[address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies

Dear Leo,

Leo Vegoda wrote:

> On 28 Jan 2010, at 7:25, Filiz Yilmaz wrote:

thanks for the detailed analysis and comments!

Looking at the framework within this exercise is meant to happen, I have
the strong opinion that the proposed changes, clarifications and additions
(and some more that c|should be incorporated, as well) do not fit within
the "editorial changes", "clarification of language" constraints.

My feeling is that the changes should either be strictly limited to those
obviously covered by the "editorial changes/clarification" headlines or
we should rather take this as an opportunity to really bring this policy
up-to-date.

This would of course imply using the regular set of rules of the PDP,
imho - which in this particular case I would certainly prefer!

Then we can easily include stuff related to contracts, think about, agree
and clearly state to which AS#s the formal requirement to return applies to
(all? only distributed by way of NCC/LIR-chain?), and where to (NCC? original
LIR? IANA for the legacy ones?)....

Wilfried.

>>Dear Colleagues,
>>
>>At the RIPE 59 Meeting in Lisbon last October, the RIPE NCC announced  
>>that it would undertake a project to improve the language of various  
>>RIPE policy documents, without changing their substance or meaning.  
>>This project is aimed at improving the clarity and readability of RIPE  
>>Documents.
> 
> 
> This is good.
> 
> [...]
> 
> 
>>A draft of the first RIPE Document to be revised is now available:  
>>"Autonomous System (AS) Number Assignment Policies and Procedures".
> 
> 
> I think the update makes the document more readable and easier to understand.
> 
> In 1.0 I am uncomfortable with the reference to RFC 1771 as it was obsoleted by RFC 4271 several years ago. I think it would be helpful to refer to the most current Standards Track RFC.
> 
> The new section 2.0 is useful as it separates the assignment criteria from the definition of the resource. I also like the simplicity of the new language used to describe the policy. I do not think it changes the policy in any way but I am sure that it makes the meaning clearer to people who are not familiar with the subject.
> 
> In section 3.1, the document refers to RFC 2026 but this has been updated by several RFCs. It might be most useful to refer to BCP 9, which includes all the relevant and current RFCs. Also, in this section, there is an example of how the experiment proposal should be published but not the results. Arguably, the results are at least as important as the proposal and it would be helpful to remove any ambiguity and give an example of acceptable publication mechanisms.
> 
> In 3.3 I think the document is saying that the network operator must renumber from the experiment ASN to a new ASN if it wants to continue using the network for commercial or other purposes after the experiment has concluded. If this is the case I think it should be spelled out in crystal clear text in this section so that there is no ambiguity. It would probably save on an argument in the case that an experiment is successful and the operator wants to commercialise it.
> 
> I have a question about the meaning of the text in 5.0. It doesn't make any mention of the contract referred to in 2.0. I think it would be helpful to clarify in the text that an ASN must be returned or reclaimed in the event that a contract lapses. And if I have misunderstood then I think the reverse should be stated.
> 
> Finally, while I don't object to the text in 6.0 I don't think the whole timeline needs to be included in this version of the document as we have already passed 1 January 2010. Just stating that "the RIPE NCC ceased to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers on 1 January 2010, and makes AS Number assignments from an undifferentiated 32-bit AS Number pool" would probably be sufficient.
> 
> All told, a very nice job. But the ASN policy is the easiest of the main three policies. IPv4 and IPv6 will be much harder work, I am sure.
> 
> Regards,
> 
> Leo Vegoda
>