- address-policy-wg - mailman.ripe.net

Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
by Kjell Leknes 11 Jun '13

11 Jun '13

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: http://www.ripe.net/ripe/docs/ripe-589 [Open URL] You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net If you have any questions, please contact ncc(a)ripe.net Regards, Kjell Leknes Registration Services RIPE NCC

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 22, Issue 2
by ACCESS 08 Jun '13

08 Jun '13

Суббота, 8 июня 2013, 12:00 +02:00 от address-policy-wg-request(a)ripe.net: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > Today's Topics: > > 1. Re: [ncc-services-wg] Resource Certification for non-RIPE NCC > Members (Wilfried Woeber) > 2. Re: [ncc-services-wg] Resource Certification for non-RIPE NCC > Members (Erik Bais) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 07 Jun 2013 15:32:31 +0200 > From: Wilfried Woeber < Woeber(a)CC.UniVie.ac.at > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: Erik Bais < ebais(a)a2b-internet.com > > Cc: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 51B1E0EF.7010303(a)CC.UniVie.ac.at > > Content-Type: text/plain; charset=windows-1252 > > Hi Erik, Community, > > a couple of general comments before potentially going into details on the > Services WG. > > Whether we need a formal "policy" or just an agreement (amongst the members > of the NCC) to a Service Description and a review of the CPS as maintained > by the NCC is a sideline issue, imho. > > For now using the framework of the PDP maybe useful and appropriate. > > I concur with other comments already, that - at the moment - there is, and > probably shouldn't be - a different colour related to PA, PI, ERX, v4, v6, > you name it. So, whatever we come up with should be "the same", technically. > > Looking at the proposed text for discussion, I sense a mindset of "the NCC is > the sole source of the Certificates". This may be reasonable for those paries, > which do have a direct Service Contract with the NCC (Direct End User, Legacy). > > For all the others, there is - or structurally, will be - a managed foodchain > and Hierarchy. > > This may be > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > > In the end we SHOULD, imo, structure the service definition *and* the > implementation to be congruent to this structe. I.e. the LIRs SHOULD be the > parties issuing the certificates for those resources which are held by their > users/customers, and for which there is a contract. > > Trying to bypass the LIRs and/or messing around with some sort of backdoor > structure for cert.creation, and "verification" by the NCC, would become > messy. We (my team) DO have real life experience, that such a disjunct and > artificial mechanism is a pain, and a source for inconsistencies. > > And, last but not least, in order to potentially, in the (near?) future, > overcome the "single point of failure thing" (that we are creating now by > building a "proper" tree structure!), removing any and all notion of the > Service Region would have my *strong* support. Not just because it will be > difficult to find a proper definition of "reside within", but more so because > it would open the chance to actually acquire certificates from more than one > "root", aka CA. > > These multiple roots/CAs could either (preferably?) be the set of RIRs, but > other parties as well. This would take away most of my worries and reservation > related to the proliferation of the RPKI. > > Sorry for the long text ;-) > Wilfried. > > Erik Bais wrote: > > > Dear community members of the AP ? WG and the NCC Services WG, > > > > As you may have seen, I?ve created a policy proposal to ask the RIPE NCC to > > allow Resource Certification for non-RIPE NCC member resource holders. (IXP > > / Legacy space and PI space holders) > > > > Currently we are in the phase: Discussion ? Open for discussion > > > > And I would like to invite you to the service wg mail list for your support > > for this policy and a discussion on wording of the policy. > > For those that are not subscribed to the NCC Services mail-list -=> > > http://www.ripe.net/mailman/listinfo/ncc-services-wg/ > > > > During the creation of the policy I made a small error in the intention to > > limit the policy to entities in the RIPE NCC service region and the policy > > currently states: > > > > ? The Internet resources reside within the RIPE NCC service region > > > > I?ll update this in the review phase. I?m not sure yet if we need to skip > > that part entirely or change it to the actual intention. > > > > Your input and stated support on the NCC Services WG mail list would be > > highly appreciated. > > > > Kind regards, > > Erik Bais > > > > Link to the policy proposal: > > https://www.ripe.net/ripe/policies/proposals/2013-04 > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Jun 2013 18:37:38 +0200 > From: "Erik Bais" < ebais(a)a2b-internet.com > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: < Woeber(a)CC.UniVie.ac.at > > Cc: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 007801ce639d$529eb0b0$f7dc1210$(a)a2b-internet.com > > Content-Type: text/plain; charset="Windows-1252" > > Hi Wilfried, > > First of all, let me say thanks for the feedback. > > > Whether we need a formal "policy" or just an agreement (amongst the > members > > of the NCC) to a Service Description and a review of the CPS as maintained > > by the NCC is a sideline issue, imho. > > > For now using the framework of the PDP maybe useful and appropriate. > > So do I. > > > Looking at the proposed text for discussion, I sense a mindset of "the NCC > is > > the sole source of the Certificates". This may be reasonable for those > paries, > > which do have a direct Service Contract with the NCC (Direct End User, > Legacy). > > > For all the others, there is - or structurally, will be - a managed > foodchain > > and Hierarchy. > > > This may be > > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > > > In the end we SHOULD, imo, structure the service definition *and* the > > implementation to be congruent to this structe. I.e. the LIRs SHOULD be > the > > parties issuing the certificates for those resources which are held by > their > > users/customers, and for which there is a contract. > > > Trying to bypass the LIRs and/or messing around with some sort of backdoor > > structure for cert.creation, and "verification" by the NCC, would become > > messy. We (my team) DO have real life experience, that such a disjunct and > > artificial mechanism is a pain, and a source for inconsistencies. > > The proposal was specifically written without a structure on how the NCC > should implement the system towards the PI or Legacy resource holders. > In my opinion that is a complete different discussion than a decision on IF > we want resource certification for resources of non-RIPE NCC members. > > I understand that it might be tempting to state how we want to have it > implemented or even move into the area where we ask ourselves the question, > who is going to pay for this and how? > However in order to keep the discussion as simple as possible and not to > force the discussion or proposal about how to do the implementation into a > certain direction or to hand-cuff the NCC on how they operate the systems, > it was specifically written without how / who / SHOULD or structure. It is > simply a question to allow non-RIPE NCC members their resources to be > certified. > > I'm sure that there will be questions after this, about what the better > structure would be (option 1,2,3), implications etc etc. > > > And, last but not least, in order to potentially, in the (near?) future, > > overcome the "single point of failure thing" (that we are creating now by > > building a "proper" tree structure!), removing any and all notion of the > > Service Region would have my *strong* support. Not just because it will be > > difficult to find a proper definition of "reside within", but more so > because > > it would open the chance to actually acquire certificates from more than > one > > "root", aka CA. > > The specific sentence has been adjusted as it was provided based on input > during the discussion phase to: > > -the Internet resources are registered in the RIPE registry. > > As certification is very closely related to the registration of resources, I > would like to limit it to the RIPE registry for now. > > I can see your point on a more global view and desire, however I would > prefer to take small steps here. > Let's get this in place for the resources in the RIPE registry. If we have > this step taken, we can always adjust the specifics if we need/want to move > to a more distributed model. > Currently it is my goal to have this sorted for the resources in the RIPE > registry. > > > These multiple roots/CAs could either (preferably?) be the set of RIRs, > but > > other parties as well. This would take away most of my worries and > reservation > > related to the proliferation of the RPKI. > > As stated earlier, I'm not going, in the current discussion, going to move > away from the as-is situation. > There is a current implementation and it is missing most of the resources. > > Yes I see how a more distributed environment might be better, however it is > beyond the scope of this proposal. > Any discussion on a distributed model is in vain imho if we exclude the > current group for which this proposal is created. > > > Sorry for the long text ;-) > > Wilfried. > > Thanks for the input and I hope to have answered your questions. > > Regards & have a nice weekend, > Erik Bais > > End of address-policy-wg Digest, Vol 22, Issue 2 > ************************************************ ACCE$$ Отправлено из мобильной Почты Mail.Ru

1 0

Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects
by Emilio Madaio 28 May '13

28 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". At the request of the proposers of the original policy proposal that produced ripe-513, we’re sending a reminder about the document review and inviting the IPv6 Working Group Mailing List and Database Working Group Mailing List subscribers to participate in the review process. A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

3 2

Final RIPE 65 APWG Session Minutes
by Emilio Madaio 21 May '13

21 May '13

Dear colleagues, The draft minutes of the RIPE 65 Address Policy Working Group session were approved by the Working Group during the session at RIPE 66. The final minutes are online at: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-65 Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Update to RFC2050
by Hans Petter Holen 14 May '13

14 May '13

(I tried do search trough the archives and found this only deep within the 2013-03 discussion.) The ASO Address Council was made aware of - and had a short discussion with one of the author on - the topic of the proposed update to RFC 2050. The current version of the draft is at http://www.ietf.org/id/draft-housley-rfc2050bis-01.txt Below is the messages I have found on the topic on the ARIN ppml which explains the background of the work in progress. Personally I think this is a long overdue cleanup of RFC2050 - and the Address Policy working-group should perhaps spend some time on follwing the development of the document to get the workings right. Hans Petter > *From:* John Curran <jcurran(a)arin.net <mailto:jcurran@arin.net>> > *Date:* March 17, 2013, 2:57:17 PM PDT > *To:* CJ Aronson <cja(a)daydream.com <mailto:cja@daydream.com>> > *Cc:* "arin-ppml(a)arin.net <mailto:arin-ppml@arin.net>" > <arin-ppml(a)arin.net <mailto:arin-ppml@arin.net>> > *Subject:* *Re: [arin-ppml] Update to RFC2050* > > On Mar 17, 2013, at 4:57 PM, CJ Aronson <cja(a)daydream.com > <mailto:cja@daydream.com>> wrote: > >> There is a current IETF draft to update RFC205. Since that RFC is >> near and dear to all of us I thought folks might want the link. >> >> http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt > > Thanks Cathy! Let me add some more background - > > We've known for quite some time that RFC 2050 (describing the > structure of > the Internet Registry system and its initial policies back in days of > Jon Postel) > has become rather outdated with time, and yet we did not want it to be > made > "historic" without a successor document (due to the various references > in the > Internet community) > > What was needed is a revised document reflecting just the high-level > principles > and agreements for the Internet address registry system. As an > informational > document, such an updated statement of current state of affairs could > serve as > a useful successor and replacement for RFC 2050. I will note that the > last time > such an effort was attempted within the IETF (circa 2003), there was some > confusion over whether the goal was documenting "as is" versus "as it > should > be", and ultimately did not reach productive conclusion. > > So, a few of us (Russ Housley, myself, Geoff Huston, and David Conrad) > took > it upon ourselves to draft a suitable replacement document, and we > have now > completed the task. We also took the time to have the draft reviewed > by the > execs from the other RIRs, folks in the IAB, IESG, and ISOC, as well > as list > of folks who have had strong involvement in the Registry System over the > years (Scott Bradner, Randy Bush, etc.) The resulting document should be > an accurate representation of the current "as is" state of the > Internet Number > Registry System as far as we can determine, including having references > to the agreements defining the structure and primary relationships. > > The document is available here: > > <http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt> > > The announcement of the draft has been posted to the "ietf" > mailing list for > further discussion (and more information on the "ietf" list is > available here: > <https://www.ietf.org/mailman/listinfo/ietf>) > > Thanks! > /John > > John Curran > President and CEO > ARIN > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML(a)arin.net > <mailto:ARIN-PPML@arin.net>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info(a)arin.net <mailto:info@arin.net> if you experience > any issues.

1 0

2012-10 Proposal Accepted (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis)
by Marco Schmidt 14 May '13

14 May '13

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-552, "IPv6 Address Allocation and Assignment Policy", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-10 The updated RIPE document is ripe-589 and is available at: https://www.ripe.net/ripe/docs/ripe-589 Thank you for your input. An announcement regarding the implementation will follow. Kind Regards Marco Schmidt Policy Development Office RIPE NCC

1 0

DRAFT Mintues from the APWG Meeting at RIPE 65
by Emilio Madaio 13 May '13

13 May '13

Dear Colleagues, the draft minutes from the APWG sessions at the recent RIPE 65 meeting have been now published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-65 Please let us know if there is anything that needs to be corrected or amended. Best Regards Emilio Madaio Policy Development Officer RIPE NCC

2 1

Cosmetic Surgery Project: new revised RIPE Policy document for IPv6 database objects
by Emilio Madaio 13 May '13

13 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

2013-02 Last Call for Comments (Removal of requirement for certification of reallocated IPv4 addresses)
by Marco Schmidt 13 May '13

13 May '13

Dear Colleagues, The proposal described in 2013-02, Removal of requirement for certification of reallocated IPv4 addresses, is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 10 June 2013 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-02 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 10 June 2013. Regards Marco Schmidt Policy Development Office RIPE NCC

1 0

Re: [address-policy-wg] 2013-02 End of Review Phase (Removal of requirement for certification of reallocated IPv4 addresses)
by Gert Doering 08 May '13

08 May '13

Dear Address Policy WG, the review period for this policy proposal is now over. Sander and I went through your comments, and all that we received in the review phase were 9 statements of "+1" or "support", no questions and no objections - so we think this is good to go to last call now. Emilio will send the formal announcement soon (public holiday in Amsterdam tomorrow). I'm not asking you to challenge our evaluation this time :-) Gert Doering, APWG chair On Wed, Apr 10, 2013 at 03:30:28PM +0200, Marco Schmidt wrote: > > Dear Colleagues, > > The draft document for the proposal described in 2013-02, > "Removal of requirement for certification of reallocated IPv4 addresses", > has been published. The impact analysis that was conducted for this > proposal has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2013-02 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg(a)ripe.net before 8 May 2013. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC > > 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

1 0