June 2013 - address-policy-wg

the interpretation of "transfer" - somewhat related to 2012-07
by Wilfried Woeber 12 Jun '13

12 Jun '13

Quoting Andrea's comment of today regarding "authoritative" RIR: <quote> Legacy resources issued to organisations within the RIPE region have been transferred to the RIPE region during the ERX project. Legacy resources that have not been transferred at that time, have been issued and registered to organisations in other RIR regions. RIPE policy has no authority over legacy resources registered in other RIR regions. For this reason, in order to transfer those resources to the RIPE registry (and register them with a RIPE NCC LIR), there needs to be a transfer policy that would allow transfers between the RIPE NCC and the RIR that has the authority over those resources. </quote> First of all, I appreciate the NCC's cautious approach to moving things around without a clear consensus and guidance on preocedures! Two comments for discussion or clarification: ° until now I always read policies or policy proposals regarding a "transfer" of addresses from userA to userB. With either both of them sharing the same assignment to an authoritative RIR (intra-region xfr) or relating to different authoritative RIRs (inter-region xfr). The comment as quoted above indicates a different, or rather an additional interpretation and applicability: the transfer of address *registration* data pertaining to some (the very same!) userX from one authoritative RIR to a different one. I am not sure that the community did or does have that interpetation in mind? ° the "good old ERX" project, back then, was based on simple clerical inputs, a procedural agreement amongst the RIRs, and with no formal policy background, IIRC. Thus I do not really understand, why we would need a formal "policy" regarding inter-regeion transfers, as long as the registration subject remains the same. I may have missed some things, of course. Wilfried.

1 0

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

11 Jun '13

Вторник, 11 июня 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: Resource Certification for non-RIPE NCC Members (Peter Koch) > 2. Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a > per-allocation vs per-LIR basis" implemented (Kjell Leknes) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jun 2013 17:20:30 +0200 > From: Peter Koch < pk(a)DENIC.DE > > Subject: Re: [address-policy-wg] Resource Certification for non-RIPE > NCC Members > To: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 20130610152030.GK14598(a)x28.adm.denic.de > > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: > > > 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 respectfully suggest it is not. The current modus operandi for RPKI > in the NCC service region is not only not based on a policy created > by the PDP, it exists despite a policy proposal for that very subject > having failed. Whether or not that creates a schism might be interesting > to discuss, but is not relevant for the case at hand. What counts here is > that the absence of policy is not an 'omission' or accident. > > So far I have seen support for 2013-04 based on symmetry or equality of > PA, PI and other (former) special cases. While this might have merit > operationally, it cannot support a parallel policy just because there's > nothing to draw the parallel to. This point of order has not been addressed > so far (and there are multiple solutions to this situation). > > Therefore I formally object to 2013-04 being elevated into the next PDP phase. > > -Peter > > ------------------------------ > > Message: 2 > Date: Tue, 11 Jun 2013 08:43:29 +0200 > From: Kjell Leknes < kjell(a)ripe.net > > Subject: [address-policy-wg] Policy Proposal 2012-10 "Extension of > IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented > To: "address-policy-wg(a)ripe.net" < address-policy-wg(a)ripe.net >, > "policy-announce(a)ripe.net" < policy-announce(a)ripe.net > > Message-ID: < 11E136AE-2A9A-4798-9F2E-D57CF49672D8(a)ripe.net > > Content-Type: text/plain; charset="us-ascii" > > [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

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