New Draft Document: Autonomous System (AS) Number Assignment Policies
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. For more information, see: http://www.ripe.net/ripe/updated-documents/ A draft of the first RIPE Document to be revised is now available: "Autonomous System (AS) Number Assignment Policies and Procedures". We have published the draft document in two layouts. The first layout contains only the proposed text, in full, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-v1.html The second layout contains both the current text and the proposed text side by side, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-v2.html At the top of both draft documents there is a summary of the proposed changes. There are two changes we would like to highlight because they constitute a slightly larger change. Paragraph 4.0 - Returning AS Numbers Excerpt from current version: "If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers..." Excerpt from proposed draft: "If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers." The main difference is that the current version says the AS Number "can" be returned, while the draft version says the AS Number "must" be returned. The change was made to better reflect the intention of the policy and to be consistent. In other policy documents, for other Internet resources, the wording of the policy states "must". The other larger change is the addition of the following paragraph: Paragraph 5.0 - Validity of an Assignment This paragraph is copied from the IPv4 policy document ("IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"). As this seems to be a shared policy principle, applicable to all Internet resources, we feel it is appropriate to add this text to the AS policy document, both for clarity and consistency. Other smaller changes are listed at the top of document. Please review the text and send your feedback to the Address Policy Working Group mailing list. The period for review is four weeks and lasts until 26 February 2010. After the review period, the Address Policy WG chairs will conclude whether or not there is consensus on the draft document. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC
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
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
...
This would of course imply using the regular set of rules of the PDP, imho - which in this particular case I would certainly prefer!
I second this. Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund
Hi Wilfried, On 5 Feb 2010, at 6:35, Wilfried Woeber, UniVie/ACOnet 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.
I can understand the need to clarify ambiguities through the regular process if they cannot be included in this update to the document. I would request, though, that the RIPE NCC publish a statement on its web site of how it currently interprets the policy where it is not explicitly clear. Kind regards, Leo Vegoda
Filiz, On 2010-01-28 16:25, Filiz Yilmaz wrote:
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. For more information, see:
http://www.ripe.net/ripe/updated-documents/
A draft of the first RIPE Document to be revised is now available: "Autonomous System (AS) Number Assignment Policies and Procedures". Oh, while I did send a mail asking about the 32-bit AS number status, I realize I didn't actually comment on the proposal.
The old document was a bit weird, and the new one makes a lot more sense. -- Shane
participants (5)
-
Andreas Schachtner -
Filiz Yilmaz -
Leo Vegoda -
Shane Kerr -
Wilfried Woeber, UniVie/ACOnet