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

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

> 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