[address-policy-wg] address-policy-wg Digest, Vol 22, Issue 2

Суббота,  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: < 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