[address-policy-wg] address-policy-wg Digest, Vol 22, Issue 2
- Previous message (by thread): [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members
- Next message (by thread): [address-policy-wg] Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ACCESS
yurax at mail.ru
Sat Jun 8 12:08:01 CEST 2013
Суббота, 8 июня 2013, 12:00 +02:00 от address-policy-wg-request at ripe.net: > Send address-policy-wg mailing list submissions to > address-policy-wg at 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 at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at 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 at CC.UniVie.ac.at > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: Erik Bais < ebais at a2b-internet.com > > Cc: ncc-services-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: < 51B1E0EF.7010303 at 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 at a2b-internet.com > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: < Woeber at CC.UniVie.ac.at > > Cc: ncc-services-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: < [email protected] > > 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
- Previous message (by thread): [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members
- Next message (by thread): [address-policy-wg] Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]