[ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)

Hi Niall,

Replying as an individual as well:

>> 1. The proposal refers to the terms and conditions under which the
>> Legacy Internet Resources were originally granted. The RIPE NCC will
>> need to be informed as to the content of these original terms and
>> conditions to properly determine their impact.
> 
> 	This need seems to be overstated.  Beyond what is necessary
> 	to determine whether the party involved is indeed the 
> 	legitimate holder of the resource in question, what need can
> 	the RIPE NCC have for the information mentioned?

Indeed. The NCC needs to know who is the holder to keep the database up to date and to provide services. The terms and conditions are not going to be enforced by the NCC, so why would they need them?

>> 2. The RIPE NCC often receives requests from Legacy Resource Holders
>> wanting their resources to be considered as space allocated by the
>> RIPE NCC. If this proposal is accepted, the RIPE NCC will have to
>> decline these requests.
> 
> 	This is information of which I was not previously aware.
> 	I appreciate being made aware of this and intend to ensure 
> 	that it is taken into account during the proposal's next 
> 	revision cycle.

As long as those Legacy Resource Holders know that they don't *have* to do this to get services from the NCC then that should indeed be up to them.

>> 3. Due diligence checks will be required to verify the legitimacy
>> of Legacy Resource Holders. If the correct documentation cannot be
>> provided, the RIPE NCC will be unable to enter into a contractual
>> relationship with the Legacy Resource Holder.
> 
> 	To the extent the the diligence applied is indeed "due",
> 	and conforms with reality rather than with some conventional
> 	concept or recipe, this seems reasonable.  Due diligence
> 	needs to be informed by both Balance of Probability and
> 	Balance of Convenience.
> 
> 	It seems to me that a test which the RIPE NCC might 
> 	reasonably use would be whether sufficient trust exists
> 	for a good-faith belief in the legitimacy of the claim
> 	to hold the resources in question.
> 
> 	I expect that the issue here is whether the RIPE NCC can
> 	safely offer registration services (possibly including
> 	certification) in each specific case.

This is a very hard thing to define in policy. Looking back at the previous item: "The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC.". I assume that for this even stricter checks are in place. That should be the upper limit of the due diligence. I don't want to define in policy how the NCC should handle this though.

>> 4. Section 2.1 of the proposal allows Legacy Internet Resources
>> to be covered by the RIPE NCC Standard Service Agreement (SSA). 
>> Modifications to the SSA will require approval by the General
>> Meeting (GM).
> 
> 	The GM has the necessary power.
> 
> 	I expect that it will be for a member with some interest
> 	in legacy resources to bring forward a proposal that the
> 	GM exercise this power.

+1

>> 5. Section 2.4 of the proposal allows the Legacy Resource Holder
>> to engage directly with the RIPE NCC through a special contract
>> if they cannot find a sponsoring LIR. The RIPE NCC cannot think of
>> any circumstances where this might be the case. Also, the creation
>> of such a special class of contract would require approval by the GM.
> 
> 	My remark to point 4 applies also to point 5.

+1

>> 6. Similarly, section 2.5 allows the Legacy Resource Holder to
>> conclude no contact due to special enduring circumstances. The RIPE
>> NCC cannot think of what these circumstances might be, and some
>> Registration Services cannot be performed without a contract in
>> place. Additionally, the RIPE NCC will be unable to enforce these
>> resource holders to maintain accurate data in the registry.
> 
> 	[s/contact/contract/]
> 
> 	The proposal mentions "special enduring or temporary
> 	circumstances" and also that these be "recognised by the 
> 	RIPE NCC as being outside the resource holder's control".
> 
> 	As I understand it, the intent here is fourfold:
> 
>     -	that the RIPE NCC have the freedom to deal appropriately
> 	with unforeseen adverse circumstances on a case-by-case 
> 	basis;
> 
>     -	that awareness of this freedom be available to every
> 	reader of the policy;
> 
>     -	that the RIPE NCC is protected from vexatious or 
> 	mischievous invocation of this section by the requirement
> 	for recognition by the RIPE NCC of the nature of the 
> 	circumstances; and
> 
>     -	that the resource holder has a remedy against unreasonable
> 	refusal of this recognition by recourse to the arbitration
> 	procedure.
> 
> 	It is of the nature of unforeseen circumstances that it
> 	may be difficult to think in advance of what they might be.
> 	It is not possible, and therefore not necessary, either for 
> 	the proposers or for the RIPE NCC to itemize in a (final 
> 	or proposed) policy an exhaustive list of such circumstances.

Making such a list would be a very bad idea. It will provide opportunities to be abused ("but according to this list I ...") and it will exclude cases that we haven't thought of. The policy should set the framework for the NCC to be able to deal with these cases.

> 	It will be useful to have a list of the Registration Services
> 	for which a contract is required.

Make that a maintained and published list.

>> 7. In cases where the Legacy Resource Holder is unknown or
>> unresponsive, the proposal allows for the RIPE NCC to update
>> entries in the RIPE Database but does not specify the scope of
>> these updates.
> 
> 	The fact that a resource holder is unknown or unresponsive
> 	should not be an obstacle to the RIPE NCC's exercise of
> 	its responsibility for the data it holds.  Circumstances
> 	may arise in which there is a compelling reason for the
> 	RIPE NCC to make an update.  The RIPE NCC is empowered
> 	and trusted to act responsibly.

Same as before: the NCC is the caretaker of our RIPE Database. If the NCC needs to update the database to improve accuracy then I don't see why we would limit that to a smaller scope than 'the RIPE database'.

>> 8. The provision of some RIPE NCC services is dependent on whether
>> the resources are PA or PI. The RIPE NCC will require clear
>> guidelines on the terms under which Legacy Internet Resources
>> would be offered these services.
> 
> 	Only Registration Services are within scope for this
> 	proposal.
> 
> 	Legacy resources are neither PA nor PI, but LEGACY,
> 	and need to be supported by Registration Services.
> 
> 	If the policy proposal is unclear, it will be helpful
> 	to have this indicated, either by reference to more
> 	detailed text in the current Impact Assessment, or by
> 	further clarification.
> 
> 	Otherwise, the preparation of operational guidelines
> 	consistent with RIPE policy as developed from time to
> 	time, seems to me to be the responsibility of the RIPE 
> 	NCC, subject to due oversight and confirmation from
> 	the community.

Saying that "resources are PA or PI" is indeed too limiting here. If this policy is accepted then the NCC needs to be able to handle LEGACY resources as well. 

>> 9. Currently arbitration does not apply to Legacy Internet
>> Resources.  Amendments to the arbitration procedure are subject
>> to approval by the GM.
> 
> 	Please see my comment to point 4.

+1

>> 10. If the proposal is accepted, the RIPE NCC will have to contact
>> Legacy Resource Holders that have their resources registered under
>> the umbrella of an LIR and offer them the contractual options of
>> the accepted proposal. The RIPE NCC will consider any requests for
>> this since 1992 as having never been submitted.
> 
> 	If such a LIR is acting as an ad-hoc registration intermediary,
> 	the situation may be seen as sufficiently irregular as to
> 	require attention whether or not the proposal is accepted.
> 
> 	Otherwise, a variation to a Sponsoring-LIR agreement will
> 	be needed, which is the responsibility of each LIR involved.
> 
> 	I'ld like to have further explanation of the last sentence,
> 	referring to 1993, as I don't understand it.

I guess that was when the NCC started. Explicitly saying that instead of mentioning a specific year would be better if I'm right. Otherwise: NCC: please explain the intention.

>> 11. If the community decides that this proposal should allow for
>> the certification of Legacy Internet Resources, the RIPE NCC will
>> need to create a certification system specific to these resources.
> 
> 	Probably.
> 
> 	I understand that another current proposal aims to allow 
> 	certification of PI resources.  It may be opportune to 
> 	create a multivalent certification system supporting 
> 	different kinds of resources.

As both PI and LEGACY resources allow the use of a Sponsoring LIR I would imagine the implementation to be roughly the same. What would be so special about legacy resources that it would need a certification system specific to those resources?

>> 12. The RIPE NCC is seeking guidance from the community on who
>> should be considered the legitimate holder of Legacy Internet
>> Resources that have been distributed through several layers
>> of hierarchy.
> 
> 	This is a significant problem, which arises whether or
> 	not the current policy proposal is accepted.
> 
> 	I'm not sure what specific impact this policy proposal 
> 	has on the problem.  I can see that it changes the context,
> 	but neither that it makes the problem either more or less
> 	intractable nor that it affects the nature of the work to
> 	be done.

The NCC already handles Legacy Resource Holders who want their resources to be treated as resources allocated by the RIPE NCC (see item 3). The procedures that are used for that would be a good starting point I guess. I think this guidance should not be put into policy at this point in time. For further guidance it might be useful to discuss this at a future RIPE meeting.

>> 13. RIPE Database objects referring to Legacy Internet Resources
>> currently have several different "status:" attribute values.
>> The RIPE NCC proposes changing these to 'LEGACY'.
> 
> 	This seems reasonable.

+1

>> 14. The RIPE NCC also proposes introducing a mandatory "status:"
>> attribute for all AUT-NUM objects which would take the value
>> 'LEGACY' for all legacy AS numbers. For all other AS numbers
>> the values would either be set to 'ASSIGNED' (assigned by the
>> RIPE NCC) or 'OTHER' (assigned by other RIRs).
> 
> 	This also seems reasonable.

+1

Thank you!
Sander