[ncc-services-wg] [address-policy-wg] Resource Certification for non-RIPE NCC Members

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