From nick at inex.ie Wed Aug 1 15:19:20 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 01 Aug 2012 14:19:20 +0100 Subject: [ncc-services-wg] LIR association with number resources Message-ID: <50192CD8.7000107@inex.ie> Hi, The RIPE NCC maintains a list of what allocations are associated with what LIR in the following file: ftp.ripe.net:/ripe/stats/membership/alloclist.txt However, this file is limited to v4/v6 allocations only. There are no direct assignments (PI addresses), no ASNs or other number resources (e.g. ERX under contract, and so forth). Would it be possible for the NCC to examine whether they could publish what LIR is associated with what number resource, for all the number resources they handle, not just allocations? Nick From gert at space.net Wed Aug 1 15:43:43 2012 From: gert at space.net (Gert Doering) Date: Wed, 1 Aug 2012 15:43:43 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <50192CD8.7000107@inex.ie> References: <50192CD8.7000107@inex.ie> Message-ID: <20120801134343.GB38127@Space.Net> Hi, On Wed, Aug 01, 2012 at 02:19:20PM +0100, Nick Hilliard wrote: > The RIPE NCC maintains a list of what allocations are associated with what > LIR in the following file: > > ftp.ripe.net:/ripe/stats/membership/alloclist.txt > > However, this file is limited to v4/v6 allocations only. There are no > direct assignments (PI addresses), no ASNs or other number resources (e.g. > ERX under contract, and so forth). > > Would it be possible for the NCC to examine whether they could publish what > LIR is associated with what number resource, for all the number resources > they handle, not just allocations? Yes, that would be nice. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From alexb at ripe.net Wed Aug 1 16:46:23 2012 From: alexb at ripe.net (Alex Band) Date: Wed, 1 Aug 2012 16:46:23 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <20120801134343.GB38127@Space.Net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> Message-ID: Hello Nick, Gert, All of this information is in the RIPE Database, which is what it's for; it's just not in this bulk representation. What you're requesting is not really straight forward to implement, and would require quite some resources to get done. Could you give us some context how you would want to use this data, and what you currently are not capable of doing using for example the RIPE Database? Thanks, Alex Band On 1 Aug 2012, at 15:43, Gert Doering wrote: > Hi, > > On Wed, Aug 01, 2012 at 02:19:20PM +0100, Nick Hilliard wrote: >> The RIPE NCC maintains a list of what allocations are associated with what >> LIR in the following file: >> >> ftp.ripe.net:/ripe/stats/membership/alloclist.txt >> >> However, this file is limited to v4/v6 allocations only. There are no >> direct assignments (PI addresses), no ASNs or other number resources (e.g. >> ERX under contract, and so forth). >> >> Would it be possible for the NCC to examine whether they could publish what >> LIR is associated with what number resource, for all the number resources >> they handle, not just allocations? > > Yes, that would be nice. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From gert at space.net Wed Aug 1 16:56:40 2012 From: gert at space.net (Gert Doering) Date: Wed, 1 Aug 2012 16:56:40 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> Message-ID: <20120801145640.GF38127@Space.Net> Hi, On Wed, Aug 01, 2012 at 04:46:23PM +0200, Alex Band wrote: > All of this information is in the RIPE Database, which is what it's for; It is? So which LIR is AS5539 attached to, if I may pose a random example, and how do I find that out from the RIPE-DB? Actually, from the RIPE DB the relationship between a certain object and a certain regID is very hard to find (if possible at all), while nicely straightforward from the alloclist. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7650 bytes Desc: not available URL: From nick at inex.ie Wed Aug 1 17:02:43 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 01 Aug 2012 16:02:43 +0100 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> Message-ID: <50194513.4040609@inex.ie> Hi Alex, Didn't realise it was in the RIPE DB. Could you explain how to access this information? I.e. for a sample prefix of 193.242.111.0/24 and a sample ASN as2128, how does one query what LIR these numbers are registered through? thanks, Nick On 01/08/2012 15:46, Alex Band wrote: > Hello Nick, Gert, > > All of this information is in the RIPE Database, which is what it's for; > it's just not in this bulk representation. What you're requesting is not > really straight forward to implement, and would require quite some > resources to get done. > Could you give us some context how you would want to use this data, and > what you currently are not capable of doing using for example the RIPE > Database? > > Thanks, > > Alex Band > > > On 1 Aug 2012, at 15:43, Gert Doering wrote: > >> Hi, >> >> On Wed, Aug 01, 2012 at 02:19:20PM +0100, Nick Hilliard wrote: >>> The RIPE NCC maintains a list of what allocations are associated with what >>> LIR in the following file: >>> >>> ftp.ripe.net:/ripe/stats/membership/alloclist.txt >>> >>> However, this file is limited to v4/v6 allocations only. There are no >>> direct assignments (PI addresses), no ASNs or other number resources (e.g. >>> ERX under contract, and so forth). >>> >>> Would it be possible for the NCC to examine whether they could publish what >>> LIR is associated with what number resource, for all the number resources >>> they handle, not just allocations? >> >> Yes, that would be nice. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >> >> > -- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From denis at ripe.net Wed Aug 1 17:42:23 2012 From: denis at ripe.net (Denis Walker) Date: Wed, 01 Aug 2012 17:42:23 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <20120801145640.GF38127@Space.Net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> Message-ID: <50194E5F.1060401@ripe.net> Dear Gert Well almost and in a round about way. All ALLOCATION objects are required to have a reference to the LIR's ORGANISATION object. All ASSIGNED PA objects are more specific to an ALLOCATION with this reference. So it is possible to get this part of the information with an inverse query on the ORGANISATION object and then a more specific query on the returned ALLOCATION objects. Beyond that is tricky as the reference to ORGANISATION is optional everywhere except the ALLOCATION objects. What you are asking for would be possible if the reference to ORGANISATION was mandatory on all allocated resources. regards Denis Walker Business Analyst RIPE NCC Database Group On 01/08/2012 16:56, Gert Doering wrote: > Hi, > > On Wed, Aug 01, 2012 at 04:46:23PM +0200, Alex Band wrote: >> All of this information is in the RIPE Database, which is what it's for; > > It is? > > So which LIR is AS5539 attached to, if I may pose a random example, > and how do I find that out from the RIPE-DB? > > Actually, from the RIPE DB the relationship between a certain object > and a certain regID is very hard to find (if possible at all), while > nicely straightforward from the alloclist. > > Gert Doering > -- NetMaster > From alexb at ripe.net Wed Aug 1 17:42:47 2012 From: alexb at ripe.net (Alex Band) Date: Wed, 1 Aug 2012 17:42:47 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <20120801145640.GF38127@Space.Net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> Message-ID: I see what you mean now. You can find out who the holder of the resources is just like this: https://apps.db.ripe.net/whois/lookup/ripe/aut-num/AS5539.html So to answer your question, AS5539 is attached to: as-name: SPACENET descr: SpaceNET AG, Munich descr: Internet provider in southern germany descr: Joseph-Dollinger-Bogen 14, D-80807 Muenchen descr: Germany But of course you know this. The only thing you can't easily find out is the reg-id, although it is available information here: https://www.ripe.net/membership/indices/data/de.space.html <-- it's in the URL! :) So I apologise for the confusion, it seems with "which LIR" you don't mean their name and contact details, but (just) their reg-id. Why would you like to know that specifically, if I may ask? -Alex On 1 Aug 2012, at 16:56, Gert Doering wrote: > Hi, > > On Wed, Aug 01, 2012 at 04:46:23PM +0200, Alex Band wrote: >> All of this information is in the RIPE Database, which is what it's for; > > It is? > > So which LIR is AS5539 attached to, if I may pose a random example, > and how do I find that out from the RIPE-DB? > > Actually, from the RIPE DB the relationship between a certain object > and a certain regID is very hard to find (if possible at all), while > nicely straightforward from the alloclist. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Wed Aug 1 17:50:58 2012 From: gert at space.net (Gert Doering) Date: Wed, 1 Aug 2012 17:50:58 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <50194E5F.1060401@ripe.net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> <50194E5F.1060401@ripe.net> Message-ID: <20120801155058.GG38127@Space.Net> Hi, On Wed, Aug 01, 2012 at 05:42:23PM +0200, Denis Walker wrote: > Well almost and in a round about way. All ALLOCATION objects are > required to have a reference to the LIR's ORGANISATION object. All > ASSIGNED PA objects are more specific to an ALLOCATION with this > reference. So it is possible to get this part of the information with an > inverse query on the ORGANISATION object and then a more specific query > on the returned ALLOCATION objects. Yeah, I'm aware of that - but it's complicated, and needs a lot of queries. The alloclist nicely groups these under the RegID (which I can't get seem out of the RIPE DB at all, if I look at our objects). > Beyond that is tricky as the reference to ORGANISATION is optional > everywhere except the ALLOCATION objects. What you are asking for would > be possible if the reference to ORGANISATION was mandatory on all > allocated resources. Now, while this sounds nice, it doesn't work. inetnum and autnum objects do have an org: attribute, and it is actually enforced upon registration by the hostmasters - but it will point to the *holder* of the object, not to the sponsoring LIR. I'm not claiming that it's there today (or that it actually *should* be there, given that Nick's initial mail was a request "for the NCC to examine..."), I'm just challenging Alex' claim that it can be done today... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Wed Aug 1 18:03:13 2012 From: gert at space.net (Gert Doering) Date: Wed, 1 Aug 2012 18:03:13 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> Message-ID: <20120801160313.GH38127@Space.Net> Hi, On Wed, Aug 01, 2012 at 05:42:47PM +0200, Alex Band wrote: > I see what you mean now. > > You can find out who the holder of the resources is just like this: > https://apps.db.ripe.net/whois/lookup/ripe/aut-num/AS5539.html > > So to answer your question, AS5539 is attached to: > as-name: SPACENET > descr: SpaceNET AG, Munich > descr: Internet provider in southern germany > descr: Joseph-Dollinger-Bogen 14, D-80807 Muenchen > descr: Germany > > But of course you know this. Actually, I don't. I now know who is using AS5539, but I do not know who gets billed for it, and who takes responsibility (by means of the 2007-01 contract) for it. For AS5539 that was not a particulary good example as "holder" and "LIR" is both SpaceNet/de.space - but let's look at a more interesting case, AS196611... > The only thing you can't easily find out is the reg-id, although it is available information here: > https://www.ripe.net/membership/indices/data/de.space.html <-- it's in the URL! :) Hmmm. This gives me mapping from "I know the regid to the contact data", but if I don't know the regid yet - how do I get there? > So I apologise for the confusion, it seems with "which LIR" you > don't mean their name and contact details, but (just) their reg-id. > Why would you like to know that specifically, if I may ask? Actually, it would be interesting to learn how to find out LIR name and contact details for AS196611... "org:" points to "the holder", and so do admin-c: and tech-c: - I could do some guesses based on the mnt-by: used, but that could be changed to something arbitrary as well. The regID would be a convenient key to be able to map "I know one object" to "what other objects does that LIR have?" - which I mostly use for statistical stuff based on routing table and stats files, to add the mapping "these all belong to the same LIR" that the stats files do not have. OTOH, since you need the regid to get the membership info, that is another quite obvious use :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nick at inex.ie Wed Aug 1 18:53:40 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 01 Aug 2012 17:53:40 +0100 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <50194E5F.1060401@ripe.net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> <50194E5F.1060401@ripe.net> Message-ID: <50195F14.5070203@inex.ie> On 01/08/2012 16:42, Denis Walker wrote: > Beyond that is tricky as the reference to ORGANISATION is optional > everywhere except the ALLOCATION objects. What you are asking for would be > possible if the reference to ORGANISATION was mandatory on all allocated > resources. Hi Denis, Thanks for your reply. Somehow or another, alloclist.txt is built from information which is held by the RIPE NCC. This information includes the LIR regid, which means that you have a pretty much direct mapping internally between allocations and regid. Separately, there is another file maintained on the RIPE ftp site called delegated-ripencc-latest. This includes all direct assignments, all ASNs and all allocations. What I was looking for was something along the lines of delegated-ripencc-latest, except with an extra field to include the regid if it exists for that particular object. I don't see any particular need to include this information in objects in the ripe database, because it would probably be difficult to do due to backwards compatibility reasons. But it should be pretty easy to augment delegated-ripencc-latest with an extra field, no? Nick From nick at netability.ie Wed Aug 1 19:10:16 2012 From: nick at netability.ie (Nick Hilliard) Date: Wed, 01 Aug 2012 18:10:16 +0100 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> Message-ID: <501962F8.1040204@netability.ie> On 01/08/2012 16:42, Alex Band wrote: > Why would you like to know that specifically, if I may ask? Hi Alex, I'm interested in seeing the regid formally linked to the allocation / direct assignments lists for several reasons: 1. because the RIPE NCC has put very substantial time and resources into linking resource assignment to the end user via a LIR, and as a representative of a RIPE NCC member, I'd like to see this particular information set published. 2. it makes handling abuse issues easier. As you're well aware, network resource abusers often hide behind several layers of indirection to conceal their tracks. By publishing a token which can provide a link between the end user and their contractual support provider, this makes it substantially easier to deal with abuse related issues. 3. it makes it possible for members to independently verify the current charging scheme. Nick From ebais at a2b-internet.com Wed Aug 1 19:18:20 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 1 Aug 2012 19:18:20 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <20120801134343.GB38127@Space.Net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> Message-ID: <00d601cd7009$a6697c80$f33c7580$@a2b-internet.com> Hi guys, Why would you like to have a list per LIR that specifies which administrative cost are billed through it? The registration office doesn't need to have a network relation with the holder of the resource. For example, we register PI or AS objects for others, but we don't require them to use them in our network. I fail to see why that relation should be published publicly. Erik Bais From alexb at ripe.net Fri Aug 3 11:30:06 2012 From: alexb at ripe.net (Alex Band) Date: Fri, 3 Aug 2012 11:30:06 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <501962F8.1040204@netability.ie> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> <501962F8.1040204@netability.ie> Message-ID: <8F501051-12BD-4687-BDDA-AB8F805234FF@ripe.net> Hello Nick, Gert, I have done some research on this topic yesterday. Based on my findings, there are two aspects that I would like to cover. First, there is the matter of the reg-id itself. The reg-id is an identifier that the RIPE NCC uses internally for maintaining records in the Registry. The fact that it is referenced in the alloclist file is essentially an anomaly, which is the reason it doesn't appear in any other place such as the RIPE Database. However, there actually is a public identifier which has a one-to-one mapping to an LIR. This is the LIR's org-id, such as "ORG-INEX1-RIPE" and "ORG-SA17-RIPE", as referenced here: https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-INEX1-RIPE.html https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-SA17-RIPE.html The information associated with this identifier is directly maintainable by the member from the LIR Portal, and should be preferred for public records. In short, if we are going to maintain an exhaustive list of all resources associated with an LIR, it should reference the org-id of the LIR and not the reg-id. Secondly, there is the addition of all resource information to the existing allocations list in bulk format. The request that you have has actually been brought up and discussed before on several occasions, even at the RIPE 63 in Vienna. The reason why it never came to an implementation is because of the the privacy issues that were raised, specifically about exposing commercial relationships such as revealing the sponsoring LIR for a particular End User resource. If you feel that the technical reasons for publishing all resource information associated with an LIR in bulk format outweigh the privacy concerns surrounding this, then we would suggest that you write a technical proposal, detailing your exact requirements and possible benefits. Then the Community should decide if this is desired. If there is consensus, then naturally we will make this information available as requested. Kind regards, Alex P.S. I will be on holiday next week, so I may not be able to respond promptly at all times On 1 Aug 2012, at 19:10, Nick Hilliard wrote: > On 01/08/2012 16:42, Alex Band wrote: >> Why would you like to know that specifically, if I may ask? > > Hi Alex, > > I'm interested in seeing the regid formally linked to the allocation / > direct assignments lists for several reasons: > > 1. because the RIPE NCC has put very substantial time and resources into > linking resource assignment to the end user via a LIR, and as a > representative of a RIPE NCC member, I'd like to see this particular > information set published. > > 2. it makes handling abuse issues easier. As you're well aware, network > resource abusers often hide behind several layers of indirection to conceal > their tracks. By publishing a token which can provide a link between the > end user and their contractual support provider, this makes it > substantially easier to deal with abuse related issues. > > 3. it makes it possible for members to independently verify the current > charging scheme. > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at netability.ie Sat Aug 4 19:25:29 2012 From: nick at netability.ie (Nick Hilliard) Date: Sat, 04 Aug 2012 18:25:29 +0100 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <8F501051-12BD-4687-BDDA-AB8F805234FF@ripe.net> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> <501962F8.1040204@netability.ie> <8F501051-12BD-4687-BDDA-AB8F805234FF@ripe.net> Message-ID: <501D5B09.5080008@netability.ie> Hi Alex, many thanks for your detailed response. On 03/08/2012 10:30, Alex Band wrote: > First, there is the matter of the reg-id itself. The reg-id is an > identifier that the RIPE NCC uses internally for maintaining records in the > Registry. The fact that it is referenced in the alloclist file is > essentially an anomaly, which is the reason it doesn't appear in any other > place such as the RIPE Database. It appears and is used in a variety of other places, e.g. the LIR index listing, board related stuff (voting, etc), meeting registration, lirportal, and so forth. > However, there actually is a public > identifier which has a one-to-one mapping to an LIR. This is the LIR's > org-id, such as "ORG-INEX1-RIPE" and "ORG-SA17-RIPE", as referenced here: > > https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-INEX1-RIPE.html > https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-SA17-RIPE.html org-ids certainly exist as an entity in the RIPEDB. However, there is not a 1:1 mapping to LIRs. It's certainly true that each LIR is assigned a unique org-id, but not every org-id is associated with a LIR. e.g. ORG-INEX1-RIPE refers to INEX, but INEX is not a LIR. > The information associated with this identifier is directly maintainable by > the member from the LIR Portal, and should be preferred for public records. > In short, if we are going to maintain an exhaustive list of all resources > associated with an LIR, it should reference the org-id of the LIR and not > the reg-id. There are certainly some advantages associated with this idea, although there is information noted in the regid listing which is not listed in the org-id object. A more complete database view would include both a resource id -> orgid and lirinfo -> orgid mapping. > Secondly, there is the addition of all resource information to the existing > allocations list in bulk format. The request that you have has actually > been brought up and discussed before on several occasions, even at the RIPE > 63 in Vienna. The reason why it never came to an implementation is because > of the the privacy issues that were raised, specifically about exposing > commercial relationships such as revealing the sponsoring LIR for a > particular End User resource. It's certainly been discussed before without any particular conclusion, but I didn't gather from the various WG discussions - either at RIPE meetings or on the mailing lists - that it stalled due to privacy concerns. Do you have a reference for this? Nick From comms+reply at ripe.net Mon Aug 6 14:54:16 2012 From: comms+reply at ripe.net (Athina Fragkouli) Date: Mon, 06 Aug 2012 14:54:16 +0200 Subject: [ncc-services-wg] =?windows-1252?q?Updated=3A_=93Independent_Inte?= =?windows-1252?q?rnet_Number_Resources_=96_Contractual_Relationship_Chang?= =?windows-1252?q?es_Between_Sponsoring_LIR_and_End_User=94?= Message-ID: <501FBE78.8070703@ripe.net> Dear colleagues, The RIPE NCC has published a new version of the procedural document ?Independent Internet Number Resources ? Contractual Relationship Changes Between Sponsoring LIR and End User?. This document replaces RIPE Document ripe-516. The procedural document describes the modifications that could be made to a contractual relationship between a sponsoring Local Internet Registry (LIR) and an End User of independent Internet number resources, and the possible consequences of such changes or of failure to communicate these changes to the RIPE NCC. The new document is available at: https://www.ripe.net/ripe/docs/ripe-559 Regards, Athina Fragkouli Legal Counsel RIPE NCC From andrew at ripe.net Fri Aug 10 12:42:40 2012 From: andrew at ripe.net (Andrew de la Haye) Date: Fri, 10 Aug 2012 12:42:40 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <50082A3F.8060701@SURFnet.nl> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> Message-ID: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> Dear Rogier and Sander, Sorry for the late reply, however holiday period started on our side. As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC. The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR. This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453. Regards, Andrew On Jul 19, 2012, at 5:39 PM, Rogier Spoor wrote: > Dear Andrew, > > Thank you for explaining that apparently there is a communication issue. > > Sander Steffann raised an important issue in his email: > -- > But more importantly: RIPE-452 is a result of policy proposal 2007-01, > and that proposal explicitly excluded ERX resource holders from being > required to sign such a contract. Quoting from 2007-01 > (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This > proposal does not cover number resources marked in the RIPE database as > Early Registration (ERX) or NOT-SET. It also does not cover number > resources listed in the RIPE database which were assigned by InterNIC or > assigned or allocated by other Regional Internet Registries." > -- > > Unfortunately you haven't responded to this issue yet. Can you please > elaborate on this issue? > > regards, > Rogier > > On 7/19/12 5:03 PM, Andrew de la Haye wrote: >> Dear colleagues, >> >> In Phase 3 of its legacy space project, the RIPE NCC is sending emails >> to contact legacy address space holders who are not RIPE NCC members and >> who hold a /16 or more. >> >> In the emails we are sending, all three options, including the option to >> register legacy address space with a sponsoring LIR, are presented to >> the organisations. However, in the case of contact with three >> organisations, an email was mistakenly sent that did not mention the >> option to use a sponsoring LIR. >> >> We regret this mistake and apologise sincerely for the confusion and any >> distress this might have caused. >> >> We are contacting the organisations concerned to ensure that the correct >> message is delivered and that they are aware of all options available to >> them. >> >> The RIPE NCC understands that "freezing" registry entries would be >> counterproductive and would not help its goal of ensuring registry >> correctness. The RIPE NCC has no intention of freezing registry entries >> for legacy resource holders. >> >> Also, the RIPE NCC would like to assure legacy address space holders >> that it has no intention of withdrawing reverse DNS services for legacy >> address space holders. >> >> The certification of address space, however, is available only to RIPE >> NCC members. >> >> Thank you for raising the issue and for giving us the opportunity to >> clarify these matters. As Marcus has pointed out, the information >> concerning the project is available on our legacy webpages: >> http://www.ripe.net/lir-services/resource-management/legacy-space >> >> We will update the documentation concerning the project in the coming >> days to accurately reflect the situation. >> >> Again, we apologise for the error and ask that you contact us at >> if you have any questions or concerns. Or let us know >> via discussion on the list. >> >> Best regards, >> >> Andrew de la Haye >> Chief Operations Officer >> RIPE NCC >> >> On 7/19/12 4:11 PM, Sander Steffann wrote: >>> Hi, >>> >>> Giving some background information related to address policy: >>> >>>> If I've understood correctly, both option a) and b) above involve in >>>> effect abolishment of historical grants and contractual submission >>>> to all current and future RIR address policies and procedures which >>>> are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting >>>> what is relevant. No grandfather clauses, acknowledgement of >>>> historical rights or explicit limitations anywhere in sight, and no >>>> option to amend the template contract imposed by the RIPE NCC. >>> >>> The template is defined in RIPE-452: >>> >>>> --- >>>> The details of any such contracts are outside the scope of this >>>> document. However, at the minimum, all contracts should include: >>>> >>>> ? Notice that the LIR is responsible for liaising with the resource >>>> holder to keep registration records up-to-date >>>> ? Notice that the resource holder is obliged to provide up-to-date >>>> registration data to the LIR and that some or all of this >>>> registration data will be published in the RIPE WHOIS Database >>>> ? Notice that none of the provider independent resources may be >>>> sub-assigned to a third party >>>> ? Notice that the resource holder is obliged to pay an annual fee to >>>> the LIR for the resources >>>> ? A clear statement that the resources will return by default to the >>>> RIPE NCC if >>>> ? The resource holder cannot be contacted >>>> ? The annual fee to the LIR is not paid >>>> ? A clear statement that the use of resources is subject to RIPE >>>> policies as published on the RIPE web site and which may be amended >>>> from time to time >>>> --- >>> >>> The first two requirements are what is important according to the >>> activity plan ("The goal of these activities will be to bring ERX and >>> legacy space registration records up to the same standards of accuracy >>> as address space distributed by the RIPE NCC since 1992."), and I >>> don't think anybody objects to that. >>> >>> The next point about sub-assignments is a problem. Current legacy >>> holders don't have any restrictions on what they can or can not do >>> with their address space. This would suddenly limit what legacy >>> holders are allowed to do, and possibly even make their existing >>> network setup break the contract. >>> >>> The next two points about paying the bills and the addresses returning >>> to the RIPE NCC if the bills are not paid also change the rights of >>> the legacy holder. When they don't sign the contract their records in >>> the database are frozen and the RIPE NCC "cannot guarantee the >>> continuation of reverse DNS". If they sign the contract and then not >>> pay the bill they lose all rights to the address space.... >>> >>> The last point is the most obvious problem for legacy holders. Now the >>> legacy holder is subject to no policy at all, and after signing such a >>> contract they are suddenly subject to all current and future RIPE >>> policies. I fully understand that legacy holders don't want to sign >>> such a contract. >>> >>> But more importantly: RIPE-452 is a result of policy proposal 2007-01, >>> and that proposal explicitly excluded ERX resource holders from being >>> required to sign such a contract. Quoting from 2007-01 >>> (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This >>> proposal does not cover number resources marked in the RIPE database >>> as Early Registration (ERX) or NOT-SET. It also does not cover number >>> resources listed in the RIPE database which were assigned by InterNIC >>> or assigned or allocated by other Regional Internet Registries." >>> >>> So, following the acceptance of 2007-01 by the community: if the RIPE >>> NCC requires legacy holders to sign such a contract (contract with >>> sponsoring LIR) they are doing something which directly contradicts an >>> accepted RIPE policy... If any legacy holder already signed such a >>> contract I strongly feel that they should either be given the option >>> to void the contract, or the contract should be declared void >>> automatically. >>> >>> - Sander >>> >>> >> > > > From sander at steffann.nl Fri Aug 10 12:53:57 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 10 Aug 2012 12:53:57 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> Message-ID: <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> Hi Andrew, > Sorry for the late reply, however holiday period started on our side. No problem! > As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC. > > The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR. Ah, I think I looked at the wrong contract template then. Thank you for clearing this up! > This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453. I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles. Thanks, Sander From nigel.titley at easynet.com Fri Aug 10 13:31:41 2012 From: nigel.titley at easynet.com (Nigel Titley) Date: Fri, 10 Aug 2012 11:31:41 +0000 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> Message-ID: Sander, I, amongst others, am really pleased that policy regarding the legacy resource holders is starting to emerge. Nigel -----Original Message----- From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Sander Steffann Sent: 10 August 2012 11:54 To: Andrew de la Haye Cc: ncc-services-wg at ripe.net; Andrew de la de la Haye; Nigel Titley; Rogier Spoor Subject: Re: [ncc-services-wg] Destruction of trust Hi Andrew, > Sorry for the late reply, however holiday period started on our side. No problem! > As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC. > > The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR. Ah, I think I looked at the wrong contract template then. Thank you for clearing this up! > This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453. I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles. Thanks, Sander From alexb at ripe.net Sun Aug 12 09:07:17 2012 From: alexb at ripe.net (Alex Band) Date: Sun, 12 Aug 2012 09:07:17 +0200 Subject: [ncc-services-wg] LIR association with number resources In-Reply-To: <501D5B09.5080008@netability.ie> References: <50192CD8.7000107@inex.ie> <20120801134343.GB38127@Space.Net> <20120801145640.GF38127@Space.Net> <501962F8.1040204@netability.ie> <8F501051-12BD-4687-BDDA-AB8F805234FF@ripe.net> <501D5B09.5080008@netability.ie> Message-ID: On 4 Aug 2012, at 19:25, Nick Hilliard wrote: > It's certainly been discussed before without any particular conclusion, but > I didn't gather from the various WG discussions - either at RIPE meetings > or on the mailing lists - that it stalled due to privacy concerns. Do you > have a reference for this? First thing I could find is a message by David Freedman from July last year: http://www.ripe.net/ripe/mail/archives/db-wg/2011-July/003745.html >> After the feedback from the DB-WG Meeting in Vienna last week, I'd like to = >> bring this back to the list. >> >> I'd like to see the RegID (or equivalent) displayed for all resources in th= >> e database, this will help us identify the >> holder of: >> >> * PA Allocations (currently found in >> alloclist >> , currently attached Org-= >> ID) >> * PA Assignments (only found through less specific aggregate inetnum an= >> d as per above) >> * PI Assignments (not found at all) >> * Autonomous systems (not found at all?) >> >> The privacy issues concerning publishing are currently being investigated b= >> y the NCC and a number of people have expressed concern about revealing com= >> mercial relationships, >> especially with regards to revealing the sponsoring LIR for a particular en= >> d-user resource (though, I did make the point that you can ask the NCC a di= >> rect question about who the >> sponsoring LIR is and lack of policy means they reveal this). >> >> The technical issue concerning publishing , is that using the RegID may not= >> be the best idea, the NCC say "It is for internal use" (but it is the only= >> thing I see in my LIR portal?), why not use the >> OrgID (but this doesn't relate to the RegID , how do I link this to a bone = >> fide LIR?) , one issue with using the regID over the orgID may be that the = >> regID would simply be represented in the >> database as a string , since there is no related object to tie it to (which= >> may be an undesirable outcome). >> >> Dave. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From bijal.sanghani at euro-ix.net Fri Aug 17 09:46:35 2012 From: bijal.sanghani at euro-ix.net (Bijal Sanghani) Date: Fri, 17 Aug 2012 08:46:35 +0100 Subject: [ncc-services-wg] Call for Agenda Items - NCC Services WG RIPE65 Message-ID: <2C9E872E-FE0A-4329-AE67-25F5EBA5F854@euro-ix.net> Dear NCC-Services WG, RIPE65 is approaching fast and we are starting to put together the agenda together for the NCC Services WG. This is your opportunity to let the RIPE NCC know what you want from them, if you would like to suggest a topic for discussion or have a presentation you have or would like to see presented please get in touch with Kurtis or myself. Kind regards, Bijal Sanghani From Niall.oReilly at ucd.ie Wed Aug 22 18:28:48 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 22 Aug 2012 17:28:48 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> Message-ID: <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> On 10 Aug 2012, at 11:53, Sander Steffann wrote: > I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles. At this time of the year, the phrase "real soon now" needs quite an elastic interpretation. Please find an initial version of our proposal attached. Best regards, Niall O'Reilly -------------- next part -------------- A non-text attachment was scrubbed... Name: LRH-Policy-draft-fbb9fbc177c9e6a8291ab86d310945e3.pdf Type: application/pdf Size: 142689 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From mansaxel at besserwisser.org Thu Aug 23 12:54:04 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 23 Aug 2012 12:54:04 +0200 Subject: [ncc-services-wg] ERX policy proposal. Message-ID: <20120823105404.GA4679@besserwisser.org> I have read the policy proposal as posted by Niall and support it. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I just got my PRINCE bumper sticker ... But now I can't remember WHO he is ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From training at ripe.net Thu Aug 23 13:56:26 2012 From: training at ripe.net (Training Mailbox) Date: Thu, 23 Aug 2012 13:56:26 +0200 Subject: [ncc-services-wg] RIPE NCC Training Courses October-December 2012 - SK, TR, NO, AE, CZ, IE, AL, DE, RU, FR, NL In-Reply-To: <4FC49B3D.8070208@ripe.net> References: <4F423861.9090900@ripe.net> <4FC49B3D.8070208@ripe.net> Message-ID: <50361A6A.8030406@ripe.net> [Apologies for duplicate emails] Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Bratislava, Istanbul, Norway, Dubai, Prague, Dublin, Tirana, Frankfurt, Moscow, Paris and Arnhem. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - IPv6 for LIRs Training Course - Routing Registry and Resource Certification Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From tore.anderson at redpill-linpro.com Thu Aug 23 14:12:10 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 23 Aug 2012 14:12:10 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> Message-ID: <50361E1A.5070006@redpill-linpro.com> * Niall O'Reilly > Please find an initial version of our proposal attached. Hi, Having read through very quickly, I'm in general supportive, but I don't think this belongs in the policy text itself: ?It is noted that, as of August 2012, commercial domain-name registrars are able to provide services comparable to the basic services defined above at a tax-inclusive retail price of about twenty euro.? It sounds more like rationale to me (although not a very good one, in my opinion). The next two paragraphs suffice as policy. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From mir at ripe.net Thu Aug 23 16:20:42 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 23 Aug 2012 16:20:42 +0200 Subject: [ncc-services-wg] New on RIPE Labs: Dry-run for last /10 procedures Message-ID: <50363C3A.5060108@ripe.net> Dear colleagues, The RIPE NCC did a "dry run" for the procedures that will start when we reach the last /10 of IPv4 address space. Please find more information about it on RIPE Labs: https://labs.ripe.net/Members/andrea/ripe-ncc-dry-run-for-last-10-procedures Kind regards, Mirjam Kuehne RIPE NCC From kurtis at kurtis.pp.se Thu Aug 23 17:06:40 2012 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Thu, 23 Aug 2012 17:06:40 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> Message-ID: <7B450B4A-D772-4221-8B99-B4A2D241FDBC@kurtis.pp.se> On 22 aug 2012, at 18:28, Niall O'Reilly wrote: > > On 10 Aug 2012, at 11:53, Sander Steffann wrote: > >> I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles. > > At this time of the year, the phrase "real soon now" needs quite > an elastic interpretation. > > Please find an initial version of our proposal attached. > > Best regards, > Niall O'Reilly So this was somewhat of a mistake. As this is a policy proposal it will be resubmitted the correct way and in the correct format and you will get the usual announcement from Emilio. For the NCC Wg-Chairs : Best regards, - kurtis - From daniel.karrenberg at ripe.net Thu Aug 23 18:19:53 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 23 Aug 2012 18:19:53 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <50361E1A.5070006@redpill-linpro.com> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <50361E1A.5070006@redpill-linpro.com> Message-ID: <064DF409-8010-4542-9F67-3FC656801D48@ripe.net> On 23.08.2012, at 14:12 , Tore Anderson wrote: > * Niall O'Reilly > >> Please find an initial version of our proposal attached. > > Hi, > > Having read through very quickly, I'm in general supportive, but I don't > think this belongs in the policy text itself: > ... > It sounds more like rationale to me (although not a very good one, in my > opinion). The next two paragraphs suffice as policy. There is a lot of such things in the proposal. It would benefit from a very clear separation of rationale, referenced policies, new policy and explanations. Clear and plain policy language should be kept clearly separate from the other parts and should not repeat other existing policy language, but reference it. Daniel From Niall.oReilly at ucd.ie Thu Aug 23 19:16:21 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 23 Aug 2012 18:16:21 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <50361E1A.5070006@redpill-linpro.com> <064DF409-8010-4542-9F67-3FC656801D48@ripe.net> Message-ID: On 23 Aug 2012, at 17:50, Nigel Titley wrote: > I'm assuming that Niall et al will refactor the proposal and Soon. If anyone would like to add their early comments to those from Tore and Daniel, they will be welcome off-list or on, and we'll take them into account. Thanks to Tore and Daniel for theirs. > submit it through the usual channels. Done earlier today. Please, everyone, accept my apologies for not doing so first time. Best regards, Niall O'Reilly From nick at netability.ie Thu Aug 23 21:49:52 2012 From: nick at netability.ie (Nick Hilliard) Date: Thu, 23 Aug 2012 20:49:52 +0100 Subject: [ncc-services-wg] ERX transfer agreement with Internet Message-ID: <50368960.8000704@netability.ie> could someone point me in the direction of the InterNIC->RIPE NCC ERX transfer agreement, if this exists? Nick From nick at netability.ie Thu Aug 23 23:48:18 2012 From: nick at netability.ie (Nick Hilliard) Date: Thu, 23 Aug 2012 22:48:18 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> Message-ID: <5036A522.6080203@netability.ie> On 22/08/2012 17:28, Niall O'Reilly wrote: > Please find an initial version of our proposal attached. I've attached some thoughts on this proposal (which I note is formally pre-publication, so these thoughts are premature). These are observations only - I'm not expressing any opinions because it's not appropriate to express an opinion before the PDP formally starts and I haven't finished formulating my opinions yet. If the proposal authors feel that there are any inaccuracies / misrepresentations / omissions here, I'd be happy to be corrected. If it would be more appropriate to wait until this document is formally announced before discussion, then I'm also happy to wait until then. Background: There are just over 3000 ERX registrations listed in the RIPE database. The proposal identifies in a roundabout way that the core problem is the lack of an existing governing contract between the ERX holders and the RIPE NCC and that in order to resolve this, the existing ERX holders should be invited on a no obligation basis to enter into a formal agreement with the RIPE NCC. In return for this invitation, the proposal creates a policy which will copperfasten the service levels which ERX holders were receiving prior to October 2011. There are two sides to the problem. On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership. Historically, the ERX holders have been happy with this situation as they received all of the privileges of address registration which were available to RIPE-assigned space and none of the responsibilities (i.e. payment). Notably, they were sufficiently happy that no-one saw any need to change the status quo by formalising this situation through a bottom-up policy. Clearly this wasn't working for the RIPE NCC, as they unilaterally withdrew the ability to perform record modifications. This was done without a mandate from the RIPE community or prior notice to the ERX holders. Whatever the rights and wrongs of this situation or how it came about, resolution is clearly necessary. The ERX holders have abruptly been disenfranchised, and the RIPE NCC's responsibilities as steward of these resources are consequently not being carried out. Neither of these positions is tenable as a long term proposition. Policy Resolution: A policy resolution needs to be found which will accommodate the wishes of the ERX holders (right of use / updates / transfers / sale / assignment of rights / contractual certainty), the RIPE community (requirement for responsible stewardship for a RIR), the RIPE NCC (payment for services received, contractual certainty) and the RIPE NCC membership (potential objection of subsidisation of non-members for ongoing services) There is a broad spectrum of potential approaches to resolution, ranging from spontaneous policy proposition by the ERX holders to unilateral action by the RIPE NCC to impose a policy determined by the RIPE community, with the decision making process being based on bottom-up consensus through the PDP, right through to a top-down decision being decided by the dutch legal system. In the absence of any existing agreement between the individual ERX holders and the RIPE NCC, it is not clear what the RIPE NCC's legal obligations are with respect to each individual ERX holder. The Current Proposal: As a side note, it is not clear to what extent this proposal reflects the viewpoints of a representative sample of ERX holders. The proposal suggests the following balance of rights and responsibilities: Rights of ERX holders: - right of use - right to have registration data kept up to date (registrant data, reverse DNS) - right to surrender the assignment - right of transfer / corporate succession / personal succession of assignment under the same terms as enjoyed by the original holder - the right to choose whether or not to enter into a formal contractual relationship with the RIPE NCC (either directly or indirectly) concerning these registrations - the right to choose whether or not to pay the RIPE NCC to maintain these registrations - the right that these rights be unaffected by any other relationship that the ERX holder has with the RIPE NCC - the right that this framework be declared as the basis of any future discussion - the right that these rights be declared as immutable in perpetuity ERX holder responsibilities: - none, unless the ERX holder chooses otherwise - if the ERX holder chooses, then: - payment of fee which is guaranteed to be lower than direct assignment RIPE NCC rights: - the right to charge for RIR services over and above those listed by the proposal as ERX holder rights RIPE NCC responsibilities - to agree explicitly to the rights claimed by the proposal - to maintain the data in the RIPE database - to perform updates / modifications / transfers as directed by ERX holders - to be responsible for ensuring that contact is made with all ERX resource holders - to agree to underwrite any cost associated with implementing this policy which is not recovered under the terms of section 5.5 of the proposal, passing on responsibility and costs to LIRs in the first instance If any of the policy proposers feel that this is unfair / inaccurate summary of the proposal / the situation, or if they feel that there are any omissions, please feel free to correct me. This email is not intended as an opinion piece and should not be read as such; I'm simply trying to understand what is being said in the proposal - it's long, complicated and is a first draft in attempting to deal with a particularly thorny issue which is fraught with political difficulties and legal uncertainties. Nick From nick at netability.ie Fri Aug 24 00:11:04 2012 From: nick at netability.ie (Nick Hilliard) Date: Thu, 23 Aug 2012 23:11:04 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5036A522.6080203@netability.ie> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5036A522.6080203@netability.ie> Message-ID: <5036AA78.5060202@netability.ie> On 23/08/2012 22:48, Nick Hilliard wrote: > RIPE NCC rights: > - the right to charge for RIR services over and above those listed by the > proposal as ERX holder rights Apologies, I omitted the following: - the right for the RIPE NCC to withdraw a basic service if and only if an equivalent other service is provided, potentially charging the ERX holder for the new service (section 5.1.2) I think there may be a conflict in the proposal here between the proposed rights of the ERX holders (i.e. the NCC must provide the basic services as stated and must not coerce the ERX holder into paying in any circumstance), and this suggestion (the RIPE NCC may completely withdraw a specific service and replace it with something equivalent, and by doing so may potentially coerce the ERX holder into paying for the new service). Or did I read it incorrectly? Nick From nigel.titley at easynet.com Thu Aug 23 18:50:18 2012 From: nigel.titley at easynet.com (Nigel Titley) Date: Thu, 23 Aug 2012 16:50:18 +0000 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <064DF409-8010-4542-9F67-3FC656801D48@ripe.net> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <50361E1A.5070006@redpill-linpro.com> <064DF409-8010-4542-9F67-3FC656801D48@ripe.net> Message-ID: I think Kurtis has already addressed this. I'm assuming that Niall et al will refactor the proposal and submit it through the usual channels. Nigel -----Original Message----- From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Daniel Karrenberg Sent: 23 August 2012 17:20 To: Tore Anderson Cc: Emilio Madaio; Nigel Titley; ncc-services-wg at ripe.net; Rogier Spoor; Andrew de la de la Haye; Sander Steffann; Andrew de la Haye; Niall O'Reilly Subject: Re: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders On 23.08.2012, at 14:12 , Tore Anderson wrote: > * Niall O'Reilly > >> Please find an initial version of our proposal attached. > > Hi, > > Having read through very quickly, I'm in general supportive, but I > don't think this belongs in the policy text itself: > ... > It sounds more like rationale to me (although not a very good one, in > my opinion). The next two paragraphs suffice as policy. There is a lot of such things in the proposal. It would benefit from a very clear separation of rationale, referenced policies, new policy and explanations. Clear and plain policy language should be kept clearly separate from the other parts and should not repeat other existing policy language, but reference it. Daniel From hank at efes.iucc.ac.il Fri Aug 24 09:25:56 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 24 Aug 2012 10:25:56 +0300 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5036A522.6080203@netability.ie> References: <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> Message-ID: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> At 22:48 23/08/2012 +0100, Nick Hilliard wrote: >There are two sides to the problem. On the one hand, ERX holders obtained >address space without a governing contract and have been enjoying the >benefits of this for many years. On the other hand, someone is footing the >bill for the maintenance and upkeep of this registration data - namely the >RIPE NCC membership. > >Historically, the ERX holders have been happy with this situation as they >received all of the privileges of address registration which were available >to RIPE-assigned space and none of the responsibilities (i.e. payment). I believe if you did an analysis of the 3000 allocations, you would find that many (my estimate - over 1700) are academic allocations and those NRENs are all paying members of RIPE NCC. And they have probably been paying members far longer than 99.9% of the RIPE membership (Janet, Renater, GARR, Surfnet, SWITCH, IUCC, etc.). But lets look at the fees as compared to ARIN: https://www.arin.net/fees/fee_schedule.html Legacy RSA: "ARIN charges a $100 USD annual fee for coverage of legacy resources under the terms of the Legacy Registration Services Agreement (Legacy RSA). Org IDs already paying annual ISP or end user fees do not pay an additional fee to receive Legacy RSA coverage. There is no initial registration fee for legacy applicants, unless a transfer is required." So, adopting a similar policy in RIPE NCC should be easy since there is a precedent. -Hank From ms at uakom.sk Fri Aug 24 11:01:14 2012 From: ms at uakom.sk (Martin Stanislav) Date: Fri, 24 Aug 2012 11:01:14 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5036AA78.5060202@netability.ie> References: <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5036A522.6080203@netability.ie> <5036AA78.5060202@netability.ie> Message-ID: <20120824090114.GB3195@moon.uakom.sk> On Thu, Aug 23, 2012 at 11:11:04PM +0100, Nick Hilliard wrote: > On 23/08/2012 22:48, Nick Hilliard wrote: > > RIPE NCC rights: > > - the right to charge for RIR services over and above those listed by the > > proposal as ERX holder rights > > Apologies, I omitted the following: > > - the right for the RIPE NCC to withdraw a basic service if and only if an > equivalent other service is provided, potentially charging the ERX holder > for the new service (section 5.1.2) > > I think there may be a conflict in the proposal here between the proposed > rights of the ERX holders (i.e. the NCC must provide the basic services as > stated and must not coerce the ERX holder into paying in any circumstance), > and this suggestion (the RIPE NCC may completely withdraw a specific > service and replace it with something equivalent, and by doing so may > potentially coerce the ERX holder into paying for the new service). Or did > I read it incorrectly? A possible issue one can infer from the outlined text is a future discussion about what comprises what the draft calles "basic services": the means for resource holders to maintain the registry data relating to their resources; publication, of this data and the provisioning of relevant delegation records in the reverse DNS. Variances of this topic are already an occasional matter of RIPE mailing lists discussions. Martin From Niall.oReilly at ucd.ie Fri Aug 24 11:47:05 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 24 Aug 2012 10:47:05 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5036AA78.5060202@netability.ie> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5036A522.6080203@netability.ie> <5036AA78.5060202@netability.ie> Message-ID: <42C3CA63-7D91-45CB-B6BD-345C8E7CCF4F@ucd.ie> On 23 Aug 2012, at 23:11, Nick Hilliard wrote: > Apologies, I omitted the following: > > - the right for the RIPE NCC to withdraw a basic service if and only if an > equivalent other service is provided, potentially charging the ERX holder > for the new service (section 5.1.2) > > I think there may be a conflict in the proposal here between the proposed > rights of the ERX holders (i.e. the NCC must provide the basic services as > stated and must not coerce the ERX holder into paying in any circumstance), > and this suggestion (the RIPE NCC may completely withdraw a specific > service and replace it with something equivalent, and by doing so may > potentially coerce the ERX holder into paying for the new service). Or did > I read it incorrectly? Nick, Whether due to your reading or my writing, I can't say, but you did miss the intent. On both sides of the apparent conflict which you identify, I think you've read more into the text than was intended. The point here is about availability of basic services (implicitly from the NCC) or of an equivalent service package (not necessarily from the NCC) at a price for either which is reasonable by reference to the current market price of a comparable service package. I expect that this will be clearer in the next (formally: initial?) draft. I could say more, but it's probably best to wait until the formalities have been respected and we properly have a draft to discuss. Best regards, Niall From kurtis at kurtis.pp.se Fri Aug 24 12:32:59 2012 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Fri, 24 Aug 2012 12:32:59 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <50361E1A.5070006@redpill-linpro.com> <064DF409-8010-4542-9F67-3FC656801D48@ripe.net> Message-ID: <1AD8BED7-3D21-4762-BABB-D6DDF338FF65@kurtis.pp.se> On 23 aug 2012, at 19:16, Niall O'Reilly wrote: > On 23 Aug 2012, at 17:50, Nigel Titley wrote: > >> I'm assuming that Niall et al will refactor the proposal and > > Soon. > If anyone would like to add their early comments to those from Tore and Daniel, > they will be welcome off-list or on, and we'll take them into account. > > Thanks to Tore and Daniel for theirs. I have a proposed clarity I like to see added. The document very briefly talks about how and under what conditions these legacy blocks where allocated. I think the document would benefit with clarifying this a bit further. I.e what's the relationship to the IANA registry, to the IR registry, RFC1174 and RFC1466. What happens if the IETF updates the IPv4 registry with a new RFC etc etc. Best regards, - kurtis - From nick at netability.ie Fri Aug 24 13:16:52 2012 From: nick at netability.ie (Nick Hilliard) Date: Fri, 24 Aug 2012 12:16:52 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> References: <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> Message-ID: <03F588DE-7793-44BD-8A6A-81CC1B65D697@netability.ie> On 24 Aug 2012, at 08:25, Hank Nussbacher wrote: > I believe if you did an analysis of the 3000 allocations, you would find that many (my estimate - over 1700) are academic allocations and those NRENs are all paying members of RIPE NCC. And they have probably been paying members far longer than 99.9% of the RIPE membership (Janet, Renater, GARR, Surfnet, SWITCH, IUCC, etc.). Hank, Are these address blocks registered to the academic institutions or to the nrens? If they are registered as being assigned directly to the institutions, I'm not sure why it's relevant that the nrens are paying members of the ripe ncc when comparing this situation to the arin LRSA. If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation. Nick From hank at efes.iucc.ac.il Sat Aug 25 20:31:05 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 25 Aug 2012 21:31:05 +0300 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <03F588DE-7793-44BD-8A6A-81CC1B65D697@netability.ie> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> At 12:16 24/08/2012 +0100, Nick Hilliard wrote: >On 24 Aug 2012, at 08:25, Hank Nussbacher wrote: > > I believe if you did an analysis of the 3000 allocations, you would > find that many (my estimate - over 1700) are academic allocations and > those NRENs are all paying members of RIPE NCC. And they have probably > been paying members far longer than 99.9% of the RIPE membership (Janet, > Renater, GARR, Surfnet, SWITCH, IUCC, etc.). > >Hank, > >Are these address blocks registered to the academic institutions or to the >nrens? If they are registered as being assigned directly to the >institutions, I'm not sure why it's relevant that the nrens are paying >members of the ripe ncc when comparing this situation to the arin LRSA. Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe: AS786 278 JOM12-RIPE operations at ja.net AS2200 257 GR1378-RIPE RenSVP at Renater.fr AS680 216 DUMY-RIPE no-email [DFN] AS137 166 EV182-RIPE Enzo.Valente at garr.it AS1103 119 SNS1-RIPE netmaster at surfnet.nl AS559 115 WH1101 huber at switch.ch AS696 45 WH1101 huber at switch.ch AS766 32 ER494-RIPE esther.robles at rediris.es AS1101 32 WB311-RIPE Wim.Biemolt at surfnet.nl AS1853 23 AA7477-RIPE admin at aco.net AS378 20 HN293-RIPE hank at efes.iucc.ac.il -Hank >If they are registered to the nrens rather than the academic institutions >then I can see that there would be a valid comparison here, which could be >relevant if the ripe community were to agree that an arin style LRSA would >be an appropriate means of resolving this situation. > >Nick From nick at netability.ie Sun Aug 26 01:02:27 2012 From: nick at netability.ie (Nick Hilliard) Date: Sun, 26 Aug 2012 00:02:27 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> Message-ID: <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> On 25 Aug 2012, at 19:31, Hank Nussbacher wrote: > Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe: mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently? Nick > AS786 278 JOM12-RIPE nstitutiooperations at ja.net > AS2200 257 GR1378-RIPE RenSVP at Renater.fr > AS680 216 DUMY-RIPE no-email [DFN] > AS137 166 EV182-RIPE Enzo.Valente at garr.it > AS1103 119 SNS1-RIPE netmaster at surfnet.nl > AS559 115 WH1101 huber at switch.ch > AS696 45 WH1101 huber at switch.ch > AS766 32 ER494-RIPE esther.robles at rediris.es > AS1101 32 WB311-RIPE Wim.Biemolt at surfnet.nl > AS1853 23 AA7477-RIPE admin at aco.net > AS378 20 HN293-RIPE hank at efes.iucc.ac.il > > -Hank > > >> If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation. >> >> Nick > From Rogier.Spoor at SURFnet.nl Sun Aug 26 01:09:25 2012 From: Rogier.Spoor at SURFnet.nl (Rogier Spoor) Date: Sun, 26 Aug 2012 01:09:25 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> Message-ID: <50395B25.2050703@SURFnet.nl> On 8/26/12 1:02 AM, Nick Hilliard wrote: > On 25 Aug 2012, at 19:31, Hank Nussbacher wrote: >> Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe: > > mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently? For ERX ranges policies are not applicable. MNT-BY is unfortunately the best indicator that's available. Rogier > > Nick > >> AS786 278 JOM12-RIPE nstitutiooperations at ja.net >> AS2200 257 GR1378-RIPE RenSVP at Renater.fr >> AS680 216 DUMY-RIPE no-email [DFN] >> AS137 166 EV182-RIPE Enzo.Valente at garr.it >> AS1103 119 SNS1-RIPE netmaster at surfnet.nl >> AS559 115 WH1101 huber at switch.ch >> AS696 45 WH1101 huber at switch.ch >> AS766 32 ER494-RIPE esther.robles at rediris.es >> AS1101 32 WB311-RIPE Wim.Biemolt at surfnet.nl >> AS1853 23 AA7477-RIPE admin at aco.net >> AS378 20 HN293-RIPE hank at efes.iucc.ac.il >> >> -Hank >> >> >>> If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation. >>> >>> Nick >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4410 bytes Desc: S/MIME Cryptographic Signature URL: From nick at netability.ie Mon Aug 27 13:26:37 2012 From: nick at netability.ie (Nick Hilliard) Date: Mon, 27 Aug 2012 12:26:37 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <50395B25.2050703@SURFnet.nl> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> Message-ID: <503B596D.1090408@netability.ie> On 26/08/2012 00:09, Rogier Spoor wrote: > On 8/26/12 1:02 AM, Nick Hilliard wrote: >> On 25 Aug 2012, at 19:31, Hank Nussbacher wrote: >>> Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe: >> >> mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently? > > For ERX ranges policies are not applicable. > > MNT-BY is unfortunately the best indicator that's available. Rogier, I suspect (strongly) that the individual academic institutions would feel that the address space is registered to them, not to the nrens. Nick From hank at efes.iucc.ac.il Tue Aug 28 18:42:51 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 28 Aug 2012 19:42:51 +0300 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503B596D.1090408@netability.ie> References: <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> Message-ID: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> At 12:26 27/08/2012 +0100, Nick Hilliard wrote: >On 26/08/2012 00:09, Rogier Spoor wrote: > > On 8/26/12 1:02 AM, Nick Hilliard wrote: > >> On 25 Aug 2012, at 19:31, Hank Nussbacher wrote: > >>> Based on mnt-by, the # of ERX address blocks managed by the top 11 > NRENs in Europe: > >> > >> mnt-by does not convey registration rights. Or did I miss a whopper of > a change in policy recently? > > > > For ERX ranges policies are not applicable. > > > > MNT-BY is unfortunately the best indicator that's available. > >Rogier, > >I suspect (strongly) that the individual academic institutions would feel >that the address space is registered to them, not to the nrens. > >Nick DDN.MIL NIC would tend to disagree with your statement (similar emails were sent back in the "old" days to most NRENs since we were the Internet pioneers): >Date: Fri, 26 Jul 91 14:00:26 PDT >From: HOSTMASTER at NIC.DDN.MIL >Subject: Re: Internet network number template >Sender: SHARON at NIC.DDN.MIL >To: HANK%VM.TAU.AC.IL at TAUNIVM.TAU.AC.IL >cc: sharon at NIC.DDN.MIL, hostmaster at NIC.DDN.MIL >Reply-To: HOSTMASTER at NIC.DDN.MIL >In-Reply-To: Message from "Hank Nussbacher > " of Wed, 24 Jul 91 15:44:58 PDT >Message-ID: <12704514128.56.SHARON at NIC.DDN.MIL> > >Hank, > >In view of your role as the network coordinator for the universities >and governmental departments in Israel, we here at the Network >Information Center feel it would be appropriate if you could serve as >the IP number delegating authority for the country of Israel. > >Basically this means that any applicaton we recieve from Israel will >be forwarded to you for IP number assignment from your allotment of >class C and B blocks. > >The delegating authority receives the applications, assigns a number >or numbers and then sends us the information so that we can update our >database (this is where the form came in that I sent to you in our >last conversation). > >We have several others like yourself who have received large blocks of >numbers and serve as delegating authorities for their respective >countries. Some do this on and "official" basis and some on an >"unofficial" basis. The difference between the two is that in the >"unofficial" situations the delegators wish to use the numbers for >specific areas of concern (eg only centers of research) and not for >any company or organization that desires a network number and/or >network connection. > >At the present time we have "official" delegating authorities for the >countries of Canada, Mexico, Italy, and the Netherlands. We have >"unofficial" delegating authorities for the countries of France, >Germany, and Sweden. > >If you would like to contact any of the authorities listed above for >more details, let me know and I will forward their names and addresses >to you. > >For the time being since you did mention that these numbers are to be >used for university and for various Ministry offices, may we forward any >requests from Israel that we receive back to you for processing? > >I have taken the liberty of naming the blocks of numbers ISRAELB-BLOCK >and ISRAELC-BLOCK (totally unimaginative I know but we had to use >something :-)) If you could think of some other identifier that would >best fit the network system please let me know and I'll change the >name immediately. > >ISRAELB-BLOCK 147.233 - 147.237 5 B's > >ISRAELC-BLOCK 192.114.1 - 192.114.254 > 192.115.1 - 192.115.254 > 192.116.1 - 192.116.254 > 192.117.1 - 192.117.254 > 192.118.1 - 192.118.254 5 Blocks of C's > > >Thank you for your cooperation. > >Regards >Sharon >An/Hostmaster From jim at rfc1035.com Tue Aug 28 19:22:58 2012 From: jim at rfc1035.com (Jim Reid) Date: Tue, 28 Aug 2012 18:22:58 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> References: <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> Message-ID: On 28 Aug 2012, at 17:42, Hank Nussbacher wrote: > DDN.MIL NIC would tend to disagree with your statement (similar > emails were sent back in the "old" days to most NRENs since we were > the Internet pioneers) Hank, that may well be have been true for you. As your email shows. However my version of this truth is even older and very different from yours. The Class B I arranged for my university in the late 1980s was never, ever anything to do with the NREN of that era. This was true for all the UK universities who dabbled in TCP/IP back then. At that time, the NREN was downright hostile to this TCP/IP heresy and we were supposed to only use X.25 based protocols until the transition to OSI was completed. CompSci departments could do TCP/IP over their own ethernets but this was *forbidden* on the WAN (and in some cases, the campus LAN too). Sometimes, it was the Internet pioneers in CompSci or EE departments who got the space from SRI, not even the university itself. Anyone interested in this ancient history can take a look at http://www.uknof.org.uk/uknof7/Reid-History.pdf So the upshot of all this is there's no "one size fits all" answer. In some cases ERX space will have been doled out by the NREN. In others, it won't. From nick at netability.ie Wed Aug 29 00:20:27 2012 From: nick at netability.ie (Nick Hilliard) Date: Tue, 28 Aug 2012 23:20:27 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> References: <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> Message-ID: <503D442B.9030500@netability.ie> On 28/08/2012 17:42, Hank Nussbacher wrote: > DDN.MIL NIC would tend to disagree with your statement (similar emails were > sent back in the "old" days to most NRENs since we were the Internet > pioneers): Hank, Like all windows into the past, the DDN's email prompts more questions than it answers. The thing that immediately jumps out is that if IUCC was acting as a de-facto national internet registry at the time and registered IP addresses on behalf of all Israeli users, not just those in the academic community, then does IUCC maintain some sort of beneficial claim of registration over subnets of the blocks you list - the sort of claim that would entitle you to say that because this was IUCC space rather than IUCC member space, that it really ought to be covered under IUCC's LIR membership for any future potential argument about a RIPE ERX policy? E.g. if ECI Telecom or Bezeq (who received 147.234.0.0/8 and 147.235.0.0/8 respectively, both of which came out of ISRAELB-BLOCK) were to state that their ERX address blocks belonged absolutely to them and that IUCC had no claims whatsoever over them, what would IUCC's position be? This is of course a matter for IUCC and ECI Telecom / Bezeq to resolve. But let's say that IUCC admitted that it had no claim to Bezeq's address block, then where would IUCC stand on 147.233.0.0/8 which is registered to the Open University? Would IUCC's position be that this is different just because they're a member of IUCC. If so, why? I can't see any clear answer here. Maybe you reached an explicit agreement with OpenU about this, but that would be outside the context of your statement about DDN-NIC above? Alternatively, could IUCC feasibly claim that it had a beneficial interest in Bezeq's block: 147.235.0.0/8? I really doubt it. I'm not fishing for answers to these specific questions, btw. I'm interested in the general issue: who is the ultimate assignee of the ERX blocks which were handed out via the NRENs and what claims are both they and the NRENs making over it? And if there is a precedent for tacitly agreeing that e.g. commercial / governmental ERX assignees are not subject to any NRENs' beneficial claims over the address space for whatever reason, then on what basis are you claiming that the NRENs have any beneficial claim over their members' address space? When I was registering address space from the InterNIC in the early 1990s, the address space was registered directly, and it was not done via a local agent (e.g. HEAnet in the case of Ireland). There was a clear understanding in all cases that the address space was registered to the individual assignee regardless of whether the registration was handled directly by the assignee or via a service provider (both HEAnet/as1213 and IEUnet/as2110 provided this service at the time). There was also a clear understanding that this address space would remain with the assignee, where-ever they happened to be connected to. There was no concept that the address space would be anything other than provider independent - in fact the idea was anathema. At least this was the case in Ireland - Israel may have been different, but I see no evidence of it in the email that you received from the DDN-NIC, regardless of talk of "your allotment". It looks much more like IUCC was acting as the equivalent of a modern day National Internet Registry of the form they currently deploy in east asia (which also receives "allocations" from apnic), rather than a pre-RIR-era LIR handling modern style PA address space. Nick From hank at efes.iucc.ac.il Wed Aug 29 02:07:08 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 29 Aug 2012 03:07:08 +0300 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503D442B.9030500@netability.ie> References: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> At 23:20 28/08/2012 +0100, Nick Hilliard wrote: >On 28/08/2012 17:42, Hank Nussbacher wrote: > > DDN.MIL NIC would tend to disagree with your statement (similar emails were > > sent back in the "old" days to most NRENs since we were the Internet > > pioneers): > >Hank, > >Like all windows into the past, the DDN's email prompts more questions than >it answers. > >The thing that immediately jumps out is that if IUCC was acting as a >de-facto national internet registry at the time and registered IP addresses >on behalf of all Israeli users, not just those in the academic community, >then does IUCC maintain some sort of beneficial claim of registration over >subnets of the blocks you list - the sort of claim that would entitle you >to say that because this was IUCC space rather than IUCC member space, that >it really ought to be covered under IUCC's LIR membership for any future >potential argument about a RIPE ERX policy? Only IP space that remains maintained under our LIR/NREN (il.iucc). >E.g. if ECI Telecom or Bezeq (who received 147.234.0.0/8 and 147.235.0.0/8 >respectively, both of which came out of ISRAELB-BLOCK) were to state that >their ERX address blocks belonged absolutely to them and that IUCC had no >claims whatsoever over them, what would IUCC's position be? Since all that IP space is no longer under our LIR, we have no claims to it. We gladly allocated that IP space to them 20+ years ago and those blocks are now listed under different LIRs that have nothing to do wth IUCC. >This is of course a matter for IUCC and ECI Telecom / Bezeq to resolve. >But let's say that IUCC admitted that it had no claim to Bezeq's address >block, then where would IUCC stand on 147.233.0.0/8 which is registered to >the Open University? Would IUCC's position be that this is different just >because they're a member of IUCC. If so, why? Yes, our view is different on that block since it remained as a member of IUCC since the time it was allocated to them. >I can't see any clear >answer here. Maybe you reached an explicit agreement with OpenU about >this, but that would be outside the context of your statement about DDN-NIC >above? > >Alternatively, could IUCC feasibly claim that it had a beneficial interest >in Bezeq's block: 147.235.0.0/8? I really doubt it. We don't have any claim to their /16. >I'm not fishing for answers to these specific questions, btw. I'm >interested in the general issue: who is the ultimate assignee of the ERX >blocks which were handed out via the NRENs and what claims are both they >and the NRENs making over it? My answer would be "Whatever is decided upon by the RIPE membership and not unilaterally by RIPE NCC management". But your initial comment of "On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership." is clearly wrong in many cases since il.iucc has been "footing the bill" for all ERX space listed under its LIR. >And if there is a precedent for tacitly >agreeing that e.g. commercial / governmental ERX assignees are not subject >to any NRENs' beneficial claims over the address space for whatever reason, >then on what basis are you claiming that the NRENs have any beneficial >claim over their members' address space? Because in our case, the members (read universities), are the "owners" of the NREN. Legally speaking. >When I was registering address space from the InterNIC in the early 1990s, >the address space was registered directly, and it was not done via a local >agent (e.g. HEAnet in the case of Ireland). There was a clear >understanding in all cases that the address space was registered to the >individual assignee regardless of whether the registration was handled >directly by the assignee or via a service provider (both HEAnet/as1213 and >IEUnet/as2110 provided this service at the time). There was also a clear >understanding that this address space would remain with the assignee, >where-ever they happened to be connected to. There was no concept that the >address space would be anything other than provider independent - in fact >the idea was anathema. > >At least this was the case in Ireland - Israel may have been different, but >I see no evidence of it in the email that you received from the DDN-NIC, >regardless of talk of "your allotment". It looks much more like IUCC was >acting as the equivalent of a modern day National Internet Registry of the >form they currently deploy in east asia (which also receives "allocations" > from apnic), rather than a pre-RIR-era LIR handling modern style PA >address space. That might be true for the allocation I listed above as an example, but there were other, even larger allocations, that were assigned specifically to IUCC for sub-allocation to its university members. -Hank >Nick From mm at elabnet.de Wed Aug 29 03:06:08 2012 From: mm at elabnet.de (Michael Markstaller) Date: Wed, 29 Aug 2012 03:06:08 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> References: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> Message-ID: <503D6B00.7000605@elabnet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just my 2ct: not any University or worse religous campaign should block a /8 or /16 without having to state HERE&NOW why and for what they really need&use it. They need exactly 1 IP for every 65536 concurrently active student to NAT and 1 for each public service at most, lets put a /22 for infra on top and then we're fine.. We have to do either I guess, at least we do, according to RIPE-policys. So we're playing with different cards here, legacy holders are being asked "what might be a nice proposal they like", I'm not asked what "might be nice for me" Regardless of legal stuff it's IMHO easy, it's basically just unassigned space, its getting routed or -well then- not.. AFAIK there's no global law on which IP's I have to route as ISP.. I don't see any "right" just on the fact address-assignment was done very different and generous 20yrs ago. It was a nice time being able to assign any fridge on the campus an IPv4 but its just over now. Times are changing, legacy resource-holders have to accept that. Done worldwide this would fully obsolete the whole IPv4 address-space discussion for many, many years! IMHO the problem isnt that we dont have enough IPv4 addresses but that thei're unequally distributed and - worse- most of them useless wasted in small networks that claim to be big like universitys just because they "have" them.. In other words, regarding the threads' context: Might sound hard but IMHO legacy resource holders should be given facts they have to agree with or leave (BGP), not nice proposals with "opt-in" wether they want to and "hmm lets talk about a little". Michael - -- Mit freundlichen Gr?ssen Michael Markstaller Elaborated Networks GmbH www.elabnet.de Lise-Meitner-Str. 1, D-85662 Hohenbrunn, Germany fon: +49-8102-8951-60, fax: +49-8102-8951-80 Gesch?ftsf?hrer: Stefan Werner, Michael Markstaller Amtsgericht M?nchen HRB 125120, Ust-ID: DE201281054 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9awAACgkQaWRHV2kMuAKmAgCcDQwkn9xH0g/Ng3Qh5XTVdyND b2MAoJtovdGTag7Njh2XMVro1CuC9Ow0 =RpTC -----END PGP SIGNATURE----- From randy at psg.com Wed Aug 29 03:26:45 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 08:26:45 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> References: <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <503B596D.1090408@netability.ie> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> Message-ID: >> In view of your role as the network coordinator for the universities >> and governmental departments in Israel, we here at the Network >> Information Center feel it would be appropriate if you could serve as >> the IP number delegating authority for the country of Israel. this was far from universal. but the same did happen in za. eventually it drove the za admin, who was not a control freak, nuts and they dumped it all back on postel and later afrinic. randy From mm at elabnet.de Wed Aug 29 03:51:35 2012 From: mm at elabnet.de (Michael Markstaller) Date: Wed, 29 Aug 2012 03:51:35 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503D6B00.7000605@elabnet.de> References: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> Message-ID: <503D75A7.1020105@elabnet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.08.2012 03:06, Michael Markstaller wrote: > or worse religous campaign should Sorry I mixed up iucc with some strange "church" in US, please delete that part.. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9dacACgkQaWRHV2kMuAIfiQCggS9GI/eDvFLwL8kGbP/lsegC KEEAoOfg65TbJazHxBBJuC9SCXkBh5PT =zm8c -----END PGP SIGNATURE----- From gert at space.net Wed Aug 29 11:05:08 2012 From: gert at space.net (Gert Doering) Date: Wed, 29 Aug 2012 11:05:08 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503D6B00.7000605@elabnet.de> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> Message-ID: <20120829090508.GQ13776@Space.Net> Hi, On Wed, Aug 29, 2012 at 03:06:08AM +0200, Michael Markstaller wrote: > Just my 2ct: not any University or worse religous campaign should > block a /8 or /16 without having to state HERE&NOW why and for what > they really need&use it. > They need exactly 1 IP for every 65536 concurrently active student to > NAT and 1 for each public service at most, lets put a /22 for infra on > top and then we're fine.. This is not how the old Internet used to work, and it is not how it works today - nobody is forced to use NAT by the RIRs, and that's how it must be (*and* it has nothing to do with the question of ERX space governance whatsoever). > We have to do either I guess, at least we do, according to > RIPE-policys. So we're playing with different cards here, legacy > holders are being asked "what might be a nice proposal they like", I'm > not asked what "might be nice for me" ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space (and even *then*, there would not be any RIPE policy forcing a user of IP address space to use NAT if they do not want to). [..] > Done worldwide this would fully obsolete the whole IPv4 address-space > discussion for many, many years! It would solve nothing. If people insist on cementing their IPv4 world for a few more years, they would have *more* stuff to move to IPv6 in the long run - nothing solved. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jim at rfc1035.com Wed Aug 29 11:18:57 2012 From: jim at rfc1035.com (Jim Reid) Date: Wed, 29 Aug 2012 10:18:57 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120829090508.GQ13776@Space.Net> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> Message-ID: <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> On 29 Aug 2012, at 10:05, Gert Doering wrote: > ERX space has not been given out under RIPE policies, so they do not > apply. Period. There is no law, legal contract, or anything else > that > would make RIPE policies automagically apply to ERX space +1000. It's a great pity the recent policy proposal doesn't use those very words. From randy at psg.com Wed Aug 29 11:28:23 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 16:28:23 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> Message-ID: > It's a great pity the recent policy proposal doesn't use those very > words. the forces of anti-terseness prevailed :) actually, i suspect it was an attempt at softer manners. randy From ripe-wgs.cs at schiefner.de Wed Aug 29 11:22:40 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 29 Aug 2012 11:22:40 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> Message-ID: <503DDF60.8090602@schiefner.de> On 29.08.2012 11:18, Jim Reid wrote: > On 29 Aug 2012, at 10:05, Gert Doering wrote: >> ERX space has not been given out under RIPE policies, so they do not >> apply. Period. There is no law, legal contract, or anything else that >> would make RIPE policies automagically apply to ERX space > > +1000. Me too. > It's a great pity the recent policy proposal doesn't use those very words. Sneak it in as soon as it's formally up. :-) Best, -C. From randy at psg.com Wed Aug 29 12:07:14 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 17:07:14 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DDF60.8090602@schiefner.de> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DDF60.8090602@schiefner.de> Message-ID: naive question before we switch terms. is erx == legacy i.e. pre-ncc? no strange corner cases? randy From sander at steffann.nl Wed Aug 29 12:07:36 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 29 Aug 2012 12:07:36 +0200 Subject: [ncc-services-wg] ERX transfer agreement with Internet In-Reply-To: <50368960.8000704@netability.ie> References: <50368960.8000704@netability.ie> Message-ID: <3665B627-4102-4E73-8D10-E100219230CB@steffann.nl> Hi, > could someone point me in the direction of the InterNIC->RIPE NCC ERX > transfer agreement, if this exists? Any other XYZ->RIPE NCC ERX transfer agreements those would also be very much appreciated. Thanks, Sander From nigel at titley.com Wed Aug 29 12:08:27 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 11:08:27 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> Message-ID: <503DEA1B.4030602@titley.com> On 29/08/2012 10:18, Jim Reid wrote: > On 29 Aug 2012, at 10:05, Gert Doering wrote: > >> ERX space has not been given out under RIPE policies, so they do not >> apply. Period. There is no law, legal contract, or anything else that >> would make RIPE policies automagically apply to ERX space > > +1000. > > It's a great pity the recent policy proposal doesn't use those very > words. > > This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? Nigel From randy at psg.com Wed Aug 29 12:14:41 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 17:14:41 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: > if RIPE policy doesn't apply to legacy space, why are the legacy > holders raising a proposal at all? because the founding fathers and mothers, who have been quietly minding their own business for a couple of decades received nasty letters from the ncc? because the founding partents actually are trying to be part of the family of their children and grandchildren? randy From nick at netability.ie Wed Aug 29 12:14:01 2012 From: nick at netability.ie (Nick Hilliard) Date: Wed, 29 Aug 2012 11:14:01 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> References: <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> Message-ID: <503DEB69.9000107@netability.ie> Hank, On 29/08/2012 01:07, Hank Nussbacher wrote: > At 23:20 28/08/2012 +0100, Nick Hilliard wrote: >> then does IUCC maintain some sort of beneficial claim of registration over >> subnets of the blocks you list - the sort of claim that would entitle you >> to say that because this was IUCC space rather than IUCC member space, that >> it really ought to be covered under IUCC's LIR membership for any future >> potential argument about a RIPE ERX policy? > > Only IP space that remains maintained under our LIR/NREN (il.iucc). It is not maintained under il.iucc, because il.iucc is a legal construct which exists between the RIPE NCC and IUCC. The only address space managed by il.iucc is 2001:0bf8::/32. Any other address space handled by IUCC have is either ERX or outside the scope of the RIPE NCC. [...] > My answer would be "Whatever is decided upon by the RIPE membership and not > unilaterally by RIPE NCC management". But your initial comment of "On the > one hand, ERX holders obtained address space without a governing contract > and have been enjoying the benefits of this for many years. On the other > hand, someone is footing the bill for the maintenance and upkeep of this > registration data - namely the RIPE NCC membership." is clearly wrong in > many cases since il.iucc has been "footing the bill" for all ERX space > listed under its LIR. Not really, no. The entry in alloclist.txt for il.iucc is: > il.iucc > IUCC - Israel InterUniversity Computation Center > > 20030508 2001:0bf8::/32 > There's no mention of any ipv4 address space, and il.iucc is categorised as "extra small". I cannot see how this means that il.iucc is footing the bill for maintenance of the registry entries any more than every other RIPE NCC member is. >> And if there is a precedent for tacitly >> agreeing that e.g. commercial / governmental ERX assignees are not subject >> to any NRENs' beneficial claims over the address space for whatever reason, >> then on what basis are you claiming that the NRENs have any beneficial >> claim over their members' address space? > > Because in our case, the members (read universities), are the "owners" of > the NREN. Legally speaking. I understand the distinction - I've been working with member-owned organisations for a long time. However legally speaking, the assets of a member-owned organisation are owned by that organisation, not by the members. The organisation as a whole belongs to the members. Do I have a right to take Axel Pawlik's laptop? He works for the RIPE NCC, and ie.netability is a member of the RIPE NCC, and I own ie.netability. Based on your assertion, I might have some sort of claim to taking it, but the legal reality is that I have no claim whatsoever. Let me put it another way: what would happen if a member were to leave your NREN? Does IUCC stake its claim on the addresses at that point or not? And if not, then on what basis do you stake any claim on the IP address space now? And as a secondary issue (to ownership, but not to the point you were originally making), if you are not staking a claim on beneficial interest in the address space now, then why are you claiming that they should just be bundled in as something similar to ALLOCATED PA address space from the point of view of your LIR membership in any future agreement with the RIPE NCC - except that you're also claiming in the policy document that it shouldn't be counted towards a LIR allocation, but should be charged as strictly less than a PI assignment per block. Hank, I'm not trying to be confrontational here. There's an important issue which I'm trying to get to the bottom of, namely the issue of where the rights and responsibilities lie between the address assignees and their historical registrars. So far I've seen nothing to suggest that the registrars have any sort of reasonable claim to the address space other; nor have I seen any indication that the assignees have given informed consent to these claims. These are important issues because they are pretty much guaranteed to become problems in situations of changes of circumstance (potentially such as this one). Nick From ripe-wgs.cs at schiefner.de Wed Aug 29 12:18:36 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 29 Aug 2012 12:18:36 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: <503DEC7C.7020301@schiefner.de> Hi Nigel, On 29.08.2012 12:08, Nigel Titley wrote: > This actually raises an interesting issue. Are there any circumstances > in which RIPE policy would apply to legacy space? Could, for example, > the AP-WG unilaterally propose a policy that annexed legacy space? I've > heard this suggested several times. And of course, if RIPE policy > doesn't apply to legacy space, why are the legacy holders raising a > proposal at all? maybe it should be looked at the other way round: that legacy space holders as good netizens want to unilaterally move this address space under a policy, given that the policy serves their needs and views? Best, Carsten From sander at steffann.nl Wed Aug 29 12:19:59 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 29 Aug 2012 12:19:59 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: Hi Nigel, > This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? IANAL, but I think that would not be legally possible. > I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? If it was about address policy I would have definitely pulled the proposal towards APWG. This is about the RIPE NCC providing services like the RIPE database and reverse DNS. That is why this policy proposal is in the NCC-Services WG. - Sander From nigel at titley.com Wed Aug 29 12:21:00 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 11:21:00 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: <503DED0C.50809@titley.com> On 29/08/2012 11:14, Randy Bush wrote: >> if RIPE policy doesn't apply to legacy space, why are the legacy >> holders raising a proposal at all? > because the founding fathers and mothers, who have been quietly minding > their own business for a couple of decades received nasty letters from > the ncc? The person at the NCC who sent those letters has had a sharp kick up the posterior. > > because the founding partents actually are trying to be part of the > family of their children and grandchildren? Indeed... but I was asking a more fundamental question. If the PDP has no jurisdiction over the legacy holders then why are the legacy holders invoking a process which they are avowing has no jurisdiction over them? Please understand this is a somewhat mischievious question, but one that I feel needs to be answered. Nigel > > randy From gert at space.net Wed Aug 29 12:21:35 2012 From: gert at space.net (Gert Doering) Date: Wed, 29 Aug 2012 12:21:35 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: <20120829102135.GS13776@Space.Net> Hi, On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote: > This actually raises an interesting issue. Are there any circumstances > in which RIPE policy would apply to legacy space? Could, for example, > the AP-WG unilaterally propose a policy that annexed legacy space? I don't think so. APWG policy governs under which rules the RIPE NCC gives out (and possible takes back from) internet numbers from the RIPE NCC "pool" to "consumers" - and this sort of obviously only applies to numbers that the RIPE NCC has been given authority over, via the IETF->IANA->RIPE NCC chain of delegation. > I've heard this suggested several times. And of course, if RIPE policy > doesn't apply to legacy space, why are the legacy holders raising a > proposal at all? Now, the RIPE NCC provides services to legacy address space holders that happen to be in the RIPE service region: - RIPE database and routing registry "who 'owns' it and who is authorized to announce it?" - reverse DNS delegation - potentially: RPKI certificates due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view. OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ). Now, the policy proposal raised here is not an *address space* policy proposal, but an *ncc service* policy proposal - which governs the way the NCC runs their, uh, services. And I think this is a reasonable approach - find something that the ERX holder community and the RIPE NCC is happy with, walk it through an open consensus process, and then nobody can argue that the RIPE NCC is going out and bullying/blackmailing ERX holders over their addresses... (As far as I understand the system, the ERX space would still not be part of the "normal" APWG policy regime - like "RIPE *address* policies have no influence on how the addresses are distributed by the holder's organizationo to 3rd parties" and "no audits", etc.) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From pk at DENIC.DE Wed Aug 29 12:29:09 2012 From: pk at DENIC.DE (Peter Koch) Date: Wed, 29 Aug 2012 12:29:09 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DDF60.8090602@schiefner.de> Message-ID: <20120829102909.GJ2326@x28.adm.denic.de> On Wed, Aug 29, 2012 at 05:07:14PM +0700, Randy Bush wrote: > naive question before we switch terms. is > > erx == legacy > > i.e. pre-ncc? no strange corner cases? I'd guess there are corner cases if you take 'pre ncc' literally. 1992/3 there were 'registries of last resort' and I'm not sure those pools were solely filled by the NCC. There was also a famous, then, /8 assignment, the mechanics of which would be interesting to research. -Peter From cfriacas at fccn.pt Wed Aug 29 12:30:24 2012 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 29 Aug 2012 11:30:24 +0100 (WEST) Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120829102135.GS13776@Space.Net> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <20120829102135.GS13776@Space.Net> Message-ID: Fully agree! Having a policy in place for services, will improve access to legacy holders, but won't force *all* legacy holders to use those services... Regards, Carlos On Wed, 29 Aug 2012, Gert Doering wrote: > Hi, > > On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote: >> This actually raises an interesting issue. Are there any circumstances >> in which RIPE policy would apply to legacy space? Could, for example, >> the AP-WG unilaterally propose a policy that annexed legacy space? > > I don't think so. > > APWG policy governs under which rules the RIPE NCC gives out (and possible > takes back from) internet numbers from the RIPE NCC "pool" to "consumers" > - and this sort of obviously only applies to numbers that the RIPE NCC has > been given authority over, via the IETF->IANA->RIPE NCC chain of delegation. > > >> I've heard this suggested several times. And of course, if RIPE policy >> doesn't apply to legacy space, why are the legacy holders raising a >> proposal at all? > > Now, the RIPE NCC provides services to legacy address space holders that > happen to be in the RIPE service region: > > - RIPE database and routing registry > "who 'owns' it and who is authorized to announce it?" > - reverse DNS delegation > - potentially: RPKI certificates > > due to the way RPSL-authentication and DNS tree'ing work, this is not > easy to do in a non-hierarchical structure, so "having this done by > the RIPE NCC" makes sense from a technical point of view. > > OTOH, I can see that the NCC wants to see some money in exchange for > the expenses running all this (and that seems to make sense as well :-) ). > > > Now, the policy proposal raised here is not an *address space* policy > proposal, but an *ncc service* policy proposal - which governs the way > the NCC runs their, uh, services. And I think this is a reasonable > approach - find something that the ERX holder community and the RIPE > NCC is happy with, walk it through an open consensus process, and then > nobody can argue that the RIPE NCC is going out and bullying/blackmailing > ERX holders over their addresses... > > (As far as I understand the system, the ERX space would still not be > part of the "normal" APWG policy regime - like "RIPE *address* policies > have no influence on how the addresses are distributed by the holder's > organizationo to 3rd parties" and "no audits", etc.) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > From cfriacas at fccn.pt Wed Aug 29 12:22:14 2012 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 29 Aug 2012 11:22:14 +0100 (WEST) Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: On Wed, 29 Aug 2012, Nigel Titley wrote: > On 29/08/2012 10:18, Jim Reid wrote: >> On 29 Aug 2012, at 10:05, Gert Doering wrote: >> >>> ERX space has not been given out under RIPE policies, so they do not >>> apply. Period. There is no law, legal contract, or anything else that >>> would make RIPE policies automagically apply to ERX space >> >> +1000. >> >> It's a great pity the recent policy proposal doesn't use those very words. >> >> > This actually raises an interesting issue. Are there any circumstances in > which RIPE policy would apply to legacy space? > Could, for example, the AP-WG > unilaterally propose a policy that annexed legacy space? Hello, I don't think so. Don't you think some court actions would immediately follow...? > I've heard this > suggested several times. And of course, if RIPE policy doesn't apply to > legacy space, why are the legacy holders raising a proposal at all? "services to" seems to be the key part... :-) Regards, Carlos Fria?as > Nigel > From jim at rfc1035.com Wed Aug 29 12:47:01 2012 From: jim at rfc1035.com (Jim Reid) Date: Wed, 29 Aug 2012 11:47:01 +0100 Subject: [ncc-services-wg] policy proposals for ERX holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: On 29 Aug 2012, at 11:08, Nigel Titley wrote: > Are there any circumstances in which RIPE policy would apply to > legacy space? Could, for example, the AP-WG unilaterally propose a > policy that annexed legacy space? One of the features of our slice of the Internet governance circus is anyone can propose anything. So of course such a policy can be proposed. It might even emerge unscathed from the PDP some time before the heat death of the universe. However that policy would almost certainly face challenges in the courts and lose. > And of course, if RIPE policy doesn't apply to legacy space, why are > the legacy holders raising a proposal at all? I think this is an example of getting your retaliation in first. :-) If the legacy holders can shove something about ERX space through the policy-making machinery, it may well prevent others from filling that vacuum with a more unpleasant policy. From randy at psg.com Wed Aug 29 13:07:47 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 18:07:47 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120829102909.GJ2326@x28.adm.denic.de> References: <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DDF60.8090602@schiefner.de> <20120829102909.GJ2326@x28.adm.denic.de> Message-ID: >> naive question before we switch terms. is >> erx == legacy >> i.e. pre-ncc? no strange corner cases? > I'd guess there are corner cases if you take 'pre ncc' literally. > 1992/3 there were 'registries of last resort' and I'm not sure those > pools were solely filled by the NCC. There was also a famous, then, > /8 assignment, the mechanics of which would be interesting to > research. i think we need to agree on a noun to denote exactly those allocations which were issued pre-ncc and are currently outside the ncc membership and policy space. because arin does not have erx space per se, i am used to the term 'legacy' but am happy with anything. randy From nick at netability.ie Wed Aug 29 13:09:59 2012 From: nick at netability.ie (Nick Hilliard) Date: Wed, 29 Aug 2012 12:09:59 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: <503DF887.9060305@netability.ie> On 29/08/2012 11:08, Nigel Titley wrote: > This actually raises an interesting issue. Are there any circumstances in > which RIPE policy would apply to legacy space? Could, for example, the > AP-WG unilaterally propose a policy that annexed legacy space? I've heard > this suggested several times. And of course, if RIPE policy doesn't apply > to legacy space, why are the legacy holders raising a proposal at all? RIPE policies do not apply to ERX address space - there is no real argument about this. However, we have an immediate operational problem caused by the fact that the RIPE NCC has withdrawn the ability for ERX holders to make updates to their address blocks. We got here because some people decided to pass the can from ddn / internic / arin to the RIPE NCC due to geographical considerations. Now that the RIPE NCC has been landed with this mess, they felt that there is a requirement to do something about it rather than let it sit there and fester due to hijacking / illegal transfers. I can see a lot of operational and legal reasons that the NCC blocked updates to the space, even though they were given no direct mandate to do this from the RIPE community. So the issue is really a question of balancing the rights and responsibilities of both the RIPE NCC and the ERX holders. This is why I asked last week if there was an agreement in place between the InterNIC and the RIPE NCC for handling the ERX transfers - if there was a formal agreement in place, then it needs to be given serious consideration when the RIPE community forms a new policy for the RIPE NCC which can be applied to the address space, because the terms of that agreement may still be binding on the RIPE NCC. If there was no agreement in place, then more options are open. Basing a policy on "annexing legacy space" is a red herring. Tut, tut, naughty Nigel. What isn't a red herring is the notion of creating a policy which accepts and understands the requirement of a quid pro quo between the ERX holders and the RIPE NCC. This principal is notably absent in the pre-publication proposal that Niall emailed to the list a couple of days ago, and without prejudice to that document, it is a principal which I suspect would radically change the conclusions of any such proposal. Nick From nigel at titley.com Wed Aug 29 13:09:57 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 12:09:57 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DDF60.8090602@schiefner.de> <20120829102909.GJ2326@x28.adm.denic.de> Message-ID: <503DF885.8050905@titley.com> On 29/08/2012 12:07, Randy Bush wrote: >>> naive question before we switch terms. is >>> erx == legacy >>> i.e. pre-ncc? no strange corner cases? >> I'd guess there are corner cases if you take 'pre ncc' literally. >> 1992/3 there were 'registries of last resort' and I'm not sure those >> pools were solely filled by the NCC. There was also a famous, then, >> /8 assignment, the mechanics of which would be interesting to >> research. > i think we need to agree on a noun to denote exactly those allocations > which were issued pre-ncc and are currently outside the ncc membership > and policy space. > > because arin does not have erx space per se, i am used to the term > 'legacy' but am happy with anything. > > I think pretty well everyone is happy with "legacy", apart from maybe Jim :-) Nigel From randy at psg.com Wed Aug 29 13:12:36 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 18:12:36 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DED0C.50809@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DED0C.50809@titley.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>> if RIPE policy doesn't apply to legacy space, why are the legacy >>> holders raising a proposal at all? >> because the founding partents actually are trying to be part of the >> family of their children and grandchildren? > Indeed... but I was asking a more fundamental question. If the PDP has > no jurisdiction over the legacy holders then why are the legacy > holders invoking a process which they are avowing has no jurisdiction > over them? the pdp may have no current juristiction. but what is attempting to be negotiated is for the pdp to have juristiction. do you have a suggestion for a different approach/venue? > Please understand this is a somewhat mischievious question, but one that > I feel needs to be answered. all taken in good humor and assuming good intent. we have a wonderful opportunity to take the high ground here, maintain humor, assume the best of intent, and set a civilized example. randy, pgp signing because some will not believe i wrote that :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Processed by Mailcrypt 3.5.8 iQEcBAEBCgAGBQJQPfkdAAoJEMzMBey4OgLtPt0IAKUj1JjtfD9qIAmldYue94bO FgRooqSYvJQn5y5kSuA5+7fqr/r/DK3Si17tWQy7qVSBHoH5eVhwOn5XmxInYWNt JnxJn09keIxInpC8yNKTktMuvtK45jWGPEnWw1qhgfDyWYdYE7hwH9HRcEY/egbo IQrnfR1P45P+fD7197fFlBv0YQoGBKMn2ElBgf0e4QmUfs+isKIJ7KWa9+5qT+Bt NdjEgsF9IB7w+r4RmDD/uRe7p5HCuKJ7VkRTCImGXhiVNF7+cHenM8nIztZhpEbj Hou3VBeDvA1aWTxiRqdX3nItTPH6S6pI36JvRvBs2v2ZmEN2QH381ggu1aYd/68= =xLHU -----END PGP SIGNATURE----- From nigel at titley.com Wed Aug 29 13:19:46 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 12:19:46 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DF887.9060305@netability.ie> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DF887.9060305@netability.ie> Message-ID: <503DFAD2.3050906@titley.com> On 29/08/2012 12:09, Nick Hilliard wrote: > On 29/08/2012 11:08, Nigel Titley wrote: >> This actually raises an interesting issue. Are there any circumstances in >> which RIPE policy would apply to legacy space? Could, for example, the >> AP-WG unilaterally propose a policy that annexed legacy space? I've heard >> this suggested several times. And of course, if RIPE policy doesn't apply >> to legacy space, why are the legacy holders raising a proposal at all? > RIPE policies do not apply to ERX address space - there is no real argument > about this. > > However, we have an immediate operational problem caused by the fact that > the RIPE NCC has withdrawn the ability for ERX holders to make updates to > their address blocks. We got here because some people decided to pass the > can from ddn / internic / arin to the RIPE NCC due to geographical > considerations. Now that the RIPE NCC has been landed with this mess, they > felt that there is a requirement to do something about it rather than let > it sit there and fester due to hijacking / illegal transfers. I can see a > lot of operational and legal reasons that the NCC blocked updates to the > space, even though they were given no direct mandate to do this from the > RIPE community. Can we get this straight please. The RIPE NCC has *not* withdrawn ability for ERX holders to make updates to their address block, neither has it withdrawn reverse DNS service. Letters to that effect were sent to a number of legacy holders but were issued in error due to a miscommunication within the RIPE NCC and were withdrawn. If anyone still has no access to their database records then this is an operational error and it should be reported through the usual channels. We now have the opportunity to get this whole thing straightened out, with a proper mandate from the community. That is what this whole proposal is about. > > So the issue is really a question of balancing the rights and > responsibilities of both the RIPE NCC and the ERX holders. This is why I > asked last week if there was an agreement in place between the InterNIC and > the RIPE NCC for handling the ERX transfers - if there was a formal > agreement in place, then it needs to be given serious consideration when > the RIPE community forms a new policy for the RIPE NCC which can be applied > to the address space, because the terms of that agreement may still be > binding on the RIPE NCC. If there was no agreement in place, then more > options are open. I'll be surprised if there was no agreement. Can someone from the RIPE NCC comment? > > Basing a policy on "annexing legacy space" is a red herring. Tut, tut, > naughty Nigel. As I said that was a little mischievious, but it has led to considerable clarification of what is being done here. > What isn't a red herring is the notion of creating a policy which accepts > and understands the requirement of a quid pro quo between the ERX holders > and the RIPE NCC. This principal is notably absent in the pre-publication > proposal that Niall emailed to the list a couple of days ago, and without > prejudice to that document, it is a principal which I suspect would > radically change the conclusions of any such proposal. > I agree fully with this and I hope that this clarification will emerge during the discussion phase of the proposal. Nigel From randy at psg.com Wed Aug 29 13:25:04 2012 From: randy at psg.com (Randy Bush) Date: Wed, 29 Aug 2012 18:25:04 +0700 Subject: [ncc-services-wg] policy proposals for ERX holders In-Reply-To: References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: > One of the features of our slice of the Internet governance circus is > anyone can propose anything. thank you dr manning From nick at netability.ie Wed Aug 29 13:24:49 2012 From: nick at netability.ie (Nick Hilliard) Date: Wed, 29 Aug 2012 12:24:49 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DFAD2.3050906@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DF887.9060305@netability.ie> <503DFAD2.3050906@titley.com> Message-ID: <503DFC01.5060706@netability.ie> On 29/08/2012 12:19, Nigel Titley wrote: > Can we get this straight please. The RIPE NCC has *not* withdrawn ability > for ERX holders to make updates to their address block, neither has it > withdrawn reverse DNS service. Letters to that effect were sent to a number > of legacy holders but were issued in error due to a miscommunication within > the RIPE NCC and were withdrawn. If anyone still has no access to their > database records then this is an operational error and it should be > reported through the usual channels. ah, good. I was not aware that this was the situation. Nick From nigel at titley.com Wed Aug 29 13:43:44 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 12:43:44 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120829102135.GS13776@Space.Net> References: <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <20120829102135.GS13776@Space.Net> Message-ID: <503E0070.8020804@titley.com> Gert, As usual you've done your excellent analysis and statement On 29/08/2012 11:21, Gert Doering wrote: > Hi, > > On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote: >> This actually raises an interesting issue. Are there any circumstances >> in which RIPE policy would apply to legacy space? Could, for example, >> the AP-WG unilaterally propose a policy that annexed legacy space? > > I don't think so. > > APWG policy governs under which rules the RIPE NCC gives out (and possible > takes back from) internet numbers from the RIPE NCC "pool" to "consumers" > - and this sort of obviously only applies to numbers that the RIPE NCC has > been given authority over, via the IETF->IANA->RIPE NCC chain of delegation. Good.... and presumably the legacy holders could voluntarily agree to submit to address policy, although it would seem that section 6.3 of the proposed policy limits the actions of legacy holders in this respect and indeed it attempts to place bounds on the authority of the community itself for all time (which always gives me pause for thought). > >> I've heard this suggested several times. And of course, if RIPE policy >> doesn't apply to legacy space, why are the legacy holders raising a >> proposal at all? > Now, the RIPE NCC provides services to legacy address space holders that > happen to be in the RIPE service region: > > - RIPE database and routing registry > "who 'owns' it and who is authorized to announce it?" > - reverse DNS delegation > - potentially: RPKI certificates > > due to the way RPSL-authentication and DNS tree'ing work, this is not > easy to do in a non-hierarchical structure, so "having this done by > the RIPE NCC" makes sense from a technical point of view. > > OTOH, I can see that the NCC wants to see some money in exchange for > the expenses running all this (and that seems to make sense as well :-) ). Yes, and bear in mind ultimately the RIPE NCC membership should be consulted about this. It's their money providing the service. > > Now, the policy proposal raised here is not an *address space* policy > proposal, but an *ncc service* policy proposal - which governs the way > the NCC runs their, uh, services. And I think this is a reasonable > approach - find something that the ERX holder community and the RIPE > NCC is happy with, walk it through an open consensus process, and then > nobody can argue that the RIPE NCC is going out and bullying/blackmailing > ERX holders over their addresses... I agree completely with this. This is obvious the best approach, but I still have some reservations about the wording of the proposal as so far seen. Perhaps when it is formally published we could discuss this. > > (As far as I understand the system, the ERX space would still not be > part of the "normal" APWG policy regime - like "RIPE *address* policies > have no influence on how the addresses are distributed by the holder's > organizationo to 3rd parties" and "no audits", etc.) > Yes, and this proposal explicitly says that this will be the case for all time. Nigel From nigel at titley.com Wed Aug 29 13:47:20 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 12:47:20 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DED0C.50809@titley.com> Message-ID: <503E0148.8030806@titley.com> On 29/08/2012 12:12, Randy Bush wrote: > the pdp may have no current juristiction. but what is attempting to be > negotiated is for the pdp to have juristiction. do you have a > suggestion for a different approach/venue? Now this is starting to make sense. In which case I think we need to have a little reworking of the proposal. >> Please understand this is a somewhat mischievious question, but one that >> I feel needs to be answered. > all taken in good humor and assuming good intent. we have a wonderful > opportunity to take the high ground here, maintain humor, assume the > best of intent, and set a civilized example. Yes, and I'd like us to succeed. I think everyone here owes a great debt to the legacy holders (and bear in mind that I was one). Without their work we'd be wallowing in an OSI mess built on top of X25. > > randy, pgp signing because some will not believe i wrote that :) I can't think why :-) Nigel From nigel at titley.com Wed Aug 29 13:59:45 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 29 Aug 2012 12:59:45 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEC7C.7020301@schiefner.de> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DEC7C.7020301@schiefner.de> Message-ID: <503E0431.80506@titley.com> On 29/08/2012 11:18, Carsten Schiefner wrote: > Hi Nigel, > > On 29.08.2012 12:08, Nigel Titley wrote: >> This actually raises an interesting issue. Are there any circumstances >> in which RIPE policy would apply to legacy space? Could, for example, >> the AP-WG unilaterally propose a policy that annexed legacy space? I've >> heard this suggested several times. And of course, if RIPE policy >> doesn't apply to legacy space, why are the legacy holders raising a >> proposal at all? > > maybe it should be looked at the other way round: that legacy space > holders as good netizens want to unilaterally move this address space > under a policy, given that the policy serves their needs and views? Well, actually the proposal explicitly precludes moving the address space under normal address policy. It explicitly says that "...[such future revisions] must never restrict the rights of Legacy Resource Holders to their legacy resources." Nigel From ripe-wgs.cs at schiefner.de Wed Aug 29 14:09:03 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 29 Aug 2012 14:09:03 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E0431.80506@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DEC7C.7020301@schiefner.de> <503E0431.80506@titley.com> Message-ID: <503E065F.6080307@schiefner.de> Hi Nigel, On 29.08.2012 13:59, Nigel Titley wrote: >> maybe it should be looked at the other way round: that legacy space >> holders as good netizens want to unilaterally move this address space >> under a policy, given that the policy serves their needs and views? > Well, actually the proposal explicitly precludes moving the address > space under normal address policy. It explicitly says that "...[such > future revisions] must never restrict the rights of Legacy Resource > Holders to their legacy resources." that is why I wrote "under _A_ policy" - that doesn't necessarily mean normal address policy. :-) Best, -C. From sander at steffann.nl Wed Aug 29 14:10:59 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 29 Aug 2012 14:10:59 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E0431.80506@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DEC7C.7020301@schiefner.de> <503E0431.80506@titley.com> Message-ID: <5FC54260-B582-42D7-B6BB-7DABA0AC1715@steffann.nl> Hi, > Well, actually the proposal explicitly precludes moving the address space under normal address policy. I think that when a legacy resource holder wants to be treated as a normal LIR and wants their resources to be treated as non-legacy resources then that should be possible. Once they choose to do that all normal policies start to apply. Sander From Niall.oReilly at ucd.ie Wed Aug 29 14:58:53 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 29 Aug 2012 13:58:53 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DFAD2.3050906@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DF887.9060305@netability.ie> <503DFAD2.3050906@titley.com> Message-ID: <8FE0D343-F123-416F-AF48-A3FD1E25FBD0@ucd.ie> On 29 Aug 2012, at 12:19, Nigel Titley wrote: > We now have the opportunity to get this whole thing straightened out, with a proper mandate from the community. > That is what this whole proposal is about. Absolutely! /Niall From Niall.oReilly at ucd.ie Wed Aug 29 15:18:49 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 29 Aug 2012 14:18:49 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEA1B.4030602@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> Message-ID: <9646D278-D964-496B-AED4-224BB17A9005@ucd.ie> On 29 Aug 2012, at 11:08, Nigel Titley wrote: > Are there any circumstances in which RIPE policy would apply to legacy space? I guess there could be, but we don't have them yet. I expect that achieving such circumstances will require us all to give more than usual care to how we understand "consensus" and "fairness". For avoidance of doubt, I'm not claiming to have done this yet. 8-) /Niall From daniel.karrenberg at ripe.net Wed Aug 29 16:37:07 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 29 Aug 2012 16:37:07 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5FC54260-B582-42D7-B6BB-7DABA0AC1715@steffann.nl> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DEC7C.7020301@schiefner.de> <503E0431.80506@titley.com> <5FC54260-B582-42D7-B6BB-7DABA0AC1715@steffann.nl> Message-ID: <60942F08-C210-400C-8E23-12E8461612D9@ripe.net> [This is said on personal title of someone involved with Internet Number Registration for quite some time.] Can we take a step back agree on definitions and community goals before we continue this discussion? In my book the community goals for IPv4 address space registration are a correct, current and comprehensive registry of who hold/uses the address space. Rob Blokzijl has written this up nicely in ripe-495 with a little help from yours truly. Now that the times of distributing from the unallocated pool of iPv4 addresses are coming to an end, it becomes even more important to maintain such a registry and to make it attractive for address space holders/users to maintain it. Should we fail to maintain such a registry, the consequences range from making it more difficult to track down criminals via hampering operational coordination to balkanisation of the IPv4 Internet. I am sure that participants on this list understand that a bad registry is harmful to them and the community at large. ripe-495 proposes principles for registration policies. Go read it. It is only three pages long and starts from scratch. Philosophically there are multiple ways to legitimise a registry of IP number resources: one may argue that registration authority passes down from the IANA or one can argue that the authority is derived bottom-up from the participants in inter-domain routing or one can argue that it is the RIPE community with its open, transparent and accessible processes that legitimises the RIPE NCC registry. Personally I consider a mixture of these factors to define the de-facto legitimacy of the RIR registries. In practice there is consensus that RIR policies govern registration of the address space that has been distributed via the RIRs. This also includes that changes to RIR policies apply to all such address space. The policies are maintained in an open, transparent and accessible way. The policies are implemented by the RIRs in a professional and neutral way. This is governed by formal agreements between the LIRS/PI holders and the RIR and then transitively down from the LIRs. All this provides security and stability to address space holders/users as well as a correct, current and comprehensive registry to everyone. Then there is "legacy" address space from before the establishment of the RIRs and their policy processes. The registration goals also apply to this address space. However there are no formal agreements and no formal policies. Registrations for much of this address space are also less correct, current and comprehensive than non-legacy registrations. I do not at all critisise those responsible at the time! Quite the opposite. They were providing a community service with little means and in-lieu of doing more exiting things. A small fraction of the IPv4 address space is their "legacy". Please do not confuse legacy space with ERX space. See the post-scriptum for an explanation of ERX space. In order to keep the IPv4 registry comprehensive, current and correct, the RIRs have always encouraged legacy address holder/users to register their address space. The RIRs are also cooperating to reach these goals for legacy address space, see the post-scriptum for an example. The RIPE community has carefully avoided to make legacy address space subject to address space *distribution* policies, such as utilisation criteria. However *registration* policies have been applied to any registrations made as far as the technical operation of the registry is concerned. The community regards good registration to be more important than recovering some address space that might be under-used according to current policies. So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less. All other questions are secondary. Resolving conflicts about the holdership/use of the address space is a non issue. Past agreements about allocation of address space are a non issue. Future agreements about transfers are a non-issue. If there is a conflict about who holds/uses address space, then we need to decide what to do in terms of registration. We can decide to help resolving conflictes, but that is another matter. In my opinion looking for past agreements concerning legacy address space between registrants and IANA or "INTERNIC", "SRI-NIC" or Santa Claus is a waste of time. We have to decide what we register. ripe-495 gives guidance about registration policies, also for legacy space. Let us work with that guidance in mind to define under which conditions registrations for legacy address space should be made and maintained in the RIPE Internet Number registry. Let us not waste time with arguments that are not helpful to make that decision. Daniel PS: Early this century the RIRs, on request of their communities, set up an activity to make registration of legacy address space more correct, current and comprehensive. It was called ERX (Early Registration Transfers). Its stated goal was to move existing registrations of legacy address space to a RIR that was close to the user and verify those registrations at the same time. Goal: correct any errors, get current information registered, make the registries more comprehensive and make it easier to maintain the registrations: "This will enable resource holders to maintain all their records in one database and End Users to interface with just one RIR for all database and reverse delegation matters. This effort will also help to locate address holders and recover unused or underutilised address space." It was explicitly not a goal of ERX to bring the legacy space under the RIR policies in any other respect than those governing the technical operation of the registry. It was stated however that ERX registration holders might be asked to share the operational costs of the registry should the community decide that at a future time. All this has been communicated and discussed by the community at the time. In practice most legacy space was registered with ARIN since ARIN had inherited the registration database from the legacy days and most of those were in use in the ARIN region. So ERX moved registrations from ARIN to other RIRs, mostly to the RIPE NCC. The address space covered by ERX registration transfers is called ERX space. It is only part of the total legacy space. ERX space is the part of legacy space for which registrations have been transferred between RIRs as part of ERX. From daniel.karrenberg at ripe.net Wed Aug 29 17:16:54 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 29 Aug 2012 17:16:54 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DFAD2.3050906@titley.com> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DF887.9060305@netability.ie> <503DFAD2.3050906@titley.com> Message-ID: On 29.08.2012, at 13:19 , Nigel Titley wrote: >> On 29/08/2012 12:09, Nick Hilliard wrote: >> So the issue is really a question of balancing the rights and >> responsibilities of both the RIPE NCC and the ERX holders. This is why I >> asked last week if there was an agreement in place between the InterNIC and >> the RIPE NCC for handling the ERX transfers - if there was a formal >> agreement in place, then it needs to be given serious consideration when >> the RIPE community forms a new policy for the RIPE NCC which can be applied >> to the address space, because the terms of that agreement may still be >> binding on the RIPE NCC. If there was no agreement in place, then more >> options are open. > I'll be surprised if there was no agreement. Can someone from the RIPE NCC comment? Comment from someone involved at the time who happens to work at the RIPE NCC: ERX was an activity of the RIRs undertaken upon request from their communities. It was structured by informal agreements which were adapted in the light of experience and governed by the respective RIR governance processes. No higher authority authorised ERX. IANA was informed and welcomed the effort to increase the quality if the Internet Number Registry. I do not consider this a relevant question at all. The InterNIC does not exist anymore and it is questionable if it ever existed in a legal sense. To a lesser extent this goes for IANA as well, but there is general acceptance of the authority of the IANA. The RIPE community can freely decide policies for registrations in the RIPE Internet Number Registry. There are a small number of boundary conditions, such as good faith towards address space users and the laws of the Netherlands. Previous agreements about address space distribution to which the RIPE NCC was not a party are not part of them. See also my longish contribution of a few minutes ago Daniel From hank at efes.iucc.ac.il Wed Aug 29 18:00:11 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 29 Aug 2012 19:00:11 +0300 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E0070.8020804@titley.com> References: <20120829102135.GS13776@Space.Net> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <20120829102135.GS13776@Space.Net> Message-ID: <5.1.1.6.2.20120829185645.002f5bd8@efes.iucc.ac.il> At 12:43 29/08/2012 +0100, Nigel Titley wrote: >>due to the way RPSL-authentication and DNS tree'ing work, this is not >>easy to do in a non-hierarchical structure, so "having this done by >>the RIPE NCC" makes sense from a technical point of view. >> >>OTOH, I can see that the NCC wants to see some money in exchange for >>the expenses running all this (and that seems to make sense as well :-) ). >Yes, and bear in mind ultimately the RIPE NCC membership should be >consulted about this. It's their money providing the service. As a long standing paying member of RIPE NCC, IUCC is willing to pay an additional amount above its current payment level in order to include its legacy blocks under its LIR. It is just open to debate what that level of payment should be. -Hank From hank at efes.iucc.ac.il Wed Aug 29 18:09:06 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 29 Aug 2012 19:09:06 +0300 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503DEB69.9000107@netability.ie> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> At 11:14 29/08/2012 +0100, Nick Hilliard wrote: >Hank, > >On 29/08/2012 01:07, Hank Nussbacher wrote: > > At 23:20 28/08/2012 +0100, Nick Hilliard wrote: > >> then does IUCC maintain some sort of beneficial claim of registration over > >> subnets of the blocks you list - the sort of claim that would entitle you > >> to say that because this was IUCC space rather than IUCC member space, > that > >> it really ought to be covered under IUCC's LIR membership for any future > >> potential argument about a RIPE ERX policy? > > > > Only IP space that remains maintained under our LIR/NREN (il.iucc). > >It is not maintained under il.iucc, because il.iucc is a legal construct >which exists between the RIPE NCC and IUCC. The only address space managed >by il.iucc is 2001:0bf8::/32. Any other address space handled by IUCC have >is either ERX or outside the scope of the RIPE NCC. > >[...] > > My answer would be "Whatever is decided upon by the RIPE membership and not > > unilaterally by RIPE NCC management". But your initial comment of "On the > > one hand, ERX holders obtained address space without a governing contract > > and have been enjoying the benefits of this for many years. On the other > > hand, someone is footing the bill for the maintenance and upkeep of this > > registration data - namely the RIPE NCC membership." is clearly wrong in > > many cases since il.iucc has been "footing the bill" for all ERX space > > listed under its LIR. > >Not really, no. The entry in alloclist.txt for il.iucc is: > > > il.iucc > > IUCC - Israel InterUniversity Computation Center > > > > 20030508 2001:0bf8::/32 > > > >There's no mention of any ipv4 address space, and il.iucc is categorised as >"extra small". I cannot see how this means that il.iucc is footing the >bill for maintenance of the registry entries any more than every other RIPE >NCC member is. > > >> And if there is a precedent for tacitly > >> agreeing that e.g. commercial / governmental ERX assignees are not subject > >> to any NRENs' beneficial claims over the address space for whatever > reason, > >> then on what basis are you claiming that the NRENs have any beneficial > >> claim over their members' address space? > > > > Because in our case, the members (read universities), are the "owners" of > > the NREN. Legally speaking. > >I understand the distinction - I've been working with member-owned >organisations for a long time. However legally speaking, the assets of a >member-owned organisation are owned by that organisation, not by the >members. The organisation as a whole belongs to the members. > >Do I have a right to take Axel Pawlik's laptop? He works for the RIPE NCC, >and ie.netability is a member of the RIPE NCC, and I own ie.netability. >Based on your assertion, I might have some sort of claim to taking it, but >the legal reality is that I have no claim whatsoever. > >Let me put it another way: what would happen if a member were to leave your >NREN? Does IUCC stake its claim on the addresses at that point or not? >And if not, then on what basis do you stake any claim on the IP address >space now? And as a secondary issue (to ownership, but not to the point >you were originally making), if you are not staking a claim on beneficial >interest in the address space now, then why are you claiming that they >should just be bundled in as something similar to ALLOCATED PA address >space from the point of view of your LIR membership in any future agreement >with the RIPE NCC - except that you're also claiming in the policy document >that it shouldn't be counted towards a LIR allocation, but should be >charged as strictly less than a PI assignment per block. > >Hank, I'm not trying to be confrontational here. Nick, As much as it would appear fun and amusing to make il.iucc into a punching bag for RIPE NCC legacy policy, in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks, I think I will stop posting here and await to see what general policy is accepted by RIPE NCC for legacy IP space. -Hank >There's an important >issue which I'm trying to get to the bottom of, namely the issue of where >the rights and responsibilities lie between the address assignees and their >historical registrars. So far I've seen nothing to suggest that the >registrars have any sort of reasonable claim to the address space other; >nor have I seen any indication that the assignees have given informed >consent to these claims. > >These are important issues because they are pretty much guaranteed to >become problems in situations of changes of circumstance (potentially such >as this one). > >Nick From daniel.karrenberg at ripe.net Wed Aug 29 18:22:56 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 29 Aug 2012 18:22:56 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> Message-ID: <871931C2-F4D6-44F1-904D-8188E79877D9@ripe.net> On 29.08.2012, at 18:09 , Hank Nussbacher wrote: > As much as it would appear fun and amusing to make il.iucc into a punching bag for RIPE NCC legacy policy, in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks, I think I will stop posting here and await to see what general policy is accepted by RIPE NCC for legacy IP space. Hey Hank, you are a better sport than that! Good policy comes only by discussion. And despite some e-mail induced friction we all do respect each other. Please stay in the discussion. Especially if it focuses on the registration policy, as it should. Daniel And just as a reminder for those folks younger than Hank and myself, let me quote from the second RIPE NCC Quarterly Report (ripe-73): "Funding for the first year of operation of the NCC is provided by EARN, the national members of RARE, Israel and EUnet." The reason Israel is mentioned here, is that Israel's NREN at the time was not a formal member of RARE; some argument about Israel not being in "Europe"; a problem RIPE never had. If I recall correctly Hank was very active in EARN at the time and certainly also contributed to the Israeli NREN. So one could say that Hank was active in the first funders of the RIPE NCC 20 years ago. From nick at netability.ie Wed Aug 29 19:33:55 2012 From: nick at netability.ie (Nick Hilliard) Date: Wed, 29 Aug 2012 18:33:55 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> Message-ID: <503E5283.7080308@netability.ie> On 29/08/2012 17:09, Hank Nussbacher wrote: > As much as it would appear fun and amusing to make il.iucc into a punching > bag for RIPE NCC legacy policy Hank, I'm surprised and saddened that you think that I intended to poke fun at IUCC or turn it into a punching bag. This was genuinely not my intention and I think I made this clear in previous emails: "I'm not fishing for answers to these specific questions, btw. I'm interested in the general issue"... and: "I'm not trying to be confrontational here. There's an important issue which I'm trying to get to the bottom of, namely the issue of where the rights and responsibilities lie between the address assignees and their historical registrars." If I've offended you or cause offence to IUCC or its members by using your good name as an example, please accept my sincere and unconditional apologies. My intention was solely to discover, not to offend. > in addition to ideas stated here to take > away our legacy IP allocations and give us /22s and force us to use NAT and > reengineer our 10,000 node university networks No idea where this idea came from. No-one has ever suggested this or even remotely implied it. Quite the opposite in fact. > I think I will stop posting > here and await to see what general policy is accepted by RIPE NCC for > legacy IP space. Please don't. Your contributions are valuable. Nick From ripe-wgs.cs at schiefner.de Wed Aug 29 21:58:29 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 29 Aug 2012 21:58:29 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E5283.7080308@netability.ie> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> Message-ID: <503E7465.6010103@schiefner.de> Hi Nick, On 29.08.2012 19:33, Nick Hilliard wrote: > On 29/08/2012 17:09, Hank Nussbacher wrote: >> in addition to ideas stated here to take >> away our legacy IP allocations and give us /22s and force us to use NAT and >> reengineer our 10,000 node university networks > > No idea where this idea came from. No-one has ever suggested this or even > remotely implied it. Quite the opposite in fact. may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 03:06:08 +0200? It's archived at: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.html Best, Carsten From nick at netability.ie Wed Aug 29 22:25:55 2012 From: nick at netability.ie (Nick Hilliard) Date: Wed, 29 Aug 2012 21:25:55 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E7465.6010103@schiefner.de> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> <503E7465.6010103@schiefner.de> Message-ID: <503E7AD3.4070203@netability.ie> On 29/08/2012 20:58, Carsten Schiefner wrote: > may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 > 03:06:08 +0200? It's archived at: > > https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.html Someone else kindly pointed this out already - I didn't actually notice this. I'm not sure which particular RIPE policy Michael Markstaller was referring to when he suggested enforced withdrawal of address assignments in his email, but it's not one I'm familiar with. Nick From daniel.karrenberg at ripe.net Wed Aug 29 22:28:36 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 29 Aug 2012 22:28:36 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E7465.6010103@schiefner.de> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> <503E7465.6010103@schiefner.de> Message-ID: On 29.08.2012, at 21:58 , Carsten Schiefner wrote: > Hi Nick, > > On 29.08.2012 19:33, Nick Hilliard wrote: >> On 29/08/2012 17:09, Hank Nussbacher wrote: >>> in addition to ideas stated here to take >>> away our legacy IP allocations and give us /22s and force us to use NAT and >>> reengineer our 10,000 node university networks >> >> No idea where this idea came from. No-one has ever suggested this or even >> remotely implied it. Quite the opposite in fact. > > may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 03:06:08 +0200? It's archived at: > > https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.html [Personal title disclaimer as usual] I read that too and felt reminded of similar proposals over the years. None of these have made it past initial discussion in the community for a fair number of reasons. The discussions are archived and available to everyone. Of course there is a danger that such proposals may gain more traction now that nobody can ignore any longer that we will reach the final /8 soon. However I am optimistic and I do believe that our community is more mature than to fall for that or into that trap. We will experience all sorts of ugly things for a period, but this is not one of them. Daniel who had pledged not to engage in addresspolicy discussions anymore, but this is "services", right? ;-) At least I will call it a day for now. From ripe-wgs.cs at schiefner.de Wed Aug 29 22:32:53 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 29 Aug 2012 22:32:53 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> <50082A3F.8060701@SURFnet.nl> <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> <503E7465.6010103@schiefner.de> Message-ID: <503E7C75.3000803@schiefner.de> On 29.08.2012 22:28, Daniel Karrenberg wrote: > [...] > At least I will call it a day for now. We all should. At least those in and adjacent to CEST. :-) Best, -C. From mm at elabnet.de Wed Aug 29 22:46:59 2012 From: mm at elabnet.de (Michael Markstaller) Date: Wed, 29 Aug 2012 22:46:59 +0200 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120829090508.GQ13776@Space.Net> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> Message-ID: <503E7FC3.1000906@elabnet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.08.2012 11:05, Gert Doering wrote: > Hi, > > On Wed, Aug 29, 2012 at 03:06:08AM +0200, Michael Markstaller > wrote: >> Just my 2ct: not any University or worse religous campaign >> should block a /8 or /16 without having to state HERE&NOW why and >> for what they really need&use it. They need exactly 1 IP for >> every 65536 concurrently active student to NAT and 1 for each >> public service at most, lets put a /22 for infra on top and then >> we're fine.. > > This is not how the old Internet used to work, and it is not how it > works today - nobody is forced to use NAT by the RIRs, and that's > how it must be (*and* it has nothing to do with the question of ERX > space governance whatsoever). Ok, this was a intentionally a little provocative. I - admittetly - don't know much about the internals and policys/proposals of InterNIC or RIPE NCC and what this WG is really about. And learned much today from the various posts. >> We have to do either I guess, at least we do, according to >> RIPE-policys. So we're playing with different cards here, legacy >> holders are being asked "what might be a nice proposal they >> like", I'm not asked what "might be nice for me" > > ERX space has not been given out under RIPE policies, so they do > not apply. Period. There is no law, legal contract, or anything > else that would make RIPE policies automagically apply to ERX space > (and even *then*, there would not be any RIPE policy forcing a user > of IP address space to use NAT if they do not want to). Well I remember ther (was?) or is some policy or draft suggesting this at least for 2G/3G networks which not all providers do and, well which is IMHO nonsense in context of IPv4 really running out to give each Gadget in my pocket a public IP.. > It would solve nothing. If people insist on cementing their IPv4 > world for a few more years, they would have *more* stuff to move to > IPv6 in the long run - nothing solved. Agreed, not solve but shift the "problem" - though, I'm no enemy of v6, just to tell you my real-world view of IPv6: No single customer was ever interested in, no single hit on the servers we ran a while back around v6-Day, no single user on the xDSL we provide wanted to use it; the only result were new problems nobody pays for. Don't take this as a rant please, I know about your efforts in many ways, the problems are sourced by low usage/training etc. But it's a real big chicken-egg-problem and as a very small provider in business my primary job is to get a working infrastructure and happy customers that pay money; none of them ever wanted to pay a single Euro for v6 (maybe because you have all of them ;)) On 29.08.2012 12:21, Gert Doering wrote: > > Now, the policy proposal raised here is not an *address space* > policy proposal, but an *ncc service* policy proposal - which > governs the way the NCC runs their, uh, services. And I think this > is a reasonable approach - find something that the ERX holder > community and the RIPE NCC is happy with, walk it through an open > consensus process, and then nobody can argue that the RIPE NCC is > going out and bullying/blackmailing > ERX holders over their addresses... Thats a key point, I didnt really get so far.. On 29.08.2012 21:58, Carsten Schiefner wrote:> Hi Nick, > > On 29.08.2012 19:33, Nick Hilliard wrote: >> On 29/08/2012 17:09, Hank Nussbacher wrote: >>> in addition to ideas stated here to take away our legacy IP >>> allocations and give us /22s and force us to use NAT and >>> reengineer our 10,000 node university networks >> >> No idea where this idea came from. No-one has ever suggested >> this or even remotely implied it. Quite the opposite in fact. > > may I suggest you re-read Michael Markstaller's posting of Wed, 29 > Aug 2012 03:06:08 +0200? It's archived at: > > https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.html It was me, yes, and sorry for the rant. It wasn't based on any known policy or proposal but just on my Opinion and then 2ct.. Since I know now, again the proposal discussed (quoted again) is not an *address space* policy proposal, but an *ncc service* policy proposal. Ok.. But then I have another 2ct if this is relevant under this topic: I found no details in the proposals how the deal with "selling v4 addresses"(*) which will IMHO happen soon when v4 is fully exhausted. *I don't vote for this* but one or another way, it might be "cheaper" to "buy" v4 space then migrate networks, so it will happen. If I get with limited knowledge things right now, this might be a topic that could be of relevance in future. *) This was discussed quite a while back, maybe on another WG for a short time but AFAIR didn't make it to a conclusion. best regards Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA+f8MACgkQaWRHV2kMuAKuKwCfR1xibpJJvd6UugoehCbRLy+9 6zIAn0PMuVXgYWM0uLN4CnzCK5eaxq0L =xMKo -----END PGP SIGNATURE----- From nigel at titley.com Thu Aug 30 03:22:56 2012 From: nigel at titley.com (Nigel Titley) Date: Thu, 30 Aug 2012 02:22:56 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DF887.9060305@netability.ie> <503DFAD2.3050906@titley.com> Message-ID: <503EC070.8030708@titley.com> On 29/08/2012 16:16, Daniel Karrenberg wrote: > On 29.08.2012, at 13:19 , Nigel Titley wrote: > >>> On 29/08/2012 12:09, Nick Hilliard wrote: >>> So the issue is really a question of balancing the rights and >>> responsibilities of both the RIPE NCC and the ERX holders. This is why I >>> asked last week if there was an agreement in place between the InterNIC and >>> the RIPE NCC for handling the ERX transfers - if there was a formal >>> agreement in place, then it needs to be given serious consideration when >>> the RIPE community forms a new policy for the RIPE NCC which can be applied >>> to the address space, because the terms of that agreement may still be >>> binding on the RIPE NCC. If there was no agreement in place, then more >>> options are open. >> I'll be surprised if there was no agreement. Can someone from the RIPE NCC comment? > Comment from someone involved at the time who happens to work at the RIPE NCC: > > ERX was an activity of the RIRs undertaken upon request from their communities. It was structured by informal agreements which were adapted in the light of experience and governed by the respective RIR governance processes. No higher authority authorised ERX. IANA was informed and welcomed the effort to increase the quality if the Internet Number Registry. > > I do not consider this a relevant question at all. The InterNIC does not exist anymore and it is questionable if it ever existed in a legal sense. To a lesser extent this goes for IANA as well, but there is general acceptance of the authority of the IANA. It is relevant because the proposal before this working group makes repeated reference to it. It probably shouldn't, and in any case having spoken to Axel (now confirmed by you) no such formal agreement exists. So this is relevant, but null. > > The RIPE community can freely decide policies for registrations in the RIPE Internet Number Registry. There are a small number of boundary conditions, such as good faith towards address space users and the laws of the Netherlands. Previous agreements about address space distribution to which the RIPE NCC was not a party are not part of them. > > See also my longish contribution of a few minutes ago > Noted. Nigel From randy at psg.com Thu Aug 30 05:16:07 2012 From: randy at psg.com (Randy Bush) Date: Thu, 30 Aug 2012 10:16:07 +0700 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <60942F08-C210-400C-8E23-12E8461612D9@ripe.net> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <5C85B133-7177-4A6C-AF85-8AD763C7B266@rfc1035.com> <503DEA1B.4030602@titley.com> <503DEC7C.7020301@schiefner.de> <503E0431.80506@titley.com> <5FC54260-B582-42D7-B6BB-7DABA0AC1715@steffann.nl> <60942F08-C210-400C-8E23-12E8461612D9@ripe.net> Message-ID: in the interest of minimizing abuse of my being an old dog pushing my altzheimer inspired view of the past, i will indulge in quoting more original sources for a bit of perspective on the early internic. http://mailman.postel.org/pipermail/internet-history/2009-August/000899.html randy From cfriacas at fccn.pt Thu Aug 30 11:54:50 2012 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 30 Aug 2012 10:54:50 +0100 (WEST) Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E7FC3.1000906@elabnet.de> References: <237A4A74-82BB-46DB-807B-8008B3D2272B@ripe.net> <6C908880-60AF-4042-924C-D6C93A6BC58A@steffann.nl> <27B732A9-6545-4B9D-A48A-25D67BD98DBC@ucd.ie> <5.1.1.6.2.20120824100848.01fcfcd0@efes.iucc.ac.il> <5.1.1.6.2.20120825212546.01fb0138@efes.iucc.ac.il> <91F9BCE1-2D67-4115-ABD0-92F2CD2E57A4@netability.ie> <50395B25.2050703@SURFnet.nl> <5.1.1.6.2.20120828193856.00397160@efes.iucc.ac.il> <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <503D6B00.7000605@elabnet.de> <20120829090508.GQ13776@Space.Net> <503E7FC3.1000906@elabnet.de> Message-ID: Hello, On Wed, 29 Aug 2012, Michael Markstaller wrote: >> It would solve nothing. If people insist on cementing their IPv4 >> world for a few more years, they would have *more* stuff to move to >> IPv6 in the long run - nothing solved. > Agreed, not solve but shift the "problem" - though, I'm no enemy of > v6, just to tell you my real-world view of IPv6: No single customer > was ever interested in, no single hit on the servers we ran a while > back around v6-Day, no single user on the xDSL we provide wanted to > use it; the only result were new problems nobody pays for. Maybe you missed some previous messages, or the messages were not clear enough: the lack of address space is not a user problem, it's a service provider's problem. However, the service provider can make this a user's problem if they choose to NAT, double-NAT, triple-NAT, ... ;-( > Don't take this as a rant please, I know about your efforts in many > ways, the problems are sourced by low usage/training etc. We still see situations were there was a clear gap in IPv4 training too... ;-) > But it's a > real big chicken-egg-problem and as a very small provider in business > my primary job is to get a working infrastructure and happy customers > that pay money; none of them ever wanted to pay a single Euro for v6 > (maybe because you have all of them ;)) And customers also don't want to pay for 32-bit numbers. All they want is "service", their applications to work, and so forth... > But then I have another 2ct if this is relevant under this topic: > I found no details in the proposals how the deal with "selling v4 > addresses"(*) which will IMHO happen soon when v4 is fully exhausted. > *I don't vote for this* but one or another way, it might be "cheaper" > to "buy" v4 space then migrate networks, so it will happen. > If I get with limited knowledge things right now, this might be a > topic that could be of relevance in future. > > *) This was discussed quite a while back, maybe on another WG for a > short time but AFAIR didn't make it to a conclusion. The policy proposal, afaik, will be improved during the discussion phase. Selling *legacy* v4 addresses is something that i think it already happenned in other regions, but anyway i don't think that is this policy's focus... ps: "cheaper" always depends on the timeframe you're considering. It may be cheaper in the short-run (3m, 6m, 1y, ...), but that option can in fact turn out to be more expensive if you cannot scale it, and you finally understand you need to go through an emergency migration process, and possibly lose customers or potential customers during that phase. :-) Best Regards, Carlos Fria?as > best regards > > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlA+f8MACgkQaWRHV2kMuAKuKwCfR1xibpJJvd6UugoehCbRLy+9 > 6zIAn0PMuVXgYWM0uLN4CnzCK5eaxq0L > =xMKo > -----END PGP SIGNATURE----- > From he at uninett.no Thu Aug 30 12:00:12 2012 From: he at uninett.no (Havard Eidnes) Date: Thu, 30 Aug 2012 12:00:12 +0200 (CEST) Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <503E5283.7080308@netability.ie> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> Message-ID: <20120830.120012.241450609.he@uninett.no> >> in addition to ideas stated here to take away our legacy IP >> allocations and give us /22s and force us to use NAT and >> reengineer our 10,000 node university networks > > No idea where this idea came from. No-one has ever suggested this or even > remotely implied it. Quite the opposite in fact. Uh... I think this came from Message-ID: <503D6B00.7000605 at elabnet.de>, from Michael Markstaller earlier in this thread, ref. http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.html Just for the record: I consider his suggestion to be totally outlandish, just the notion that "all one needs at any one time as a user is a single NAT'ed socket" is so far out of touch with what consitutes "need" that the rest isn't really worthy of comments. However, just for the record, let me say this: the community really should accept that historical assignments should not be put into question, at least not as part of this discussion, also not at the present time, and it is somewhat doubtful that they ever can be. The only realistic and straight-forward way to re-claim legacy IPv4 address space is through voluntary surrender by the current holder. Therefore, I think I agree with what Daniel Karrenberg said about what the present discussion should be about, I'm quoting: So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less. All other questions are secondary. Resolving conflicts about the holdership/use of the address space is a non issue. Past agreements about allocation of address space are a non issue. [...] (I have a question of terminology that I'll bring up in a separate message.) Best regards, - H?vard From bijal.sanghani at euro-ix.net Thu Aug 30 12:11:32 2012 From: bijal.sanghani at euro-ix.net (Bijal Sanghani) Date: Thu, 30 Aug 2012 11:11:32 +0100 Subject: [ncc-services-wg] NCC Services WG Draft Agenda - RIPE 65 Message-ID: Dear colleague, Please see below and online the draft agenda for the NCC Services WG - RIPE 65 - https://ripe65.ripe.net/programme/meeting-plan/services-wg/ Date: Wednesday 26 September 2012 Time: 16.00 - 17.45 Chair: Kurtis Lindqvist Co-Chair: Bijal Sanghani A. Administrative Matters (5 minutes) Welcome Select a scribe Finalise agenda Approve minutes from RIPE 64 B. Report from RIPE NCC - Axel Pawlik, RIPE NCC (30 minutes) C. IP Anlyiser API - Alex Band, RIPE NCC (10 minutes) D. IPv4 Final Distribution ? update - Andrea Cima, RIPE NCC (10 minutes) E. Proposed Policy for RIPE NCC Services to Legacy Internet Resource Holders - Niall O? Reilly (40 minutes) F. Open Microphone Session Z. AOB regards, Bijal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Niall.oReilly at ucd.ie Thu Aug 30 12:41:24 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 30 Aug 2012 11:41:24 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120830.120012.241450609.he@uninett.no> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> <20120830.120012.241450609.he@uninett.no> Message-ID: <49063958-A40B-407C-A74C-E5780AE72CF4@ucd.ie> On 30 Aug 2012, at 11:00, Havard Eidnes wrote: > Therefore, I think I agree with what Daniel Karrenberg said about > what the present discussion should be about, I'm quoting: > > So what we have to decide as a community is: under which policies > does the RIPE community allow legacy space holders to register > their address space in the RIPE Internet Number registry. Nothing > more, nothing less. > > All other questions are secondary. Resolving conflicts about the > holdership/use of the address space is a non issue. Past agreements > about allocation of address space are a non issue. [...] > > (I have a question of terminology that I'll bring up in a separate > message.) I think I agree too. Background work on a new version of the policy proposal has begun. It is premature for me to say more at this stage. Best regards, Niall From nick at netability.ie Thu Aug 30 13:03:43 2012 From: nick at netability.ie (Nick Hilliard) Date: Thu, 30 Aug 2012 12:03:43 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120830.120012.241450609.he@uninett.no> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> <20120830.120012.241450609.he@uninett.no> Message-ID: <503F488F.2040408@netability.ie> On 30/08/2012 11:00, Havard Eidnes wrote: > Just for the record: I consider his suggestion to be totally > outlandish, just the notion that "all one needs at any one time as a > user is a single NAT'ed socket" is so far out of touch with what > consitutes "need" that the rest isn't really worthy of comments. That is a polite way of putting it, yes. I agree completely. > However, just for the record, let me say this: the community really > should accept that historical assignments should not be put into > question I also agree completely with this. > at least not as part of this discussion, also not at the > present time, and it is somewhat doubtful that they ever can be. > The only realistic and straight-forward way to re-claim legacy IPv4 > address space is through voluntary surrender by the current holder. As we're talking about registration in a database, the RIPE NCC has a stewardship responsibility to ensure that the registration details are "correct", for some meaning of the word "correct" which needs to be defined by policy (which is why I was interested in the NREN / NREN member position on the ultimate assignee). As such, the registration policy means that the RIPE NCC will need to perform some level of due process with regard to identifying the ERX holders. This will inevitably lead to the identification of ERX space which is registered to organisations / persons which no longer exist, and in this case there may be a argument to take these addresses out of circulation in order to stop hijacking (whether that means preventing updates or deregistering them/returning them to the IANA pool or something else, I do not know). I would be happy for this not to be part of any initial policy, but I do believe that garbage collection will be a necessary part of the overall ERX management process and that we will eventually need to look at this from a policy point of view. Other than garbage collection, I see no basis for reclaiming v4 address space other than by voluntary return. Nick From jim at rfc1035.com Thu Aug 30 13:12:42 2012 From: jim at rfc1035.com (Jim Reid) Date: Thu, 30 Aug 2012 12:12:42 +0100 Subject: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders In-Reply-To: <20120830.120012.241450609.he@uninett.no> References: <5.1.1.6.2.20120829025024.01f06a68@efes.iucc.ac.il> <5.1.1.6.2.20120829190532.05363748@efes.iucc.ac.il> <503E5283.7080308@netability.ie> <20120830.120012.241450609.he@uninett.no> Message-ID: On 30 Aug 2012, at 11:00, Havard Eidnes wrote: > Therefore, I think I agree with what Daniel Karrenberg said about > what the present discussion should be about, I'm quoting: > > So what we have to decide as a community is: under which policies > does the RIPE community allow legacy space holders to register > their address space in the RIPE Internet Number registry. Nothing > more, nothing less. Indeed. I think it will be helpful to close this thread and start a new one which focuses on this key point. IMO legacy holders should be able to register/manage their space in the NCC database and get the equivalent service they would have enjoyed from SRI or whoever it was that issued the space all those years ago. Since that service was free back then, the comparable services for that space today from the NCC -- updating contact objects and delegation info mostly -- should be free too. YMMV. The incremental cost to the NCC of doing that should be negligible. The database and its supporting infrastructure is already there. And besides, the NCC provides services for the benefit of the broader Internet community than just its members. These must be costing quite a bit more than supporting a bunch of legacy space database entries. So the actual costs of this "free" service to legacy holders would probably be lost in the noise. Of course if that turned out not to be the case, then some mechanism would need to be found to fund it. Says he hand-waving from a distance... A fee of a few euro per update could do that but may be more bother than it's worth. It may well cost more than that to raise an invoice and do the bean counting. If/when the legacy holder needs additional RIR services related to that space -- say a secure reverse delegation or a cert for RPKI -- they can either pay for that on a cost recovery basis or become an LIR. Those services didn't exist when they got the space, so it's only right that a legacy holder pays for that extra functionality somehow. From BECHA at ripe.net Fri Aug 31 13:51:23 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 31 Aug 2012 13:51:23 +0200 Subject: [ncc-services-wg] Announcing RIPE Atlas Anchors, Pilot Phase Message-ID: <5040A53B.3080106@ripe.net> Dear colleagues, [apologies for duplicate messages] Please find a new article on RIPE Labs describing the details of RIPE Atlas Anchors: https://labs.ripe.net/Members/dfk/ripe-atlas-anchors Right now, we are looking for a small number of pilot hosts from the RIPE NCC membership for deployment to begin in October 2012. If you are interested, please contact me or Daniel Karrenberg before the RIPE65. We will be discussing further details at the RIPE meeting. Regards, Vesna Manojlovic -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net