2008-09 New Policy Proposal (ASPLAIN Format for the Registration of 4-byte ASNs)
PDP Number: 2008-09 ASPLAIN Format for the Registration of 4-byte ASNs Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-09.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 17 November 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
On 20 okt 2008, at 16:50, Filiz Yilmaz wrote:
PDP Number: 2008-09 ASPLAIN Format for the Registration of 4-byte ASNs
Dear Colleagues,
A new RIPE Policy Proposal has been made and is now available for discussion.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2008-09.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 17 November 2008.
I'm not against this proposal, as ripe should follow standards where the apply. I like however the idea of a more generic one stating that ripe should follow formatting standards and change all current documents should one of these standards change. It seems rather cumbersome to file a change proposal for each and every individual document where it basically comes down to a cosmetic change following international standards and will prevent us from a lot of discussion and the small risk some of these changes won't get consensus and we end up with 2 different models. Groet, MarcoH
It seems rather cumbersome to file a change proposal for each and every individual document where it basically comes down to a cosmetic change following international standards and will prevent us from a lot of discussion and the small risk some of these changes won't get consensus and we end up with 2 different models. Apart from this, it seems prudent to wait until draft-ietf-idr-as-representation-01.txt will become an official standard. Then it can be properly quoted. Since it is not defining a protocol, it is more likely to become a BCP anyway. jaap
On Oct 20, 2008, at 9:27 AM, Jaap Akkerhuis wrote:
It seems rather cumbersome to file a change proposal for each and every individual document where it basically comes down to a cosmetic change following international standards and will prevent us from a lot of discussion and the small risk some of these changes won't get consensus and we end up with 2 different models.
Apart from this, it seems prudent to wait until draft-ietf-idr-as-representation-01.txt will become an official standard. Then it can be properly quoted.
Since it is not defining a protocol, it is more likely to become a BCP anyway.
FWIW, it's being considered currently as Standards Track, not BCP or Informational, although either of those would likely work for this purpose as well. -danny
Jaap Akkerhuis wrote:
It seems rather cumbersome to file a change proposal for each and every individual document where it basically comes down to a cosmetic change following international standards and will prevent us from a lot of discussion and the small risk some of these changes won't get consensus and we end up with 2 different models.
Yes, the proposal should be to move to the same format everywhere the RIPE NCC uses ASN.
Apart from this, it seems prudent to wait until draft-ietf-idr-as-representation-01.txt will become an official standard. Then it can be properly quoted.
Yes, while it is likely that this draft will be accepted, it is by no means certain. Since we have some 14,000 ASN in the 16 bit range left (where all representations are the same), there is no real hurry either. I'd suggest that we wait the +/- 2 months it will take to finalize the draft, then ask the RIPE NCC to "adjust the formatting of AS numbers to the standard set by the IETF everywhere". Henk Speaking as myself, not an NCC employee and not the person who'll be doing the work to move from ASDOT to ASPLAIN. -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk)
Hi, On Tue, Oct 21, 2008 at 08:27:01AM +0200, Henk Uijterwaal wrote:
Yes, while it is likely that this draft will be accepted, it is by no means certain. Since we have some 14,000 ASN in the 16 bit range left (where all representations are the same), there is no real hurry either.
Except that the NCC will hand out 4-byte ASNs by default starting January 1st...
From Ripe-406:
----------------- snip --------------
From 1 January 2009, you can use the Supplemental Comments field to let us know if you would like a 2-byte AS Number. If you give no preference, we will assign a 4-byte AS Number. ----------------- snip --------------
Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert,
On Tue, Oct 21, 2008 at 08:27:01AM +0200, Henk Uijterwaal wrote:
Yes, while it is likely that this draft will be accepted, it is by no means certain. Since we have some 14,000 ASN in the 16 bit range left (where all representations are the same), there is no real hurry either.
Except that the NCC will hand out 4-byte ASNs by default starting January 1st...
From Ripe-406:
----------------- snip --------------
From 1 January 2009, you can use the Supplemental Comments field to let us know if you would like a 2-byte AS Number. If you give no preference, we will assign a 4-byte AS Number. ----------------- snip --------------
When this text was written, the idea was that one would get an ASN32, that is a nummber in the range 0 to 4.10^9. There was an option to get for a number in the 0-65536 range if you specifically asked for it. The text doesn't say that the RIRs cannot give out the numbers in the lower range in other cases. The background was that one estimate showed that we'd be close to the point where all ASN16 were assigned by 1/1/9, so it'd be good to keep the few remaining ones for special cases. In reality, it turns out that we now still have some 14,000 left, so handing out a few more from the <65536 range while we're sorting out how to format the numbers above 65536 doesn't seem to be a big issue to me. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk)
Hi Henk, Going off on a slight tangent... :)
When this text was written, the idea was that one would get an ASN32, that is a nummber in the range 0 to 4.10^9.
That doesn't quite match RIPE-389, which says the following: -------------------- 1.9 4-Byte AS Numbers RIPE NCC will assign 4-Byte AS Numbers according to the following timeline: * From 1 January 2007 the RIPE NCC will process applications that specifically request 4-byte only AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 4-byte only AS Number, a 2-byte only AS Number will be assigned by the RIPE NCC. * From 1 January 2009 the RIPE NCC will process applications that specifically request 2-byte only AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 2-byte only AS Number, a 4-byte only AS Number will be assigned by the RIPE NCC. * From 1 January 2010 the RIPE NCC will cease to make any distinction between 2-byte only AS Numbers and 4-byte only AS Numbers, and will operate AS Number assignments from an undifferentiated 4- byte AS Number allocation pool. Terminology "2-byte only AS Numbers" refers to AS Numbers in the range 0 - 65535 "4-byte only AS Numbers" refers to AS Numbers in the range 1.0 - 65535.65535 (decimal range 65,536 - 4,294,967,295) "4-byte AS Numbers" refers to AS Numbers in the range 0.0 - 65535.65535 (decimal range 0 - 4,294,967,295) -------------------- It says "4-byte only" (i.e. above 65535) as of the start of next year... Of course, I'm sure this won't prevent the RIPE NCC being a bit more pragmatic in their approach whilst the procedures and documentation is sorted out. :) Cheers, Rob
Hi Rob,
When this text was written, the idea was that one would get an ASN32, that is a nummber in the range 0 to 4.10^9.
That doesn't quite match RIPE-389, which says the following:
It says "4-byte only" (i.e. above 65535) as of the start of next year...
Of course, I'm sure this won't prevent the RIPE NCC being a bit more pragmatic in their approach whilst the procedures and documentation is sorted out. :)
Hmm, my memory seems to be a little different from the policy. Anyway, I still don't think that there is an operational need to assign above 65535 as of 1/1, while the discussion and implementation of the formatting converges. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk)
Hi all, I think the following announcement from the IESG is relevant for this discussion (sent yesterday, 27/10 @ 20:00). For those not familiar with the IETF process, this means that the document will now become an RFC in the next couple of weeks. Henk - - - - The IESG has approved the following document: - 'Textual Representation of AS Numbers ' <draft-ietf-idr-as-representation-01.txt> as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt Technical Summary A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS Number. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. asplain refers to a syntax scheme of representing all AS numbers using decimal integer notation. Using asplain notation an AS number of value 65526 would be represented as the string "65526" and an AS number of value 65546 would be represented as the string "65546". Working Group Summary It was readily accepted. Document Quality No issues Personnel Dave Ward -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk)
[ trimmed the cc list to continue in AP only ] Gert Doering wrote: [...]
Except that the NCC will hand out 4-byte ASNs by default starting January 1st...
Yes, but they will be the same 23 bits anyway, not being "modified" by the syntax used to register them in the DB. Much like a CIDR notation for a block of addresses is equivalent to a range notation...
From Ripe-406:
----------------- snip -------------- From 1 January 2009, you can use the Supplemental Comments field to let us know if you would like a 2-byte AS Number. If you give no preference, we will assign a 4-byte AS Number. ----------------- snip --------------
Gert Doering -- APWG chair
While I appreciate the fact that this proposal is managed and dicussed in Address Policy, for formal reasons explained already, I'd really like to see statements of support (or against?) from those parties which/who have to "use" those beasts. Which imho is more a matter of routing, ie. product develepment, UI, scripts, tools... Wilfried.
while we can hope that the ietf and rfced will process the asplain draft before eoy, when the rirs start issuing 4-byte asns, there is no need to bet on it. after all, the ietf was not very swift about processing the base 4-byte asn draft, were they? but there is no need for pissing contests or constitutional crises. i suggest that ripe just proceed with achieving community consensus on the policy path, but stall in making it formal. given passage of the policy, the ncc can prepare implementation. then, if the ietf/rfced come through on time, it's a win. if they don't then the ncc uses asplain by community consensus policy and the ietf can catch up at their own pace. this is essentially the same as apnic is doing for asns reserved for documentation. the only difference is that other regions have no need to do policy as all can use the docco asns issued by apnic if the ietf does not come through as hoped. life can be simple. randy
On 22/10/2008, at 12:47 AM, Randy Bush wrote:
while we can hope that the ietf and rfced will process the asplain draft before eoy, when the rirs start issuing 4-byte asns, there is no need to bet on it. after all, the ietf was not very swift about processing the base 4-byte asn draft, were they?
in the meantime the IETF has completed its work: 28th October 2008 Protocol Action: 'Textual Representation of AS Numbers' to Proposed Standard The IESG has approved the following document: - 'Textual Representation of AS Numbers ' <draft-ietf-idr-as-representation-01.txt> as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt Technical Summary A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS Number. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. asplain refers to a syntax scheme of representing all AS numbers using decimal integer notation. Using asplain notation an AS number of value 65526 would be represented as the string "65526" and an AS number of value 65546 would be represented as the string "65546". Working Group Summary It was readily accepted. Document Quality No issues Personnel Dave Ward
while we can hope that the ietf and rfced will process the asplain draft before eoy ^^^^^^^^^^^^^^ in the meantime the IETF has completed its work:
which is cheering. and when the process, which includes publication as an rfc, actually completes by eoy, we will not need the policy. and i think that we all have every hope they will complete the process. but, if perchance they do not, the rirs need to be prepared to record issuance 4 byte asns on 1 jan. hence the policy we hope we don't need. randy
Filiz Yilmaz wrote:
You can find the full proposal at:
Can definitely support this. ASDOT is a broken representation and has no merit of any substance. Not only that, the two arguments opposing the proposal are irrelevant. - "ASDOT is more easily remembered" For the foreseeable future, after the first 10k assignments of ASN32s in a particular 16 bit ASN block range (e.g. AS3.x), both ASDOT and ASPLAIN formats will be represented using similar numbers of digits. - "All existing 4-byte only assignments have been made in ASDOT" As of today, RIPE has assigned 19 ASN32s. Changing the representation for these 19 holders (most of whom will have requested them for testing purposes anyway) is not going to be a major issue. ASPLAIN representation is important for anyone who is in the business of writing or maintaining BGP prefix and AS path filters, either router-side or script-side. In this area, ASDOT format is just a bagful of hurt with no redeeming features whatever. Incidentally, the following documents will also need to be updated: RIPE Database Query Reference Manual, section 2.3 RIPE Database Update Reference Manual, section 1.2.3 RIPE Database Update Reference Manual, table A1 However, as the RIPE database manual is outside the context of the PDP, it is probably appropriate to omit this from the policy proposal. It's important that this policy proposal be passed before Jan 1, 2009, when the RIPE NCC starts issuing ASN32s by default. After this date, it will become a lot more difficult to clean up the mess that's going to happen. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
I 100% agree with all of the points stated by Nick below and I also urge RIPE to implement this change QUICKLY.
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Nick Hilliard Sent: 20 October 2008 16:19 To: address-policy-wg@ripe.net Cc: routing-wg@ripe.net; db-wg@ripe.net Subject: Re: [address-policy-wg] 2008-09 New Policy Proposal (ASPLAIN Format for the Registration of 4-byte ASNs)
Filiz Yilmaz wrote:
You can find the full proposal at:
Can definitely support this.
ASDOT is a broken representation and has no merit of any substance. Not only that, the two arguments opposing the proposal are irrelevant.
- "ASDOT is more easily remembered"
For the foreseeable future, after the first 10k assignments of ASN32s in a particular 16 bit ASN block range (e.g. AS3.x), both ASDOT and ASPLAIN formats will be represented using similar numbers of digits.
- "All existing 4-byte only assignments have been made in ASDOT"
As of today, RIPE has assigned 19 ASN32s. Changing the representation for these 19 holders (most of whom will have requested them for testing purposes anyway) is not going to be a major issue.
ASPLAIN representation is important for anyone who is in the business of writing or maintaining BGP prefix and AS path filters, either router-side or script-side. In this area, ASDOT format is just a bagful of hurt with no redeeming features whatever.
Incidentally, the following documents will also need to be updated:
RIPE Database Query Reference Manual, section 2.3 RIPE Database Update Reference Manual, section 1.2.3 RIPE Database Update Reference Manual, table A1
However, as the RIPE database manual is outside the context of the PDP, it is probably appropriate to omit this from the policy proposal.
It's important that this policy proposal be passed before Jan 1, 2009, when the RIPE NCC starts issuing ASN32s by default. After this date, it will become a lot more difficult to clean up the mess that's going to happen.
Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
On 20 okt 2008, at 17:41, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I 100% agree with all of the points stated by Nick below and I also urge RIPE to implement this change QUICKLY.
And on all documents/tools/websites and not only this document. Groet, MarcoH
Hi Nick,
- "ASDOT is more easily remembered"
For the foreseeable future, after the first 10k assignments of ASN32s in a particular 16 bit ASN block range (e.g. AS3.x), both ASDOT and ASPLAIN formats will be represented using similar numbers of digits.
I agree, both with your sentiment and the proposal, but the "more easily remembered" tag is a bit more than irrelevant. Whilst the low-order 16 bits might not be memorable, it might be quite easy to keep up with which registries have used which upper 16 bits for a little while, so manual 'whois' queries can be directed to the appropriate server. Cheers, Rob
Rob Evans wrote:
I agree, both with your sentiment and the proposal, but the "more easily remembered" tag is a bit more than irrelevant. Whilst the low-order 16 bits might not be memorable, it might be quite easy to keep up with which registries have used which upper 16 bits for a little while, so manual 'whois' queries can be directed to the appropriate server.
Why would _YOU_ worry about memorizing which RIR to forward a query to? I thought that's what we have computers & programs for ;) I also agree with the proposal; amongst other things, AS regex would be a nightmare with different representation (except maybe automagically converting all 16 Bit AS to 0.x format) -garry
Indeed. FOr some time now the RIRs have backed the joint whois project, which is operated by LACNIC. http://lacnic.net/cgi-bin/lacnic/whois?lg=EN or whois -h whois.lacnic.net There is no format translation, you get the native thing from each of the registries (with a note for the source of the info at the beginning) Why would you use any other whois server for IP/ASNs/RPSL? Joao On 20 Oct 2008, at 20:47, Garry Glendown wrote:
Rob Evans wrote:
I agree, both with your sentiment and the proposal, but the "more easily remembered" tag is a bit more than irrelevant. Whilst the low-order 16 bits might not be memorable, it might be quite easy to keep up with which registries have used which upper 16 bits for a little while, so manual 'whois' queries can be directed to the appropriate server.
Why would _YOU_ worry about memorizing which RIR to forward a query to? I thought that's what we have computers & programs for ;)
I also agree with the proposal; amongst other things, AS regex would be a nightmare with different representation (except maybe automagically converting all 16 Bit AS to 0.x format)
-garry
On Oct 22, 2008, at 10:46, Joao Damas wrote:
Why would you use any other whois server for IP/ASNs/RPSL?
Shouldn't the question be "why would anyone use any whois server for anything?"? :-)
Fellow WG, I concur fully on Nick's position, quoted below. Best regards, Daniel On Mon, Oct 20, 2008 at 04:18:48PM +0100, Nick Hilliard wrote:
Filiz Yilmaz wrote:
You can find the full proposal at:
Can definitely support this.
ASDOT is a broken representation and has no merit of any substance. Not only that, the two arguments opposing the proposal are irrelevant.
- "ASDOT is more easily remembered"
For the foreseeable future, after the first 10k assignments of ASN32s in a particular 16 bit ASN block range (e.g. AS3.x), both ASDOT and ASPLAIN formats will be represented using similar numbers of digits.
- "All existing 4-byte only assignments have been made in ASDOT"
As of today, RIPE has assigned 19 ASN32s. Changing the representation for these 19 holders (most of whom will have requested them for testing purposes anyway) is not going to be a major issue.
ASPLAIN representation is important for anyone who is in the business of writing or maintaining BGP prefix and AS path filters, either router-side or script-side. In this area, ASDOT format is just a bagful of hurt with no redeeming features whatever.
Incidentally, the following documents will also need to be updated:
RIPE Database Query Reference Manual, section 2.3 RIPE Database Update Reference Manual, section 1.2.3 RIPE Database Update Reference Manual, table A1
However, as the RIPE database manual is outside the context of the PDP, it is probably appropriate to omit this from the policy proposal.
It's important that this policy proposal be passed before Jan 1, 2009, when the RIPE NCC starts issuing ASN32s by default. After this date, it will become a lot more difficult to clean up the mess that's going to happen.
Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 17 November 2008.
I am opposed to this proposal because it seems completely inappropriate to use a PDP for something this straightforward and low-level. Also, this issue goes beyond RIPE and is about development of an industry standard. It is not a RIPE-specific issue. There are more appropriate other fora for developing industry standards. RIPE (and indeed all RIRs) should defer to other industry bodies for development of technical standards. Note that the IETF is currently finalizing the document draft-ietf-idr-as-representation-01.txt already. Indeed, the IESG will be formally considering it this week, so with a little bit of luck, it will be an RFC in a month. At that point, it would be fine for RIPE to adopt that standard, but I would hope that it could do so without requiring a PDP. (Does RIPE generally need a PDP before it is allowed to start using an IETF standards?) Let's keep things simple please! PS, if there are any objections to draft-ietf-idr-as-representation-01.txt becoming the standard for ASN representation, make your opinions known to the IETF immediately! Thomas
[ restricting my reply to the ap-wg list ] Thomas, Thomas Narten wrote:
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 17 November 2008.
I am opposed to this proposal because it seems completely inappropriate to use a PDP for something this straightforward and low-level.
the reason for having to use the PDP is the fact that registration format "ASDOT" is explicitely prescribed in the AS# distribution- policy doc. This was a conscious (but maybe unwise) decision, taken at a time when there was no (standards) rfc available. This has already been explained somewhere on the list(s) iirc.
Also, this issue goes beyond RIPE and is about development of an industry standard. It is not a RIPE-specific issue. There are more appropriate other fora for developing industry standards. RIPE (and indeed all RIRs) should defer to other industry bodies for development of technical standards.
Note that the IETF is currently finalizing the document draft-ietf-idr-as-representation-01.txt already. Indeed, the IESG will be formally considering it this week, so with a little bit of luck, it will be an RFC in a month.
At that point, it would be fine for RIPE to adopt that standard, but I would hope that it could do so without requiring a PDP. (Does RIPE generally need a PDP before it is allowed to start using an IETF standards?)
I presume in general the answer would be NO to your (question). But please stop bashing RIPE for respecting its own internal procedures.
Let's keep things simple please!
Indeed, but I guess you would not recommend to "simply" change a formally adopted policy document, would you? This could be seen as a nasty precedent...
PS, if there are any objections to draft-ietf-idr-as-representation-01.txt becoming the standard for ASN representation, make your opinions known to the IETF immediately!
Thomas
Wilfried.
Hi Wilfried.
the reason for having to use the PDP is the fact that registration format "ASDOT" is explicitely prescribed in the AS# distribution- policy doc. This was a conscious (but maybe unwise) decision, taken at a time when there was no (standards) rfc available.
Sorry but I did miss this detail. I do think it is unfortunate to tie this sort of detail into things that require PDPs to change.
This has already been explained somewhere on the list(s) iirc.
Also, this issue goes beyond RIPE and is about development of an industry standard. It is not a RIPE-specific issue. There are more appropriate other fora for developing industry standards. RIPE (and indeed all RIRs) should defer to other industry bodies for development of technical standards.
Note that the IETF is currently finalizing the document draft-ietf-idr-as-representation-01.txt already. Indeed, the IESG will be formally considering it this week, so with a little bit of luck, it will be an RFC in a month.
At that point, it would be fine for RIPE to adopt that standard, but I would hope that it could do so without requiring a PDP. (Does RIPE generally need a PDP before it is allowed to start using an IETF standards?)
I presume in general the answer would be NO to your (question). But please stop bashing RIPE for respecting its own internal procedures.
Wouldn't it be better then to use the PDP to undo the previous requirement, but leave it as an operational matter as to what the exact format should be? Coupled, of course, with a _suggestion_ as to the preferred format as opposed to a _requirement_? I.e., undo the previous requirement but not replace it with another firm/inflexible requirement? In general, isn't this how these sorts of details are worked out?
Let's keep things simple please!
Indeed, but I guess you would not recommend to "simply" change a formally adopted policy document, would you? This could be seen as a nasty precedent...
No, of course not. So looking forward, what can be done so that future changes like this will not require a PDP to make further (minor) updates? I would think it best not to require the use of PDPs to handle these sorts of things. Thomas
Thomas and all, Interesting circular argument... Thomas Narten wrote:
Hi Wilfried.
the reason for having to use the PDP is the fact that registration format "ASDOT" is explicitely prescribed in the AS# distribution- policy doc. This was a conscious (but maybe unwise) decision, taken at a time when there was no (standards) rfc available.
Sorry but I did miss this detail. I do think it is unfortunate to tie this sort of detail into things that require PDPs to change.
This has already been explained somewhere on the list(s) iirc.
Also, this issue goes beyond RIPE and is about development of an industry standard. It is not a RIPE-specific issue. There are more appropriate other fora for developing industry standards. RIPE (and indeed all RIRs) should defer to other industry bodies for development of technical standards.
Note that the IETF is currently finalizing the document draft-ietf-idr-as-representation-01.txt already. Indeed, the IESG will be formally considering it this week, so with a little bit of luck, it will be an RFC in a month.
At that point, it would be fine for RIPE to adopt that standard, but I would hope that it could do so without requiring a PDP. (Does RIPE generally need a PDP before it is allowed to start using an IETF standards?)
I presume in general the answer would be NO to your (question). But please stop bashing RIPE for respecting its own internal procedures.
Wouldn't it be better then to use the PDP to undo the previous requirement, but leave it as an operational matter as to what the exact format should be? Coupled, of course, with a _suggestion_ as to the preferred format as opposed to a _requirement_? I.e., undo the previous requirement but not replace it with another firm/inflexible requirement?
In general, isn't this how these sorts of details are worked out?
Let's keep things simple please!
Indeed, but I guess you would not recommend to "simply" change a formally adopted policy document, would you? This could be seen as a nasty precedent...
No, of course not. So looking forward, what can be done so that future changes like this will not require a PDP to make further (minor) updates? I would think it best not to require the use of PDPs to handle these sorts of things.
Thomas
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
On Oct 22, 2008, at 5:00 PM, Wilfried Woeber, UniVie/ACOnet wrote:
I presume in general the answer would be NO to your (question). But please stop bashing RIPE for respecting its own internal procedures.
I agree with Thomas and I don't see this as 'RIPE bashing' merely as an attempt to keep things simple and avoid lengthy debates on something trivial, especially in this case where the pros and cons should be raised in the IETF.
Let's keep things simple please!
Indeed, but I guess you would not recommend to "simply" change a formally adopted policy document, would you? This could be seen as a nasty precedent...
You have a point there and it we might call it an oversight in the PDP to not be able to handle small changes in formatting or typos without going through the whole process again. So for the sake of it all, let's adopt this change using the current proces and focus the discussion on how to handle such changes in the future. I don't expect it to happen much, but the way you put it a small cosmetic error can result in going over a lenghty discussion again and might be a tool to bend things differently by the need to reach consensus again. MarcoH
Marco, On Wed, 2008-10-22 at 17:41 +0200, Marco Hogewoning wrote:
Let's keep things simple please!
Indeed, but I guess you would not recommend to "simply" change a formally adopted policy document, would you? This could be seen as a nasty precedent...
You have a point there and it we might call it an oversight in the PDP to not be able to handle small changes in formatting or typos without going through the whole process again. So for the sake of it all, let's adopt this change using the current proces and focus the discussion on how to handle such changes in the future. I don't expect it to happen much, but the way you put it a small cosmetic error can result in going over a lenghty discussion again and might be a tool to bend things differently by the need to reach consensus again.
I agree. Right now there *is* no other way to change policies, right? I found Thomas' comment a bit strange - like asking the IETF to create a standard without an Internet draft. But he does have a point that the PDP may be heavyweight in cases like this. So you are right, lets tweak the PDP. :) Cheers, -- Shane
Shane, On Thu, Oct 23, 2008 at 09:30:10PM +0200, Shane Kerr wrote:
On Wed, 2008-10-22 at 17:41 +0200, Marco Hogewoning wrote:
Let's keep things simple please!
Indeed, but I guess you would not recommend to "simply" change a formally adopted policy document, would you? This could be seen as a nasty precedent...
You have a point there and it we might call it an oversight in the PDP to not be able to handle small changes in formatting or typos without going through the whole process again. So for the sake of it all, let's adopt this change using the current proces and focus the discussion on how to handle such changes in the future. I don't expect it to happen much, but the way you put it a small cosmetic error can result in going over a lenghty discussion again and might be a tool to bend things differently by the need to reach consensus again.
I agree.
Right now there *is* no other way to change policies, right? I found Thomas' comment a bit strange - like asking the IETF to create a standard without an Internet draft.
But he does have a point that the PDP may be heavyweight in cases like this. So you are right, lets tweak the PDP. :)
I don't think Thomas comments were strange at all. It is complete overkill to use the policy process to deal with *conventions* on how to write down a particular resource. However, it was explained quite well why we encountered this problem and it seems reasonable to use a policy proposal to get around it. However, the new proposal again creates a dependancy on a particular format instead of leaving the format out of the policy. If the proposal would read like (new text): 1.9 4-byte AS Numbers . . . Terminology "2-byte only AS Numbers" refers to AS Numbers in the range 0 - 65535 "4-byte only AS Numbers" refers to AS Numbers in the range 65536 - 4294967295 "4-byte AS Numbers" refers to AS Numbers in the range 0 - 4294967295 we would not refer to any particular format and we can just proceed whether the IETF is ready to approve ASPLAIN format or not. Also, I noticed that it is kind of strange that the policy document has no reference whatsoever to the IETF document that actually defines 4-octet AS numbers. Note that IETF uses 'octet' in their terminology, while the policy document uses the word 'byte'. Personally, I don't particularly care but it might be more consistant to use the same terminology. David Kessens ---
participants (21)
-
Daniel Roesen -
Danny McPherson -
David Kessens -
Filiz Yilmaz -
Garry Glendown -
Geoff Huston -
Gert Doering -
Henk Uijterwaal -
Jaap Akkerhuis -
Jeffrey A. Williams -
Jim Reid -
Joao Damas -
Marco Hogewoning -
michael.dillonļ¼ bt.com -
Nick Hilliard -
Randy Bush -
Rob Evans -
Rob Evans -
Shane Kerr -
Thomas Narten -
Wilfried Woeber, UniVie/ACOnet