2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal)
PDP Number: 2005-12 4-Byte AS Number Policy Proposal Dear Colleagues A new RIPE policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-12.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 22 January 2006. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager
At 04:27 PM 23/12/2005, RIPE NCC Policy Coordinator wrote:
PDP Number: 2005-12 4-Byte AS Number Policy Proposal
Dear Colleagues
A new RIPE policy has been proposed and is now available for discussion.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2005-12.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 22 January 2006.
After this date, we will prepare a draft RIPE Document. We will let you know when this is available.
This policy was submitted to all five RIRs in early December. In the intervening period the discussion on the ARIN policy discussion mailing list has undoubtedly been the most active of all the regions. For those who do not follow the ARIN list, the points arising from that discussion as they relate to changes in the text of the policy so far appear to be: a) that the section on terminology should use a period as a separator between the high and low 16 bit fields rather than a colon as originally proposed, in order to reduce confusion with delimiters in BGP communities b) that the proposal replace the term "2 byte" with "16 bit" and "4 byte" with "32 bit" due to the somewhat imprecise nature of the definition of a "byte" Other topics of discussion on the ARIN list have been - whether the terminology and nomenclature sessions should be included in the policy proposal - whether the specification of dates are reasonable in this context - whether the policy alters the current sequential number allocation registry practice - the criteria (if any) that should be applied to a request for an AS number of the "other" type - the desireable size of the private use AS number pool No further changes to the policy are proposed at this point in time as a clear outcome of these discussions. Its also worth noting that this is intended to be a temporary policy associated with transition to the larger number pool, and at the end of the period, proposed to be 1 January 2010, this policy is no longer in force, and the larger 32-bit AS number space will be managed as a single pool using the current policies and procedures. regards, Geoff
On 26 Dec, 2005, at 21:28, Geoff Huston wrote:
b) that the proposal replace the term "2 byte" with "16 bit" and "4 byte" with "32 bit" due to the somewhat imprecise nature of the definition of a "byte"
why not use octet, which is the language used in the i-d?
Other topics of discussion on the ARIN list have been - whether the terminology and nomenclature sessions should be included in the policy proposal
If policy is what decides if a requester gets the resource or not, then no, as this sounds more like local implementation (procedure), like most of the text (except for the dates, perhaps, which set what gets assigned and when)
- whether the specification of dates are reasonable in this context
is this a question of whether the suggested dates are appropriate or whether any dates are appropriate?
- whether the policy alters the current sequential number allocation registry practice - the criteria (if any) that should be applied to a request for an AS number of the "other" type - the desireable size of the private use AS number pool
Would the policy need a reference to the IANA as the ultimate caretaker of the registry? Joao
At 02:11 AM 29/12/2005, João Damas wrote:
On 26 Dec, 2005, at 21:28, Geoff Huston wrote:
b) that the proposal replace the term "2 byte" with "16 bit" and "4 byte" with "32 bit" due to the somewhat imprecise nature of the definition of a "byte"
why not use octet, which is the language used in the i-d?
no particular reason - I'm sure in any room half would prefer "bits" and half "octets" I'm personally inclined to use "bits" in preference to "octets"
Other topics of discussion on the ARIN list have been - whether the terminology and nomenclature sessions should be included in the policy proposal
If policy is what decides if a requester gets the resource or not, then no, as this sounds more like local implementation (procedure), like most of the text (except for the dates, perhaps, which set what gets assigned and when)
However it does make the policy proposal clearer to read!
- whether the specification of dates are reasonable in this context
is this a question of whether the suggested dates are appropriate or whether any dates are appropriate?
the latter - the ARIN discussion has appeared to head towards a conclusion that the dates are the critical part of the proposal, and to remove them from the proposal would make the entire exercise somewhat meaningless. I concur with that view.
- whether the policy alters the current sequential number allocation registry practice - the criteria (if any) that should be applied to a request for an AS number of the "other" type - the desireable size of the private use AS number pool
Would the policy need a reference to the IANA as the ultimate caretaker of the registry?
No I do not think so. Nothing else changes in the policy proposal. regards, Geoff
On 28 Dec, 2005, at 21:38, Geoff Huston wrote:
- whether the specification of dates are reasonable in this context
is this a question of whether the suggested dates are appropriate or whether any dates are appropriate?
the latter - the ARIN discussion has appeared to head towards a conclusion that the dates are the critical part of the proposal, and to remove them from the proposal would make the entire exercise somewhat meaningless. I concur with that view.
I do too. The way I read this text, the dates are the only real important content of this document. Joao
participants (3)
-
Geoff Huston -
João Damas -
RIPE NCC Policy Coordinator