Hello, TREX is now in a position to start requesting an autonomous system number and IPv4 and IPv6 address space. I originally thought we'd just ask one of the connecting ISPs to forward the requests to RIPE under their LIR, and this is probably what we will end up doing. But it's not a very convenient way of doing it. I would like to compare the situation to that of the pure IPv6 transit providers who have expressed concerns on other mailing lists: they wouldn't like to be dependent in any way on one of their customers either. Their situation differs slightly from ours though. They are willing to become LIRs, or they are already LIRs, whereas the number of annual change requests to an IXP's database objects is so small that it won't make sense for a new IXP to become a LIR itself. (Especially given the recent volatility of the costs associated ...) So, what would be an ideal solution? One solution that occurred to me was that there could be an umbrella-LIR for all the IXPs in Europe. Perhaps it could be operated by RIPE NCC? Or possibly Euro-IX could operate a LIR for use by its members? What sort of thoughts do others have on this issue? Or is it a non-issue? ;-) -- Aleksi Suhonen / +358 45 6702048 TREX Tampere Region Exchange Oy www.trextampereregionexchange.fi
Hi At 10:46 +0300 9/7/03, Aleksi Suhonen wrote:
Hello,
TREX is now in a position to start requesting an autonomous system number and IPv4 and IPv6 address space. I originally thought we'd just ask one of the connecting ISPs to forward the requests to RIPE under their LIR, and this is probably what we will end up doing.
But it's not a very convenient way of doing it. I would like to compare the situation to that of the pure IPv6 transit providers who have expressed concerns on other mailing lists: they wouldn't like to be dependent in any way on one of their customers either.
PI space as opposed to PA would help here.
Their situation differs slightly from ours though. They are willing to become LIRs, or they are already LIRs, whereas the number of annual change requests to an IXP's database objects is so small that it won't make sense for a new IXP to become a LIR itself. (Especially given the recent volatility of the costs associated ...)
This sounds like an item for the NCC services group to develop a new low cost membership for low change LIRs. The Action Plan for next year is being formulated just now so it would be a good time to suggest it.
So, what would be an ideal solution? One solution that occurred to me was that there could be an umbrella-LIR for all the IXPs in Europe. Perhaps it could be operated by RIPE NCC?
I think PI space would be a better solution rather than an LIR run by the NCC.
Or possibly Euro-IX could operate a LIR for use by its members?
That might attract the attention of the EU, as it gives an appearance of "join the association or you will not get address space" which is seen as anti-competitive.
What sort of thoughts do others have on this issue? Or is it a non-issue? ;-)
I think it is more of an issue now as the costs go up to become an LIR. f
On Wed, 9 Jul 2003, Fearghas McKay wrote:
Hi
Hello,
At 10:46 +0300 9/7/03, Aleksi Suhonen wrote:
Hello,
TREX is now in a position to start requesting an autonomous system number and IPv4 and IPv6 address space. I originally thought we'd just ask one of the connecting ISPs to forward the requests to RIPE under their LIR, and this is probably what we will end up doing.
But it's not a very convenient way of doing it. I would like to compare the situation to that of the pure IPv6 transit providers who have expressed concerns on other mailing lists: they wouldn't like to be dependent in any way on one of their customers either.
PI space as opposed to PA would help here.
Regarding IPv6: IXPs already have /48s "set aside". I understand that transit providers (with few clients) dont have their problem solved at this time. My view is that transit providers customers make the policies at the meetings because they are the majority, but some good sense is yet to be seen towards the transit providers' "problem" (some already hacked the situation, some others didnt).
Their situation differs slightly from ours though. They are willing to become LIRs, or they are already LIRs, whereas the number of annual change requests to an IXP's database objects is so small that it won't make sense for a new IXP to become a LIR itself. (Especially given the recent volatility of the costs associated ...)
This sounds like an item for the NCC services group to develop a new low cost membership for low change LIRs. The Action Plan for next year is being formulated just now so it would be a good time to suggest it.
So, what would be an ideal solution? One solution that occurred to me was that there could be an umbrella-LIR for all the IXPs in Europe. Perhaps it could be operated by RIPE NCC?
I think PI space would be a better solution rather than an LIR run by the NCC.
I also dont think a LIR run by the NCC makes much sense, although i think its feasible. Here, we run an IXP, a ccTLD (with a registrar scheme), and also an academic network. One of *our* people runs the registrar for the academic network.
Or possibly Euro-IX could operate a LIR for use by its members?
That might attract the attention of the EU, as it gives an appearance of "join the association or you will not get address space" which is seen as anti-competitive.
This would be only a way. Other associations are free to operate a LIR, right? The other solution i see for the problem presented is asking (paying?) an ISP from another country to submit the request. Anybody knows this form of business? LIR-only-customer? :-)
What sort of thoughts do others have on this issue? Or is it a non-issue? ;-)
I think it is more of an issue now as the costs go up to become an LIR.
f
Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!"
Hello, Quote from Fearghas McKay: } >TREX is now in a position to start requesting an autonomous system } >number and IPv4 and IPv6 address space. I originally thought we'd } >just ask one of the connecting ISPs to forward the requests to RIPE } >under their LIR, and this is probably what we will end up doing. } PI space as opposed to PA would help here. Hmm ... this raises another potential issue: We would like to be able to host a ccTLD name server and possibly other services that absolutely require global visibility. If we request PI space we will get exactly what we ask for. According to my notes it would be under /20 (but over /22) and thus it might be really hard to get it visible in every nook and cranny on the Internet. } >Their situation differs slightly from ours though. They are willing } >to become LIRs, or they are already LIRs, whereas the number of } >annual change requests to an IXP's database objects is so small } >that it won't make sense for a new IXP to become a LIR itself. } This sounds like an item for the NCC services group to develop } a new low cost membership for low change LIRs. The Action Plan } for next year is being formulated just now so it would be a good } time to suggest it. Hmm ... maybe, but I could anticipate great resistance toward such a suggestion, because couldn't it raise the cost of the bigger membership classes drastically? I am under the impression that a good portion of the existing SMALL LIRs have pretty low change frequencies too. } >Or possibly Euro-IX could operate a LIR for use by its members? } That might attract the attention of the EU, as it gives an } appearance of "join the association or you will not get address } space" which is seen as anti-competitive. Well ... Carlos already pointed this out too, but the way I see it is that IXPs would still have all the old options available. They could become LIRs themselves or they could use someone else's LIR. And nothing would prevent someone from creating another European IXP Association. Euro-IX is not exactly a monopoly on anything. ;-) -- Aleksi Suhonen / TREX
Hi, On Wed, Jul 09, 2003 at 01:07:14PM +0300, Aleksi Suhonen wrote:
Hmm ... this raises another potential issue: We would like to be able to host a ccTLD name server and possibly other services that absolutely require global visibility.
Global visibility doesn't require a dedicated network for that server - to the contrary: if you want to make that name server reliably reachable, take address space from the largest block you can find. There is *no* need for PI or "otherwise special" addresses for a ccTLD name server. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, 9 Jul 2003, Gert Doering wrote:
Hi,
On Wed, Jul 09, 2003 at 01:07:14PM +0300, Aleksi Suhonen wrote:
Hmm ... this raises another potential issue: We would like to be able to host a ccTLD name server and possibly other services that absolutely require global visibility.
Global visibility doesn't require a dedicated network for that server - to the contrary: if you want to make that name server reliably reachable, take address space from the largest block you can find.
There is *no* need for PI or "otherwise special" addresses for a ccTLD name server.
This is out of the scope of eix-wg, but i do not fully agree: + root servers are globally-critical infrastructure + ccTLD servers are community-critical infrastructure AND: IXPs fall in the border of the previous two: a) An IXP in London/Amsterdam/Frankfurt/... is globally-critical b) An IXP in Lisbon/Warsaw/Bucharest/... is community-critical The curious thing is b) are also undoubtably IXPs, but it is more difficult for them, being in small cities to get a /48 from the IXPs' block (take another look at the rules!) hint: transit providers dont show up often in small cities' IXPs!
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!"
hi, On Wed, Jul 09, 2003 at 11:32:19AM +0100, Carlos Friacas wrote:
There is *no* need for PI or "otherwise special" addresses for a ccTLD name server.
This is out of the scope of eix-wg, but i do not fully agree: + root servers are globally-critical infrastructure + ccTLD servers are community-critical infrastructure
I have no problems with that. But "critical infrastructure" doesn't need "special addresses". The *root* needs special addresses, because they are hardwired into the clients. Everything else (DNS wise) can be found via DNS, so there's no need for special addresses for ccTLD servers, 2nd-level DNS servers, or whatever. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
This is out of the scope of eix-wg, but i do not fully agree: + root servers are globally-critical infrastructure + ccTLD servers are community-critical infrastructure
and the latter can be found using the dns, the former are the only things which can't. randy
Hi Carlos, Carlos Friacas <cfriacas@fccn.pt> wrote: [...]
AND: IXPs fall in the border of the previous two: a) An IXP in London/Amsterdam/Frankfurt/... is globally-critical b) An IXP in Lisbon/Warsaw/Bucharest/... is community-critical
The curious thing is b) are also undoubtably IXPs, but it is more difficult for them, being in small cities to get a /48 from the IXPs' block (take another look at the rules!)
Looking at the policy[0] I see that to be defined as an IXP you must have "... a minimum of three ISPs connected and there must be a clear and open policy for others to join." The policy then says that a /48 will be assigned unless the requester "is confident that it will never need more than a single network". The result of this is that we've assigned 29 /48s[1]. No one has ever told us that they are confident that a /64 will suffice. I don't think that the policy actually discriminates against IXPs in small cities. I concede that the wording in the policy could be clearer. We'd be happy to update the text of the policy if needed. I'd suggest that any changes to the policy text (or content for that matter) should be discussed on the <address-policy-wg@ripe.net> list. Regards, -- leo vegoda RIPE NCC Registration Services Manager [0] http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html [1] http://www.ripe.net/ipv6/ipv6allocs.html
Hi, just an additional comment to add to Leo's message: The policy [0] speaks about IPv6 address allocation for the peering mesh itself. However, many IXPs also establish separate "service networks" attached to the IXP, to provide various services, and I get the impression that the initial question really was about what he should do to get address space for the service network. I think the generic answer here is "get it from one or more of your upstream transit service providers", i.e. it's not covered by the "IPv6 address allocation policy for IXPs". In other words, there is nothing special about an IXP service network which warrants that it be treated different from anyone else. Regards, - Håvard [0] http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html
On Thu, 10 Jul 2003, Havard Eidnes wrote:
Hi,
just an additional comment to add to Leo's message:
The policy [0] speaks about IPv6 address allocation for the peering mesh itself. However, many IXPs also establish separate "service networks" attached to the IXP, to provide various services, and I get the impression that the initial question really was about what he should do to get address space for the service network.
I think the generic answer here is "get it from one or more of your upstream transit service providers", i.e. it's not covered by the "IPv6 address allocation policy for IXPs". In other words, there is nothing special about an IXP service network which warrants that it be treated different from anyone else.
Oh, no... not back to that discussion again! :-) My issue is related to the requirement of having 3 members without "default:" on their policy. I can live with 3 (i think even 5 or 10 would be a better number), however what i dont see fit is having the requirement for not defaulting. Example: a+ small country [somewhat different reality] b+ 6 ISPs (6 autonomous systems) c+ 2 tier-something carrier d+ IXP has 8 members (b plus c) Outcome: IXP doesnt qualify to get an "IXP allocation" (/48 or /64, i dont mind that...).
Regards,
- Håvard
Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!"
Hi, On Thu, Jul 10, 2003 at 12:12:37PM +0100, Carlos Friacas wrote:
My issue is related to the requirement of having 3 members without "default:" on their policy.
Ummm. Where exactly do you see the word "default" in the policy document? $ lynx -dump http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html |grep default comes back empty.
Example: a+ small country [somewhat different reality] b+ 6 ISPs (6 autonomous systems) c+ 2 tier-something carrier d+ IXP has 8 members (b plus c) Outcome: IXP doesnt qualify to get an "IXP allocation" (/48 or /64, i dont mind that...).
Of course the IXP qualifies. 8 is more than 3. Easy math. People - if you complain about policy, complain about what's there, not what you are afraid that *might* have sneaked in by the evil empire... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Thu, Jul 10, 2003 at 01:37:01PM +0200, Gert Doering wrote:
My issue is related to the requirement of having 3 members without "default:" on their policy. Ummm. Where exactly do you see the word "default" in the policy document?
OK. Found it, it's in the *request form*. I agree that the form should demand data that the policy doesn't. (nevertheless, finding *3* ISPs that have full BGP tables shouldn't be overly hard even for a small country / small IXP - and if you are so small that you can't manage that, using a /64 from one of the members wouldn't hurt anybody - the DECIX ran on a borrowed IPv4 PA /24 for about 5 years or so, with over 50 members, and without any issues). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, 10 Jul 2003, Gert Doering wrote:
Hi,
On Thu, Jul 10, 2003 at 01:37:01PM +0200, Gert Doering wrote:
My issue is related to the requirement of having 3 members without "default:" on their policy. Ummm. Where exactly do you see the word "default" in the policy document?
OK. Found it, it's in the *request form*.
you didnt submit any request for an IXP till today...? :-)
I agree that the form should demand data that the policy doesn't.
(nevertheless, finding *3* ISPs that have full BGP tables shouldn't be overly hard even for a small country / small IXP - and if you are so
"shouldn't be": yes, it was. :-)))
small that you can't manage that, using a /64 from one of the members wouldn't hurt anybody - the DECIX ran on a borrowed IPv4 PA /24 for about 5 years or so, with over 50 members, and without any issues).
a "hack". an example of what we dont want when we are putting effort in designing policies... ;-)
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Thanks Gert. Sorry if some of my lines turn out to be cryptic sometimes... :-) Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!"
Hi, On Thu, Jul 10, 2003 at 12:47:24PM +0100, Carlos Friacas wrote:
My issue is related to the requirement of having 3 members without "default:" on their policy. Ummm. Where exactly do you see the word "default" in the policy document? OK. Found it, it's in the *request form*. you didnt submit any request for an IXP till today...? :-)
No :-) (while I'm a listed tech-c: for the DECIX LIR, Arnold handled that) [..]
small that you can't manage that, using a /64 from one of the members wouldn't hurt anybody - the DECIX ran on a borrowed IPv4 PA /24 for about 5 years or so, with over 50 members, and without any issues).
a "hack". an example of what we dont want when we are putting effort in designing policies... ;-)
Yes. But on the other hand, no single policy can catch all special cases, and you want to have at least *some* definition of IXP... Still I think that the form is worded in a way that doesn't reflect the intent of the policy. Maybe something like "three members that participate in the global BGP routing with their own globally visible AS" or whatever like that. Peering makes sense even without a full BGP table. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, 10 Jul 2003, Gert Doering wrote:
Hi,
small that you can't manage that, using a /64 from one of the members wouldn't hurt anybody - the DECIX ran on a borrowed IPv4 PA /24 for about 5 years or so, with over 50 members, and without any issues).
a "hack". an example of what we dont want when we are putting effort in designing policies... ;-)
Yes. But on the other hand, no single policy can catch all special cases, and you want to have at least *some* definition of IXP...
IXP definition: 3 or more members, policy for joining public. enough? need to add that a member needs to have a valid ASN ?
Still I think that the form is worded in a way that doesn't reflect the intent of the policy. Maybe something like "three members that participate in the global BGP routing with their own globally visible AS" or whatever like that. Peering makes sense even without a full BGP table.
Agree. Now to practice: Can the form be "corrected" in a near future? if noone objects to that... :-)
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!"
At 13:51 +0200 10/7/03, Gert Doering wrote:
Still I think that the form is worded in a way that doesn't reflect the intent of the policy. Maybe something like "three members that participate in the global BGP routing with their own globally visible AS" or whatever like that. Peering makes sense even without a full BGP table.
However the agreed policy definition did not refer to BGP, globally visible AS and those issues were never raised during the discussions. As such the form should be tweaked to reflect policy rather than the other way round. f
Hi, On Thu, Jul 10, 2003 at 12:58:39PM +0100, Fearghas McKay wrote:
At 13:51 +0200 10/7/03, Gert Doering wrote:
Still I think that the form is worded in a way that doesn't reflect the intent of the policy. Maybe something like "three members that participate in the global BGP routing with their own globally visible AS" or whatever like that. Peering makes sense even without a full BGP table.
However the agreed policy definition did not refer to BGP, globally visible AS and those issues were never raised during the discussions.
As such the form should be tweaked to reflect policy rather than the other way round.
That's about what I wanted to say :-) - the usual counter argument is "but how do we know that those entities are ISPs" - and I think tacking that to "have a global unique AS number" would be a reasonable compromise. (If *all* participants at an IXP insist on peering with private ASns, then I'd consider that a very specific corner case that I'm not going to worry about) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
At 14:03 +0200 10/7/03, Gert Doering wrote:
Hi,
However the agreed policy definition did not refer to BGP, globally visible AS and those issues were never raised during the discussions.
As such the form should be tweaked to reflect policy rather than the other way round.
That's about what I wanted to say :-) - the usual counter argument is "but how do we know that those entities are ISPs" - and I think tacking that to "have a global unique AS number" would be a reasonable compromise.
except we already had that argument when we put the policy together initially. This is merely correcting an implementation error by an RIR, as such unless we really want to go through the whole policy debate again the form should be corrected. If we reopen the policy I am sure there will be more cans of worms opened:-(
(If *all* participants at an IXP insist on peering with private ASns, then I'd consider that a very specific corner case that I'm not going to worry about)
The open membership policy should help cover that - as the space is liable to filtering that was felt to be enough to discourage spurious applications. <wg-chair hat>So Leo - can we have a change in the application form please so it more closely represents the policy?</hat> Thanks f
Fearghas McKay <fm@st-kilda.org> wrote: [...]
As such the form should be tweaked to reflect policy rather than the other way round.
It will be. Regards, -- leo vegoda RIPE NCC Registration Services Manager
At 13:07 +0300 9/7/03, Aleksi Suhonen wrote:
} PI space as opposed to PA would help here.
Hmm ... this raises another potential issue: We would like to be able to host a ccTLD name server and possibly other services that absolutely require global visibility.
Getting visibility when you have a ccTLD server is probably not an immediate issue for now IMO.
If we request PI space we will get exactly what we ask for. According to my notes it would be under /20 (but over /22) and thus it might be really hard to get it visible in every nook and cranny on the Internet.
Anycast would help here, getting multipe announcements of your routes/PI space from your transit provider members would help. After all is not the main reason to have the independent space, whether PI or PA is to protect the IXP in the case of the donating member of PA space for the IXP going into liquidation etc.
} >Their situation differs slightly from ours though. They are willing } >to become LIRs, or they are already LIRs, whereas the number of } >annual change requests to an IXP's database objects is so small } >that it won't make sense for a new IXP to become a LIR itself.
} This sounds like an item for the NCC services group to develop } a new low cost membership for low change LIRs. The Action Plan } for next year is being formulated just now so it would be a good } time to suggest it.
Hmm ... maybe, but I could anticipate great resistance toward such a suggestion, because couldn't it raise the cost of the bigger membership classes drastically?
it would also bring in new members who have legacy space that is not in the RIRs.
I am under the impression that a good portion of the existing SMALL LIRs have pretty low change frequencies too.
indeed and they would perhaps be happy to vote for it as an idea as well!
} >Or possibly Euro-IX could operate a LIR for use by its members?
} That might attract the attention of the EU, as it gives an } appearance of "join the association or you will not get address } space" which is seen as anti-competitive.
Well ... Carlos already pointed this out too, but the way I see it is that IXPs would still have all the old options available. They could become LIRs themselves or they could use someone else's LIR. And nothing would prevent someone from creating another European IXP Association.
Euro-IX is not exactly a monopoly on anything. ;-)
Indeed however when sitting next to a sleeping 800 kg gorilla it is always best to tread with care. :-) If as an association offering a service Euro-IX then has to devote an amount of time to dealing with the EU it will just add to the cost of the service which may make it uninteresting for members. This is not to say that it is not a possibility just one that has to be considered carefully. f
participants (7)
-
Aleksi Suhonen -
Carlos Friacas -
Fearghas McKay -
Gert Doering -
Havard Eidnes -
leo vegoda -
Randy Bush