Re: [address-policy-wg] address-policy-wg Digest, Vol 22, Issue 2
Суббота, 8 июня 2013, 12:00 +02:00 от address-policy-wg-request@ripe.net:
Send address-policy-wg mailing list submissions to address-policy-wg@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@ripe.net
You can reach the person managing the list at address-policy-wg-owner@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@CC.UniVie.ac.at > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members To: Erik Bais < ebais@a2b-internet.com > Cc: ncc-services-wg@ripe.net, address-policy-wg@ripe.net Message-ID: < 51B1E0EF.7010303@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@a2b-internet.com > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members To: < Woeber@CC.UniVie.ac.at > Cc: ncc-services-wg@ripe.net, address-policy-wg@ripe.net Message-ID: < 007801ce639d$529eb0b0$f7dc1210$@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
participants (1)
-
ACCESS