From memsvcs at arin.net  Fri Dec  2 16:24:20 2005
From: memsvcs at arin.net (Member Services)
Date: Fri, 02 Dec 2005 16:24:20 -0500
Subject: [ppml] Freezing of ip6.int zones
Message-ID: <4390BB84.1070807@arin.net>

As discussed during the most recent Public Policy Meeting, ARIN will be 
complying with RFC4159 and cease maintenance of the ip6.int zones. In 
preparation for the deprecation of ip6.int, ARIN will no longer modify 
any of the zones it administers under ip6.int. This change is effective 
December 7, 2005.

Regards,

Ginny Listman
Director of Engineering
American Registry for Internet Numbers


From memsvcs at arin.net  Mon Dec 12 08:44:33 2005
From: memsvcs at arin.net (Member Services)
Date: Mon, 12 Dec 2005 08:44:33 -0500
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <439D7EC1.2040109@arin.net>

ARIN received the following proposed policy. In accordance with the ARIN 
Internet Resource Policy Evaluation Process, the proposal is being 
posted to the ARIN Public Policy Mailing List and being placed on ARIN's 
website.

The ARIN Advisory Council (AC) will review the proposal and within ten 
working days may decide to:
1)  Support the proposal as is,
2)  Work with the author to clarify, divide or combine one or more 
policy proposals, or
3)  Not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the 
author, then the proposal will be posted as a formal policy proposal to 
the Public Policy Mailing List and it will be presented at the Public 
Policy Meeting. If the AC does not support the proposal, then the author 
may elect to use the petition process to advance the proposal. If the 
author elects not to petition or the petition fails, then the proposed 
policy will be considered closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
	http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
	http://www.arin.net/mailing_lists/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###

Policy Proposal Name:

         4-Byte AS Number Policy Proposal

Author: Geoff Huston
	

Policy Term:		

         Temporary (1 January 2007 - 1 January 2010)

Policy Statement:

         This policy proposal nominates 3 dates for changes to the
         current AS Number allocation policy for the registry:

         On 1 January 2007 the registry will process applications that
         specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.

         On 1 January 2009 the registry will process applications that
         specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.

         On 1 January 2010 the registry will cease to make any
         distinction between 2-byte only AS Numbers and 4-byte only AS
         Numbers, and will operate AS number allocations from an
         undifferentiated 4-byte AS Number allocation pool.

         Nomenclature

         It is proposed to identify 4-byte AS Numbers using a syntax of
         <high order 16 bit value in decimal>:<low order 16 bit value
         in decimal>. Accordingly, a 4-byte AS number of value 65546
         (decimal) would be identified as "1:10".

         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)

Rationale:

         Recent studies of AS number consumption rates indicate that
         the existing 2-byte pool of unallocated AS Numbers will be
         exhausted sometime in the period between 2010 and 2016, absent
         of any concerted efforts of recovery of already-allocated AS
         Numbers [1] [2]. Standardization work in the IETF has produced
         a document that is currently being submitted as a Proposed
         Standard that will expand the AS Number space to a 4-byte
         field [3].

         It is noted that some advance period may be required by
         network operators to undertake the appropriate procedures
         relating to support of 4-byte AS numbers, and while no flag
         day is required in the transition to the longer AS Number
         field, it is recognised that a prudent course of action is to
         allow for allocation of these extended AS numbers well in
         advance of an anticipated 2-byte AS Number exhaustion date.

         This policy proposal details a set of actions and associated
         dates for RIR AS Number allocation policies to assist in an
         orderly transition to use of the 4-byte AS Number space.

         The essential attributes of this policy proposal are to
         facilitate the ease of transitional arrangements by equipment
         vendors, network managers and network operations staff, to
         provide the industry with some predictability in terms of
         dates and associated actions with respect to registry
         operational procedures for AS Number allocations.

         References

         [1]  Daily AS Number Report,
              http://www.potaroo.net/tools/asns
         [2]  ASNs MIA: A Comparision of RIR Statistics and RIS
              Reality, http://www.nanog.org/mtg-0510/wilhelm.html
         [3]  BGP Support for Four-octet AS Number Space,
              draft-ietf-idr-as4bytes-12.txt

Timetable for implementation:

	Procedures to support this proposal need to be implemented
	by 1 January 2007


From andrew.dul at quark.net  Mon Dec 12 12:23:01 2005
From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=)
Date: Mon, 12 Dec 2005 17:23:01 +0000
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <20051212172301.23801.qmail@hoster908.com>

This is proposed as a temporary policy, which to me means that if the policy is approved at some point it will automatically be removed from the NPRM on 1/1/2010.  Which means we will then only have the current AS number policy.  Does everyone feel that the current text will then be sufficient in a 4 byte world?  Or do we need additional text to deal with the new issues in a 4-byte world?

Andrew


***************************
NRPM 
***************************

5. AS Numbers

There are a limited number of available Autonomous System Numbers (AS Numbers), therefore, it is important to determine which sites require unique AS Numbers and which do not. Sites that do not require a unique AS Number should use one or more of the AS Numbers reserved for private use. Those numbers are: 64512 through 65535.

In order to be assigned an AS Number, each requesting organization must provide ARIN with verification that it has one of the following:

   1. A unique routing policy (its policy differs from its border gateway peers)
   2. A multihomed site.

AS Numbers are issued based on current need. An organization should request an AS Number only when it is already multihomed or will immediately become multihomed. Details regarding requirements, fees, and applying for an AS Number can be found on the Guidelines for AS Numbers page.

*******************


>  
>  Policy Proposal Name:
>  
>           4-Byte AS Number Policy Proposal
>  
>  Author: Geoff Huston
>  
>  
>  Policy Term:
>  
>           Temporary (1 January 2007 - 1 January 2010)
>  
>  Policy Statement:
>  
>           This policy proposal nominates 3 dates for changes to the
>           current AS Number allocation policy for the registry:
>  
>           On 1 January 2007 the registry will process applications that
>           specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.
>  
>           On 1 January 2009 the registry will process applications that
>           specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.
>  
>           On 1 January 2010 the registry will cease to make any
>           distinction between 2-byte only AS Numbers and 4-byte only AS
>           Numbers, and will operate AS number allocations from an
>           undifferentiated 4-byte AS Number allocation pool.
>  
>           Nomenclature
>  
>           It is proposed to identify 4-byte AS Numbers using a syntax of
>           <high order 16 bit value in decimal>:<low order 16 bit value
>           in decimal>. Accordingly, a 4-byte AS number of value 65546
>           (decimal) would be identified as "1:10".
>  
>           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)
>  


From william at elan.net  Mon Dec 12 12:28:37 2005
From: william at elan.net (william(at)elan.net)
Date: Mon, 12 Dec 2005 09:28:37 -0800 (PST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051212172301.23801.qmail@hoster908.com>
References: <20051212172301.23801.qmail@hoster908.com>
Message-ID: <Pine.LNX.4.62.0512120928060.6721@sokol.elan.net>


On Mon, 12 Dec 2005, Andrew Dul wrote:

> This is proposed as a temporary policy, which to me means that if the 
> policy is approved at some point it will automatically be removed from 
> the NPRM on 1/1/2010.  Which means we will then only have the current AS 
> number policy.  Does everyone feel that the current text will then be 
> sufficient in a 4 byte world?  Or do we need additional text to deal 
> with the new issues in a 4-byte world?

What issues?

-- 
William Leibzon
Elan Networks
william at elan.net


From andrew.dul at quark.net  Mon Dec 12 13:08:38 2005
From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=)
Date: Mon, 12 Dec 2005 18:08:38 +0000
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <20051212180838.21626.qmail@hoster908.com>

>  -------Original Message-------
>  From: william(at)elan.net <william at elan.net>
>  Subject: Re: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
>  Sent: 12 Dec '05 09:28
>  
>  
>  On Mon, 12 Dec 2005, Andrew Dul wrote:
>  
>  > This is proposed as a temporary policy, which to me means that if the
>  > policy is approved at some point it will automatically be removed from
>  > the NPRM on 1/1/2010.  Which means we will then only have the current AS
>  > number policy.  Does everyone feel that the current text will then be
>  > sufficient in a 4 byte world?  Or do we need additional text to deal
>  > with the new issues in a 4-byte world?
>  
>  What issues?

Suppose I wanted, for some reason, an AS from the old 2-byte space.  Could I request one?   Or maybe I wanted a 4-byte for another reason could I request one be allocated from that range?

Mostly I just asking the question, since moving to a 4-byte world seems to be a pretty big step and we should try and cover the various cases that are going to develop from this change.

Andrew


From billd at cait.wustl.edu  Mon Dec 12 13:31:10 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Mon, 12 Dec 2005 12:31:10 -0600
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <CC5444841A969F4CBBF6A305E569F008030023@kronos.cait.wustl.edu>

I believe the proposal addresses the issue in that it prepares the industry
for the transition and transitions the allocation process allowing
flexibility throughout.
In the end-state, the remaining 2 byte numbers will be allocated in 4 byte
format, right.

bd

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Andrew Dul
> Sent: Monday, December 12, 2005 12:09 PM
> To: ppml at arin.net
> Subject: Re: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
> 
> 
> >  -------Original Message-------
> >  From: william(at)elan.net <william at elan.net>
> >  Subject: Re: [ppml] Proposed Policy: 4-Byte AS Number 
> Policy Proposal
> >  Sent: 12 Dec '05 09:28
> >  
> >  
> >  On Mon, 12 Dec 2005, Andrew Dul wrote:
> >  
> >  > This is proposed as a temporary policy, which to me 
> means that if 
> > the  > policy is approved at some point it will automatically be 
> > removed from  > the NPRM on 1/1/2010.  Which means we will 
> then only 
> > have the current AS  > number policy.  Does everyone feel that the 
> > current text will then be  > sufficient in a 4 byte world?  
> Or do we 
> > need additional text to deal  > with the new issues in a 
> 4-byte world?
> >  
> >  What issues?
> 
> Suppose I wanted, for some reason, an AS from the old 2-byte 
> space.  Could I request one?   Or maybe I wanted a 4-byte for 
> another reason could I request one be allocated from that range?
> 
> Mostly I just asking the question, since moving to a 4-byte 
> world seems to be a pretty big step and we should try and 
> cover the various cases that are going to develop from this change.
> 
> Andrew
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From jeroen at unfix.org  Mon Dec 12 13:36:14 2005
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 12 Dec 2005 19:36:14 +0100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051212180838.21626.qmail@hoster908.com>
References: <20051212180838.21626.qmail@hoster908.com>
Message-ID: <439DC31E.4000604@unfix.org>

Andrew Dul wrote:
>>  -------Original Message-------
>>  From: william(at)elan.net <william at elan.net>
>>
>>  On Mon, 12 Dec 2005, Andrew Dul wrote:
>>  
>>  > This is proposed as a temporary policy, which to me means that if the
>>  > policy is approved at some point it will automatically be removed from
>>  > the NPRM on 1/1/2010.  Which means we will then only have the current AS
>>  > number policy.  Does everyone feel that the current text will then be
>>  > sufficient in a 4 byte world?  Or do we need additional text to deal
>>  > with the new issues in a 4-byte world?
>>  
>>  What issues?
> 
> Suppose I wanted, for some reason, an AS from the old 2-byte space.
> Could I request one?

With Geoff's policy proposal until 2010 you will be able to request
those, after that you won't be able to.

> Or maybe I wanted a 4-byte for another reason could I request one be
> allocated from that range?

After 2007 this proposal should be in effect and you should be able to
request one.

> Mostly I just asking the question, since moving to a 4-byte world
> seems to be a pretty big step and we should try and cover the various
> cases that are going to develop from this change.

It will be a big step indeed, this is why there is a timeframe in the
document to give a clear transitional timeframe, but not a flagday (just
like IPv6 ;) Geoff has run quite a lot of numbers on these subjects and
knowing his other work in this areas his projections are pretty
accurate. ASN's are already at ~40k and have been going out faster the
last couple of years. Moving to 4-byte ASN's will thus be mandatory.
Note also that the draft for the 4-byte ASN's notes that it will be
transparent to most players.


BTW: I support this proposal and would very much like to see this being
proposed to the other RIR's. Geoff, did you also push this in those
directions already? I either haven't seen it yet, though I could have
missed it.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051212/86604c11/attachment.sig>

From gih at apnic.net  Mon Dec 12 15:13:01 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 13 Dec 2005 07:13:01 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <439DC31E.4000604@unfix.org>
References: <20051212180838.21626.qmail@hoster908.com>
	<439DC31E.4000604@unfix.org>
Message-ID: <6.2.0.14.2.20051213070846.02dd3358@kahuna.telstra.net>


>
>BTW: I support this proposal and would very much like to see this being
>proposed to the other RIR's. Geoff, did you also push this in those
>directions already? I either haven't seen it yet, though I could have
>missed it.

Yes, I have submitted the same (or similar as the policy templates differ) 
proposal to all five RIRs on Friday the 9th December (my time). Of course, 
each RIR is able to consider this in their own fashion. However I did feel 
that unless we are able to offer some clear milestones to the industry it 
would be left to the last minute (or, more likely, 5 minutes after the last 
minute :-))

Geoff




From gih at apnic.net  Mon Dec 12 15:07:33 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 13 Dec 2005 07:07:33 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051212172301.23801.qmail@hoster908.com>
References: <20051212172301.23801.qmail@hoster908.com>
Message-ID: <6.2.0.14.2.20051213070245.02dd3730@kahuna.telstra.net>

Andrew,

I haven't been able to identify any long standing issues with 2-byte / 
4-byte number interaction that would merit any further efforts to 
distinguish between the two number pools post 2010. Yes, existing software 
from many vendors cannot today support a local 4-Byte AS number (although 
they can operate quite happily in the situation where other AS numbers 
deploy 4-Byte AS's), but I am of the view that its reasonable to anticipate 
some form of software rollover in the intervening period in those 
situations where the local AS number itself is rolled over.


regards,

    Geoff




At 04:23 AM 13/12/2005, Andrew Dul wrote:
>This is proposed as a temporary policy, which to me means that if the 
>policy is approved at some point it will automatically be removed from the 
>NPRM on 1/1/2010.  Which means we will then only have the current AS 
>number policy.  Does everyone feel that the current text will then be 
>sufficient in a 4 byte world?  Or do we need additional text to deal with 
>the new issues in a 4-byte world?
>
>Andrew
>
>
>***************************
>NRPM
>***************************
>
>5. AS Numbers
>
>There are a limited number of available Autonomous System Numbers (AS 
>Numbers), therefore, it is important to determine which sites require 
>unique AS Numbers and which do not. Sites that do not require a unique AS 
>Number should use one or more of the AS Numbers reserved for private use. 
>Those numbers are: 64512 through 65535.
>
>In order to be assigned an AS Number, each requesting organization must 
>provide ARIN with verification that it has one of the following:
>
>    1. A unique routing policy (its policy differs from its border gateway 
> peers)
>    2. A multihomed site.
>
>AS Numbers are issued based on current need. An organization should 
>request an AS Number only when it is already multihomed or will 
>immediately become multihomed. Details regarding requirements, fees, and 
>applying for an AS Number can be found on the Guidelines for AS Numbers page.
>
>*******************
>
>
> >
> >  Policy Proposal Name:
> >
> >           4-Byte AS Number Policy Proposal
> >
> >  Author: Geoff Huston
> >
> >
> >  Policy Term:
> >
> >           Temporary (1 January 2007 - 1 January 2010)
> >
> >  Policy Statement:
> >
> >           This policy proposal nominates 3 dates for changes to the
> >           current AS Number allocation policy for the registry:
> >
> >           On 1 January 2007 the registry will process applications that
> >           specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.
> >
> >           On 1 January 2009 the registry will process applications that
> >           specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.
> >
> >           On 1 January 2010 the registry will cease to make any
> >           distinction between 2-byte only AS Numbers and 4-byte only AS
> >           Numbers, and will operate AS number allocations from an
> >           undifferentiated 4-byte AS Number allocation pool.
> >
> >           Nomenclature
> >
> >           It is proposed to identify 4-byte AS Numbers using a syntax of
> >           <high order 16 bit value in decimal>:<low order 16 bit value
> >           in decimal>. Accordingly, a 4-byte AS number of value 65546
> >           (decimal) would be identified as "1:10".
> >
> >           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)
> >
>_______________________________________________
>PPML mailing list
>PPML at arin.net
>http://lists.arin.net/mailman/listinfo/ppml




From Ed.Lewis at neustar.biz  Mon Dec 12 16:35:05 2005
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Mon, 12 Dec 2005 16:35:05 -0500
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <439D7EC1.2040109@arin.net>
References: <439D7EC1.2040109@arin.net>
Message-ID: <a06200700bfc39ab5f7e5@[10.31.32.117]>

At 8:44 -0500 12/12/05, Member Services wrote:

>Policy Proposal Name:
>
>          4-Byte AS Number Policy Proposal
>
>Author: Geoff Huston

>          Terminology
>
>          "2-byte only AS Numbers" refers to AS numbers in the range 0 -
>          65535

Should that be "0:0 - 0:65536"?

>Rationale:

>          [3]  BGP Support for Four-octet AS Number Space,
>               draft-ietf-idr-as4bytes-12.txt

The syntax "a:b" does not appear in that document.  Is it defined 
elsewhere?  The use of the ":" as separator bothers me as that is 
used in IPv6 address notation.

I don't mean to question the sanity of the choice in this forum, I am 
wondering if the decision is documented elsewhere.  (Obviously, I do 
question the sanity of it, but I don't mean to make that a thread 
here, nor am I strongly opposed to the choice.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.


From rich at nic.umass.edu  Mon Dec 12 17:36:20 2005
From: rich at nic.umass.edu (Rich Emmings)
Date: Mon, 12 Dec 2005 17:36:20 -0500 (EST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <439D7EC1.2040109@arin.net>
References: <439D7EC1.2040109@arin.net>
Message-ID: <Pine.GSO.4.63.0512121723100.444@troy>

A possible addition is for space to be left aside in the proposal for private 4 byte AS numbers, perhaps:

  1) in the same range as the 2 byte range, i.e. 64512 - 65534:x or
  2) in each range (x:64512 - 65534)

Notes: a) not sure the status of AS23456 with regard to this, if any.
        b) administrative ease is addressed here by using the same range, at the possible expense of "c"
        c) efficiency of allocation is not -- could be with a small range at the top, at the expense of "b"

In addition, documention-only ASN's may be of use, ala the IPv4 addresses in 
RFC3330.  While the private range can be used, in BGP documentation, as with 
others, it's harder to determine 'public' from 'private' when only private 
space is used.

On Mon, 12 Dec 2005, Member Services wrote:
>
> [deleted]
> ### * ###
>
> Policy Proposal Name:
>
>         4-Byte AS Number Policy Proposal
>
> Author: Geoff Huston


From gih at apnic.net  Mon Dec 12 17:40:50 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 13 Dec 2005 09:40:50 +1100
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
 Proposal
In-Reply-To: <a06200700bfc39ab5f7e5@[10.31.32.117]>
References: <439D7EC1.2040109@arin.net> <a06200700bfc39ab5f7e5@[10.31.32.117]>
Message-ID: <6.2.0.14.2.20051213093714.02dffb70@kahuna.telstra.net>

At 08:35 AM 13/12/2005, Edward Lewis wrote:
>At 8:44 -0500 12/12/05, Member Services wrote:
>
> >Policy Proposal Name:
> >
> >          4-Byte AS Number Policy Proposal
> >
> >Author: Geoff Huston
>
> >          Terminology
> >
> >          "2-byte only AS Numbers" refers to AS numbers in the range 0 -
> >          65535
>
>Should that be "0:0 - 0:65536"?


65536 is 10000000000000000 (i.e. it takes 17 bits) while 65535 is 
1111111111111111 (16 all 1's). The highest number in the 2byte space is 65535.



> >Rationale:
>
> >          [3]  BGP Support for Four-octet AS Number Space,
> >               draft-ietf-idr-as4bytes-12.txt
>
>The syntax "a:b" does not appear in that document.  Is it defined
>elsewhere?  The use of the ":" as separator bothers me as that is
>used in IPv6 address notation.


The reason why the notation note appears in the proposal was because it is 
not used in the ietf document, and frankly the concept of using decimal 
numbers up to 4 billion did not excite me. This proposed notation is a 
convenience - nothing more.


>I don't mean to question the sanity of the choice in this forum, I am
>wondering if the decision is documented elsewhere.  (Obviously, I do
>question the sanity of it, but I don't mean to make that a thread
>here, nor am I strongly opposed to the choice.)

It is not documented elsewhere, no.

regards,

   Geoff




From gih at apnic.net  Mon Dec 12 17:57:13 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 13 Dec 2005 09:57:13 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.GSO.4.63.0512121723100.444@troy>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
Message-ID: <6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>

At 09:36 AM 13/12/2005, Rich Emmings wrote:
>A possible addition is for space to be left aside in the proposal for 
>private 4 byte AS numbers, perhaps:
>
>   1) in the same range as the 2 byte range, i.e. 64512 - 65534:x or
>   2) in each range (x:64512 - 65534)


While I have heard of folk indicating that the private IPv4 address space 
is too small, I have not heard of anyone saying that the 1023 AS numbers 
reserved for private use is too small. If there is a broad perception that 
the space is too small then we'd either need to go down the path of a 
global policy to reserve additional space or possibly head down the IETF 
Standards track document path. Both represent significantly greater 
thresholds than this relatively simple policy proposal. I'd suggest that 
expansion of the private AS number space be considered as a separate topic 
and the merits or otherwise of such a proposal be considered without tying 
it up with this transition policy.



>Notes: a) not sure the status of AS23456 with regard to this, if any.


as23456 is reserved for use as a transition AS in 
draft-ietf-idr-as4bytes-12.txt - no further RIR action is required 
regarding this particular AS number.


>         b) administrative ease is addressed here by using the same range, 
> at the possible expense of "c"
>         c) efficiency of allocation is not -- could be with a small range 
> at the top, at the expense of "b"


it is unclear to me what your point is here.



>In addition, documention-only ASN's may be of use, ala the IPv4 addresses in
>RFC3330.  While the private range can be used, in BGP documentation, as with
>others, it's harder to determine 'public' from 'private' when only private
>space is used.

Again, this may well benefit from being a distinct policy proposal.

regards,

    Geoff






From owen at delong.com  Tue Dec 13 01:07:48 2005
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Dec 2005 22:07:48 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <439D7EC1.2040109@arin.net>
References: <439D7EC1.2040109@arin.net>
Message-ID: <8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>

In general, I like the policy, however, I think the nomenclature is a bad
idea as specified below:

>          Nomenclature
>
>          It is proposed to identify 4-byte AS Numbers using a syntax of
>          <high order 16 bit value in decimal>:<low order 16 bit value
>          in decimal>. Accordingly, a 4-byte AS number of value 65546
>          (decimal) would be identified as "1:10".
>
That fits really well with the current ASN:Comm syntax used for
communities... NOT!  This will create no end of confusion by
using this nomenclature.  Is 45:1234 AS45 community 1234 or
is it AS45:1234?  What about communities within 16 bit ASNs?
Will it then become AS45:1234:5678?

Perhaps using dot as a separator as in 45.1234 instead would be a better
idea.  Perhaps hyphen, perhaps something else.  I really don't care, but,
I'd hate to see : used as it will do nothing but create confusion.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051212/b3e89d82/attachment.sig>

From owen at delong.com  Tue Dec 13 01:14:14 2005
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Dec 2005 22:14:14 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051212172301.23801.qmail@hoster908.com>
References: <20051212172301.23801.qmail@hoster908.com>
Message-ID: <72A9D14FE6173B424CD24C61@odpwrbook.hq.netli.lan>

I think that the issues in a 4-byte world are not yet well enough known to
shape policy.  I think that the term specified in the temporary policy 
allows
enough time for us to gain operational experience and build new permanent
policy around the issues actually encountered instead of making them up
in advance.

I think the temporary policy is a good step in the correct direction and 
that
permanent policy should be based on experience.  Even in the ARIN world, we
usually manage to get policy done in less than 4 years when it is needed.

Owen


--On December 12, 2005 5:23:01 PM +0000 Andrew Dul <andrew.dul at quark.net> 
wrote:

> This is proposed as a temporary policy, which to me means that if the
> policy is approved at some point it will automatically be removed from
> the NPRM on 1/1/2010.  Which means we will then only have the current AS
> number policy.  Does everyone feel that the current text will then be
> sufficient in a 4 byte world?  Or do we need additional text to deal with
> the new issues in a 4-byte world?
>
> Andrew
>
>
> ***************************
> NRPM
> ***************************
>
> 5. AS Numbers
>
> There are a limited number of available Autonomous System Numbers (AS
> Numbers), therefore, it is important to determine which sites require
> unique AS Numbers and which do not. Sites that do not require a unique AS
> Number should use one or more of the AS Numbers reserved for private use.
> Those numbers are: 64512 through 65535.
>
> In order to be assigned an AS Number, each requesting organization must
> provide ARIN with verification that it has one of the following:
>
>    1. A unique routing policy (its policy differs from its border gateway
> peers)    2. A multihomed site.
>
> AS Numbers are issued based on current need. An organization should
> request an AS Number only when it is already multihomed or will
> immediately become multihomed. Details regarding requirements, fees, and
> applying for an AS Number can be found on the Guidelines for AS Numbers
> page.
>
> *******************
>
>
>>
>>  Policy Proposal Name:
>>
>>           4-Byte AS Number Policy Proposal
>>
>>  Author: Geoff Huston
>>
>>
>>  Policy Term:
>>
>>           Temporary (1 January 2007 - 1 January 2010)
>>
>>  Policy Statement:
>>
>>           This policy proposal nominates 3 dates for changes to the
>>           current AS Number allocation policy for the registry:
>>
>>           On 1 January 2007 the registry will process applications that
>>           specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.
>>
>>           On 1 January 2009 the registry will process applications that
>>           specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.
>>
>>           On 1 January 2010 the registry will cease to make any
>>           distinction between 2-byte only AS Numbers and 4-byte only AS
>>           Numbers, and will operate AS number allocations from an
>>           undifferentiated 4-byte AS Number allocation pool.
>>
>>           Nomenclature
>>
>>           It is proposed to identify 4-byte AS Numbers using a syntax of
>>           <high order 16 bit value in decimal>:<low order 16 bit value
>>           in decimal>. Accordingly, a 4-byte AS number of value 65546
>>           (decimal) would be identified as "1:10".
>>
>>           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)
>>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051212/1ecdeda7/attachment.sig>

From gih at apnic.net  Tue Dec 13 01:14:05 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 13 Dec 2005 17:14:05 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
Message-ID: <6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>

Your point about syntactical confusion with AS number communities is well 
taken.

What about a dot as the nibble separator within the AS number then?

Geoff



At 05:07 PM 13/12/2005, Owen DeLong wrote:
>In general, I like the policy, however, I think the nomenclature is a bad
>idea as specified below:
>
>>          Nomenclature
>>
>>          It is proposed to identify 4-byte AS Numbers using a syntax of
>>          <high order 16 bit value in decimal>:<low order 16 bit value
>>          in decimal>. Accordingly, a 4-byte AS number of value 65546
>>          (decimal) would be identified as "1:10".
>That fits really well with the current ASN:Comm syntax used for
>communities... NOT!  This will create no end of confusion by
>using this nomenclature.  Is 45:1234 AS45 community 1234 or
>is it AS45:1234?  What about communities within 16 bit ASNs?
>Will it then become AS45:1234:5678?
>
>Perhaps using dot as a separator as in 45.1234 instead would be a better
>idea.  Perhaps hyphen, perhaps something else.  I really don't care, but,
>I'd hate to see : used as it will do nothing but create confusion.
>
>Owen
>
>--
>If this message was not signed with gpg key 0FE2AA3D, it's probably
>a forgery.
>
>
>
>_______________________________________________
>PPML mailing list
>PPML at arin.net
>http://lists.arin.net/mailman/listinfo/ppml




From owen at delong.com  Tue Dec 13 02:08:02 2005
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Dec 2005 23:08:02 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.GSO.4.63.0512121723100.444@troy>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
Message-ID: <ACF260D0AA7CB9FD9728F822@odpwrbook.hq.netli.lan>

Why do we need additional private asns instead of just 0:64512-0:65534?

Owen


--On December 12, 2005 5:36:20 PM -0500 Rich Emmings <rich at nic.umass.edu> 
wrote:

> A possible addition is for space to be left aside in the proposal for
> private 4 byte AS numbers, perhaps:
>
>   1) in the same range as the 2 byte range, i.e. 64512 - 65534:x or
>   2) in each range (x:64512 - 65534)
>
> Notes: a) not sure the status of AS23456 with regard to this, if any.
>         b) administrative ease is addressed here by using the same range,
> at the possible expense of "c"         c) efficiency of allocation is not
> -- could be with a small range at the top, at the expense of "b"
>
> In addition, documention-only ASN's may be of use, ala the IPv4 addresses
> in  RFC3330.  While the private range can be used, in BGP documentation,
> as with  others, it's harder to determine 'public' from 'private' when
> only private  space is used.
>
> On Mon, 12 Dec 2005, Member Services wrote:
>>
>> [deleted]
>> ### * ###
>>
>> Policy Proposal Name:
>>
>>         4-Byte AS Number Policy Proposal
>>
>> Author: Geoff Huston
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051212/cf1aee07/attachment.sig>

From owen at delong.com  Tue Dec 13 02:14:40 2005
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Dec 2005 23:14:40 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
Message-ID: <E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>

I think it's fine, although, I'm not sure we need nibble separation rather
than just two 16 bit fields as originally proposed.

I think AS 45.1234 (equivalent to 2,950,354 or 45*65536+1234) is fine.

I suspect that is what you meant, but, a nibble is 4 bits or one hex digit.

Owen


--On December 13, 2005 5:14:05 PM +1100 Geoff Huston <gih at apnic.net> wrote:

> Your point about syntactical confusion with AS number communities is well
> taken.
>
> What about a dot as the nibble separator within the AS number then?
>
> Geoff
>
>
>
> At 05:07 PM 13/12/2005, Owen DeLong wrote:
>> In general, I like the policy, however, I think the nomenclature is a bad
>> idea as specified below:
>>
>>>          Nomenclature
>>>
>>>          It is proposed to identify 4-byte AS Numbers using a syntax of
>>>          <high order 16 bit value in decimal>:<low order 16 bit value
>>>          in decimal>. Accordingly, a 4-byte AS number of value 65546
>>>          (decimal) would be identified as "1:10".
>> That fits really well with the current ASN:Comm syntax used for
>> communities... NOT!  This will create no end of confusion by
>> using this nomenclature.  Is 45:1234 AS45 community 1234 or
>> is it AS45:1234?  What about communities within 16 bit ASNs?
>> Will it then become AS45:1234:5678?
>>
>> Perhaps using dot as a separator as in 45.1234 instead would be a better
>> idea.  Perhaps hyphen, perhaps something else.  I really don't care, but,
>> I'd hate to see : used as it will do nothing but create confusion.
>>
>> Owen
>>
>> --
>> If this message was not signed with gpg key 0FE2AA3D, it's probably
>> a forgery.
>>
>>
>>
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051212/e4bb51a2/attachment.sig>

From gih at apnic.net  Tue Dec 13 04:14:58 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 13 Dec 2005 20:14:58 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
Message-ID: <6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>

my mistake - I did mean 16 bit separation - I just didn't type it!


ok - unless I hear to the contrary I'll run with the notation <high>.<low>

e.g. 10.1


  Geoff

At 06:14 PM 13/12/2005, Owen DeLong wrote:
>I think it's fine, although, I'm not sure we need nibble separation rather
>than just two 16 bit fields as originally proposed.
>
>I think AS 45.1234 (equivalent to 2,950,354 or 45*65536+1234) is fine.
>
>I suspect that is what you meant, but, a nibble is 4 bits or one hex digit.
>
>Owen
>
>
>--On December 13, 2005 5:14:05 PM +1100 Geoff Huston <gih at apnic.net> wrote:
>
>>Your point about syntactical confusion with AS number communities is well
>>taken.
>>
>>What about a dot as the nibble separator within the AS number then?
>>
>>Geoff
>>
>>
>>
>>At 05:07 PM 13/12/2005, Owen DeLong wrote:
>>>In general, I like the policy, however, I think the nomenclature is a bad
>>>idea as specified below:
>>>
>>>>          Nomenclature
>>>>
>>>>          It is proposed to identify 4-byte AS Numbers using a syntax of
>>>>          <high order 16 bit value in decimal>:<low order 16 bit value
>>>>          in decimal>. Accordingly, a 4-byte AS number of value 65546
>>>>          (decimal) would be identified as "1:10".
>>>That fits really well with the current ASN:Comm syntax used for
>>>communities... NOT!  This will create no end of confusion by
>>>using this nomenclature.  Is 45:1234 AS45 community 1234 or
>>>is it AS45:1234?  What about communities within 16 bit ASNs?
>>>Will it then become AS45:1234:5678?
>>>
>>>Perhaps using dot as a separator as in 45.1234 instead would be a better
>>>idea.  Perhaps hyphen, perhaps something else.  I really don't care, but,
>>>I'd hate to see : used as it will do nothing but create confusion.
>>>
>>>Owen
>>>
>>>--
>>>If this message was not signed with gpg key 0FE2AA3D, it's probably
>>>a forgery.
>>>
>>>
>>>
>>>_______________________________________________
>>>PPML mailing list
>>>PPML at arin.net
>>>http://lists.arin.net/mailman/listinfo/ppml
>
>
>
>
>




From Michael.Dillon at btradianz.com  Tue Dec 13 05:33:51 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Tue, 13 Dec 2005 10:33:51 +0000
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
Message-ID: <OFEF3358AC.92B39C7F-ON802570D6.0039B88C-802570D6.003A03A9@btradianz.com>

> Your point about syntactical confusion with AS number communities is 
well 
> taken.
> 
> What about a dot as the nibble separator within the AS number then?

Is there something wrong with using 78934526:1234 to refer to
community 1234 in AS number 78934526?

Is it worthwhile specifying that AS numbers should be allocated
sequentially rather than randomly from the 4 byte numberspace?

--Michael Dillon

P.S. Would anyone have objections to rewriting that policy
in plain English?



From owen at delong.com  Tue Dec 13 05:41:36 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Dec 2005 02:41:36 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <OFEF3358AC.92B39C7F-ON802570D6.0039B88C-802570D6.003A03A9@btradianz.com>
References: <OFEF3358AC.92B39C7F-ON802570D6.0039B88C-802570D6.003A03A9@btrad
	ianz.com>
Message-ID: <E9C8A3CDCE0B006305AD7269@odpwrbook.hq.netli.lan>

1.	I thought the policy was in plain English.  Admittedly, the British
	version of plain English often differs from what I grew up with,
	but, I think it was passable for North American Plain English.

2.	There is some convenience and human readability/error prevention
	to be gained from 1204.29182:1234 vs. your proposed 78934526:1234.
	I think that 1204:29182:1234 would be bad, and, the policy author
	has agreed and stated that he will change his recommendation to
	dot (period for those of you on the other side of the pond) instead
	of colon.

3.	I am not sure that sequential ASN allocation is worth while.  I do
	think it makes sense for ICANN to allocate blocks of ASNs to RIRs
	as is currently done, and, that prevents perfect sequentiality, so,
	I'm not sure that within a block sequential allocation from RIRs
	actually matters.  I suspect that ICANN will issue a single
	16 bit ASN prefix to each RIR to start, but, perhaps there will be
	some reason ICANN wants to issue smaller or larger chunks of ASNs.

Owen


--On December 13, 2005 10:33:51 AM +0000 Michael.Dillon at btradianz.com wrote:

>> Your point about syntactical confusion with AS number communities is
> well
>> taken.
>>
>> What about a dot as the nibble separator within the AS number then?
>
> Is there something wrong with using 78934526:1234 to refer to
> community 1234 in AS number 78934526?
>
> Is it worthwhile specifying that AS numbers should be allocated
> sequentially rather than randomly from the 4 byte numberspace?
>
> --Michael Dillon
>
> P.S. Would anyone have objections to rewriting that policy
> in plain English?
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051213/28b4e4b4/attachment.sig>

From dr at cluenet.de  Tue Dec 13 05:45:50 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Tue, 13 Dec 2005 11:45:50 +0100
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
	Proposal
In-Reply-To: <a06200700bfc39ab5f7e5@[10.31.32.117]>
References: <439D7EC1.2040109@arin.net> <a06200700bfc39ab5f7e5@[10.31.32.117]>
Message-ID: <20051213104550.GA4432@srv01.cluenet.de>

On Mon, Dec 12, 2005 at 04:35:05PM -0500, Edward Lewis wrote:
> The syntax "a:b" does not appear in that document.  Is it defined 
> elsewhere?  The use of the ":" as separator bothers me as that is 
> used in IPv6 address notation.

And in community syntax, for both standard communities and extended
communities (which become very very ugly with this notation).

But you are right, probably not the place to discuss that, although
this document text would set a precedence.

A question to Geoff: why will issueing of 4-byte ASNs start only at
2007-01-01, not earlier? To give RIRs two(!) years time to prepare
themselves from 32bit ASN?


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From dr at cluenet.de  Tue Dec 13 05:50:09 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Tue, 13 Dec 2005 11:50:09 +0100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
Message-ID: <20051213105009.GB4432@srv01.cluenet.de>

On Tue, Dec 13, 2005 at 08:14:58PM +1100, Geoff Huston wrote:
> ok - unless I hear to the contrary I'll run with the notation <high>.<low>

Excellent. Much better. And simplifies parsers (human and electronic
ones) big time.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From jeroen at unfix.org  Tue Dec 13 05:57:40 2005
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 13 Dec 2005 11:57:40 +0100
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number
	Policy	Proposal
In-Reply-To: <20051213104550.GA4432@srv01.cluenet.de>
References: <439D7EC1.2040109@arin.net> <a06200700bfc39ab5f7e5@[10.31.32.117]>
	<20051213104550.GA4432@srv01.cluenet.de>
Message-ID: <439EA924.10909@unfix.org>

Daniel Roesen wrote:
> On Mon, Dec 12, 2005 at 04:35:05PM -0500, Edward Lewis wrote:
>> The syntax "a:b" does not appear in that document.  Is it defined 
>> elsewhere?  The use of the ":" as separator bothers me as that is 
>> used in IPv6 address notation.
> 
> And in community syntax, for both standard communities and extended
> communities (which become very very ugly with this notation).
> 
> But you are right, probably not the place to discuss that, although
> this document text would set a precedence.
> 
> A question to Geoff: why will issueing of 4-byte ASNs start only at
> 2007-01-01, not earlier? To give RIRs two(!) years time to prepare
> themselves from 32bit ASN?

One year :) It will be 2006-01-01 in about 17 days, depending on
timezone. This policy needs to be discussed, approved and also
implemented, software wise but also these blocks need to be requested
from IANA, which also means some time for policy, software, procedures
to be developed there. One year is going to be tight as it is already.
Ignoring that vendors also need to implement it, though I understood
that a couple of vendors where already busy with it, that even before
the draft is reasonably final, which is a rather good thing.

On Tue, Dec 13, 2005 at 08:14:58PM +1100, Geoff Huston wrote:
> ok - unless I hear to the contrary I'll run with the notation <high>.<low>

Ack too. The <high>.<low> format is good.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051213/b672ab0c/attachment.sig>

From william at elan.net  Tue Dec 13 06:24:23 2005
From: william at elan.net (william(at)elan.net)
Date: Tue, 13 Dec 2005 03:24:23 -0800 (PST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <E9C8A3CDCE0B006305AD7269@odpwrbook.hq.netli.lan>
References: <OFEF3358AC.92B39C7F-ON802570D6.0039B88C-802570D6.003A03A9@btrad
	ianz.com> <E9C8A3CDCE0B006305AD7269@odpwrbook.hq.netli.lan>
Message-ID: <Pine.LNX.4.62.0512130317100.6721@sokol.elan.net>


On Tue, 13 Dec 2005, Owen DeLong wrote:

> 3.	I am not sure that sequential ASN allocation is worth while.  I do
> 	think it makes sense for ICANN to allocate blocks of ASNs to RIRs
>
> 	as is currently done, and, that prevents perfect sequentiality, so,
> 	I'm not sure that within a block sequential allocation from RIRs
> 	actually matters.  I suspect that ICANN will issue a single
> 	16 bit ASN prefix to each RIR to start, but, perhaps there will be
> 	some reason ICANN wants to issue smaller or larger chunks of ASNs.

Yes, I think it would be good idea to consider upper 16 bits in 4-byte ASN 
to  be like upper 8 bits in ip4 and have IANA manage set of those and 
allocate  from there to specific RIR, i.e. 1.xxxxx (1.0-1.65535) could
be reallocated to ARIN, 2.xxxxx to RIPE, 3.xxxxx to APNIC, etc
  with 0:xxxxx becoming a version of 192.x.x.x swamp for ASNs....

-- 
William Leibzon
Elan Networks
william at elan.net


From rich at nic.umass.edu  Tue Dec 13 09:46:19 2005
From: rich at nic.umass.edu (Rich Emmings)
Date: Tue, 13 Dec 2005 09:46:19 -0500 (EST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
Message-ID: <Pine.GSO.4.63.0512130933070.10437@troy>

On Tue, 13 Dec 2005, Geoff Huston wrote:

[regarding separation of policy proposals on documentation/private space]

No real objection to that.

> While I have heard of folk indicating that the private IPv4 address space is 
> too small, I have not heard of anyone saying that the 1023 AS numbers 
> reserved for private use is too small. [ balance deleted]
>

More thinking that 1023 could perceived as some as being too large a 
reservation of the top two bytes.

>
>>         b) administrative ease is addressed here by using the same range, 
>> at the possible expense of "c"
>>         c) efficiency of allocation is not -- could be with a small range 
>> at the top, at the expense of "b"
>
>
> it is unclear to me what your point is here.
>

Reservation of the top 1023 2 bytes in 4 byte space is a larger chunk of 
space, than is probably needed, but using the same numbers as in 2 byte 
space is easier to remember -- administrative ease.  The other side is to 
only strip off a few addresses at the top, say: 65520.x - 65534.x, instead 
of 1023 (in the first 2 bytes of the 4.)

---

AS2 -> AS4 transition will mirror what will happen in IPv6 implementation. 
Won't happen until/if forced, workarounds allowing the continued use of AS2 
space will probably be developed ala some of the tools which extended the 
IPv4 lifetime (both good and ugly), they'll be some things that won't leave 
IPv4 space for 10+ years, if ever, and they'll be grumbling all over.  In 
other words, same as always.  (but no reason not to get started now)


From Lee.Howard at stanleyassociates.com  Tue Dec 13 09:59:47 2005
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Tue, 13 Dec 2005 09:59:47 -0500
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number
	PolicyProposal
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4C7EC9B@CL-S-EX-1.stanleyassociates.com>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Daniel Roesen
> Sent: Tuesday, December 13, 2005 5:46 AM
> To: ppml at arin.net
> Subject: Re: [ppml] ":" - Re: Proposed Policy: 4-Byte AS 
> Number PolicyProposal
> 

> A question to Geoff: why will issueing of 4-byte ASNs start only at
> 2007-01-01, not earlier? To give RIRs two(!) years time to prepare
> themselves from 32bit ASN?

One year and nineteen days from today.  By the time it has passed
the policy process, about six months.  

Lee

> 
> 
> Regards,
> Daniel
> 
> -- 
> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From gih at apnic.net  Tue Dec 13 13:45:50 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 05:45:50 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <OFEF3358AC.92B39C7F-ON802570D6.0039B88C-802570D6.003A03A9@
	btradianz.com>
References: <6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<OFEF3358AC.92B39C7F-ON802570D6.0039B88C-802570D6.003A03A9@btradianz.com>
Message-ID: <6.2.0.14.2.20051214053659.02d887a8@kahuna.telstra.net>

At 09:33 PM 13/12/2005, Michael.Dillon at btradianz.com wrote:
> > Your point about syntactical confusion with AS number communities is
>well
> > taken.
> >
> > What about a dot as the nibble separator within the AS number then?
>
>Is there something wrong with using 78934526:1234 to refer to
>community 1234 in AS number 78934526?

This notation is not formally part of the policy proposal - it is a
convenience in the same way that the dotted quad notation for
IPv4 addresses is a convenience. Use it or not as you want.


>Is it worthwhile specifying that AS numbers should be allocated
>sequentially rather than randomly from the 4 byte numberspace?


I see no reason to head off there The policy does not proposes such changes
to the manner of AS number allocation.  This is a _temporary_ policy
intended to provide some milestones in the transition to  a larger AS Number
space that will allow vendors, operators and others to prepare their part 
of the
plot well before we exhaust the 2 byte number pool.

>--Michael Dillon
>
>P.S. Would anyone have objections to rewriting that policy
>in plain English?


If "that policy" refers to "4-Byte AS Number Policy Proposal" then
yes, I do have objections.




From gih at apnic.net  Tue Dec 13 14:01:21 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 06:01:21 +1100
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
 Proposal
In-Reply-To: <20051213104550.GA4432@srv01.cluenet.de>
References: <439D7EC1.2040109@arin.net> <a06200700bfc39ab5f7e5@[10.31.32.117]>
	<20051213104550.GA4432@srv01.cluenet.de>
Message-ID: <6.2.0.14.2.20051214054738.02d56150@kahuna.telstra.net>

At 09:45 PM 13/12/2005, Daniel Roesen wrote:
>On Mon, Dec 12, 2005 at 04:35:05PM -0500, Edward Lewis wrote:
> > The syntax "a:b" does not appear in that document.  Is it defined
> > elsewhere?  The use of the ":" as separator bothers me as that is
> > used in IPv6 address notation.
>
>And in community syntax, for both standard communities and extended
>communities (which become very very ugly with this notation).
>
>But you are right, probably not the place to discuss that, although
>this document text would set a precedence.

I will revise the proposal with a '.' rather than a ':' delimiter.

>A question to Geoff: why will issueing of 4-byte ASNs start only at
>2007-01-01, not earlier? To give RIRs two(!) years time to prepare
>themselves from 32bit ASN?

1 January 2007 is some 12 1/2 months away. Given that, it will take some 
months of elapsed time for:

- the policy proposal to make it through the RIR and get adopted as RIR policy

- the 4-byte draft to get far enough through the IETF's Proposed Standard 
process to initiate the IANA action on the registry (already, more than 1 
month after the publication request was made by the IDR Working Grop chairs 
in the IETF  (12th November) , the document status in the document tracker 
says "I-D Exists" rather than "publication requested" - this is not exactly 
being fast tracked)

- the IANA action to actually create the expanded registry (a small task in 
and of itself, but it often takes some time to get to the top of the IANA 
work list)

- the IANA action to allocate 5 blocks to the RIRs from the 4-byte only AS 
Number pool

- The RIR to check that there are no 16 bit restrictions ion the code base 
they are using in their registry code.

- The RIR to prepare documentation and implement procedures in the AS 
allocation framework that will permit an applicant to request a 4-byte AS 
number

Doubtless each of these tasks is minor in nature, but it's prudent to allow 
a 12 month period in order to ensure that all this can be done without 
having to rush it through..

thanks,

   Geoff





From gih at apnic.net  Tue Dec 13 14:28:11 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 06:28:11 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.GSO.4.63.0512130933070.10437@troy>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
	<Pine.GSO.4.63.0512130933070.10437@troy>
Message-ID: <6.2.0.14.2.20051214061633.02d337c8@kahuna.telstra.net>

At 01:46 AM 14/12/2005, Rich Emmings wrote:
>On Tue, 13 Dec 2005, Geoff Huston wrote:
>
>[regarding separation of policy proposals on documentation/private space]
>
>No real objection to that.
>
> > While I have heard of folk indicating that the private IPv4 address 
> space is
> > too small, I have not heard of anyone saying that the 1023 AS numbers
> > reserved for private use is too small. [ balance deleted]
> >
>
>More thinking that 1023 could perceived as some as being too large a
>reservation of the top two bytes.
>
> >
> >>         b) administrative ease is addressed here by using the same range,
> >> at the possible expense of "c"
> >>         c) efficiency of allocation is not -- could be with a small range
> >> at the top, at the expense of "b"
> >
> >
> > it is unclear to me what your point is here.
> >
>
>Reservation of the top 1023 2 bytes in 4 byte space is a larger chunk of
>space, than is probably needed, but using the same numbers as in 2 byte
>space is easier to remember -- administrative ease.  The other side is to
>only strip off a few addresses at the top, say: 65520.x - 65534.x, instead
>of 1023 (in the first 2 bytes of the 4.)


This policy proposal says absolutely nothing about expansion of the private 
AS number space. Currently the AS numbers 0 (or 0.0 in a 4 byte notation), 
23456 (0.23456) and 65535 (0.65535) are reserved by IANA, and the range 
64512 - 65534 (0.64512 - 0.65534) are designated for private use 
(http://www.iana.org/assignments/as-numbers) Neither the IETF 4 Byte draft 
nor this proposal say anything about extending this set of reserved or 
designated numbers in any way. i.e. in a 4byte AS world private AS numbers 
will still be the range of AS numbers from 0.64512 to 0.65534.



>AS2 -> AS4 transition will mirror what will happen in IPv6 implementation.
>Won't happen until/if forced, workarounds allowing the continued use of AS2
>space will probably be developed ala some of the tools which extended the
>IPv4 lifetime (both good and ugly), they'll be some things that won't leave
>IPv4 space for 10+ years, if ever, and they'll be grumbling all over.  In
>other words, same as always.  (but no reason not to get started now)


I have to disagree with this assertion. As noted in the 4byte AS draft, and 
as noted in http://www.potaroo.net/ispcol/2005-08/as.html, the transition 
is entirely different to that associated with IPv6. In this case existing 
players in the inter-domain routing space have no requirement to do 
anything now, or in the future. Let me say it again: Folk who have 2 byte 
AS numbers need do _nothing_ , i.e. the transition allows for "the 
continued use of AS2  space" indefinitely. Please read these references, as 
they are intended to describe the transition situation in as comprehensive 
manner as possible.


thanks,

   Geoff




From sleibrand at internap.com  Tue Dec 13 14:30:28 2005
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 13 Dec 2005 14:30:28 -0500 (EST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051213105009.GB4432@srv01.cluenet.de>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<20051213105009.GB4432@srv01.cluenet.de>
Message-ID: <Pine.LNX.4.58.0512131427100.13145@sleibrand.acs.internap.com>

On 12/13/05 at 11:50am +0100, Daniel Roesen <dr at cluenet.de> wrote:

> On Tue, Dec 13, 2005 at 08:14:58PM +1100, Geoff Huston wrote:
> > ok - unless I hear to the contrary I'll run with the notation <high>.<low>
>
> Excellent. Much better. And simplifies parsers (human and electronic
> ones) big time.

I would agree that with the s/:/./ change, this is a very sensible and
necessary policy proposal that I would support.  Geoff, thanks for your
continued work in developing and refining this proposal to this point.

-Scott


From william at elan.net  Tue Dec 13 14:38:10 2005
From: william at elan.net (william(at)elan.net)
Date: Tue, 13 Dec 2005 11:38:10 -0800 (PST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051214061633.02d337c8@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
	<Pine.GSO.4.63.0512130933070.10437@troy>
	<6.2.0.14.2.20051214061633.02d337c8@kahuna.telstra.net>
Message-ID: <Pine.LNX.4.62.0512131130540.6721@sokol.elan.net>


On Wed, 14 Dec 2005, Geoff Huston wrote:

> I have to disagree with this assertion. As noted in the 4byte AS draft, and
> as noted in http://www.potaroo.net/ispcol/2005-08/as.html, the transition
> is entirely different to that associated with IPv6. In this case existing
> players in the inter-domain routing space have no requirement to do
> anything now, or in the future. Let me say it again: Folk who have 2 byte
> AS numbers need do _nothing_ , i.e. the transition allows for "the
> continued use of AS2  space" indefinitely. Please read these references, as
> they are intended to describe the transition situation in as comprehensive
> manner as possible.

That is not quite as easy as you describe. To be able to use 32bit ASNs,
all routers will need to be upgraded (at least all those who want to 
directly communicate/peer with somebody with 32bit ASN). Note that users
of ASNs are not the same as users of IPv4 space - for ipv4 the end-sites
are kinds of computer devices and everyone on the internet a user of ipv4 
space, where as for ASN end-sites are routers and users are the ISPs.
Since we say that all such devices will need to upgrade software, that
means that all users of ASNs do indeed need to upgrade. The difference
as far as ipv4 vs ipv6 is that there is no need to actually request new
number (as with ipv6) and upgrade is just software or hardware upgrade.

-- 
William Leibzon
Elan Networks
william at elan.net


From david.kessens at nokia.com  Tue Dec 13 14:48:22 2005
From: david.kessens at nokia.com (David Kessens)
Date: Tue, 13 Dec 2005 11:48:22 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
Message-ID: <20051213194822.GA32278@nokia.com>


Geoff,

On Tue, Dec 13, 2005 at 08:14:58PM +1100, Geoff Huston wrote:
> my mistake - I did mean 16 bit separation - I just didn't type it!
> 
> ok - unless I hear to the contrary I'll run with the notation <high>.<low>
> 
> e.g. 10.1

I would prefer hex notation for the numbers. When numbers get larger,
the ASCII version gets longer and longer. Hex could compress it's size
considerably and we might even want to skip the '.' altogether.

David Kessens
---


From Lee.Howard at stanleyassociates.com  Tue Dec 13 14:56:15 2005
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Tue, 13 Dec 2005 14:56:15 -0500
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
	Proposal
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4D48D1B@CL-S-EX-1.stanleyassociates.com>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Geoff Huston
> Sent: Tuesday, December 13, 2005 2:01 PM
> To: Daniel Roesen; ppml at arin.net
> Subject: Re: [ppml] ":" - Re: Proposed Policy: 4-Byte AS 
> Number Policy Proposal
> 
> At 09:45 PM 13/12/2005, Daniel Roesen wrote:
> >On Mon, Dec 12, 2005 at 04:35:05PM -0500, Edward Lewis wrote:
> > > The syntax "a:b" does not appear in that document.  Is it defined
> > > elsewhere?  The use of the ":" as separator bothers me as that is
> > > used in IPv6 address notation.
> >
> >And in community syntax, for both standard communities and extended
> >communities (which become very very ugly with this notation).
> >
> >But you are right, probably not the place to discuss that, although
> >this document text would set a precedence.
> 
> I will revise the proposal with a '.' rather than a ':' delimiter.
> 
> >A question to Geoff: why will issueing of 4-byte ASNs start only at
> >2007-01-01, not earlier? To give RIRs two(!) years time to prepare
> >themselves from 32bit ASN?
> 
> 1 January 2007 is some 12 1/2 months away. Given that, it 
> will take some 
> months of elapsed time for:
> 
> - the policy proposal to make it through the RIR and get 
> adopted as RIR policy

Assume an April [1] meeting with universal support.  The AC recommends 
it for last call, ten working days.  Now it's mid-May, and the AC
meets again and decides that there's been nothing but support in
last call, and forwards to the Board.  The Board agrees, and 
ratifies the policy.  It's probably June by now, six months from
the date of the proposal.

> - the IANA action to actually create the expanded registry (a 
> small task in 
> and of itself, but it often takes some time to get to the top 
> of the IANA work list)
> 
> - the IANA action to allocate 5 blocks to the RIRs from the 
> 4-byte only AS Number pool

Does this need to be a Global Policy?


> - The RIR to check that there are no 16 bit restrictions in 
> the code base they are using in their registry code.

Existing data fields will have to be changed.  Code changes and
template changes are required.  This may be significant; I'm sure
staff will advise at the public policy meeting.


> Doubtless each of these tasks is minor in nature, but it's 
> prudent to allow 
> a 12 month period in order to ensure that all this can be 
> done without having to rush it through.

I agree, and appreciate your work on this.

Lee


>    Geoff

[1] April 9-12, 2006, Montreal, Quebec.  Assume there's a plug for
Member Services here.


From stephen at sprunk.org  Tue Dec 13 15:09:29 2005
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 13 Dec 2005 14:09:29 -0600
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
	Proposal
References: <439D7EC1.2040109@arin.net>
	<a06200700bfc39ab5f7e5@[10.31.32.117]><20051213104550.GA4432@srv01.cluenet.de>
	<6.2.0.14.2.20051214054738.02d56150@kahuna.telstra.net>
Message-ID: <00c701c60021$29ee9460$8701a8c0@dax>

Thus spake "Geoff Huston" <gih at apnic.net>
> At 09:45 PM 13/12/2005, Daniel Roesen wrote:
>>On Mon, Dec 12, 2005 at 04:35:05PM -0500, Edward Lewis wrote:
>> > The syntax "a:b" does not appear in that document.  Is it defined
>> > elsewhere?  The use of the ":" as separator bothers me as that is
>> > used in IPv6 address notation.
>>
>>And in community syntax, for both standard communities and
>>extended communities (which become very very ugly with this
>> notation).
>>
>>But you are right, probably not the place to discuss that, although
>>this document text would set a precedence.
>
> I will revise the proposal with a '.' rather than a ':' delimiter.

Am I the only one concerned that some buggy humans or code may interpret AS 
1.0 as being the same as AS 1?

I agree the colon is problematic, but it seems every punctuation character
is already taken for some purpose or looks downright dumb.  Why do we need a 
separator at all, and are the RIRs really in the business of designating 
what it is?

IMHO, the proposal should be revised to eliminate the separator but leave
enough flexibility for one to be used if the IETF specifies one in the
future -- or alternate display formats such as hex.

I'm also not thrilled with "2-byte only" and "4-byte only" ASN; there's too
much chance of confusion with "2-byte" and "4-byte" ASNs which have a
different enough meaning to warrant a better distinction.  I'd prefer
something like "legacy" vs. "expanded", "low" vs. "high", etc.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2767 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051213/400d0fd1/attachment.bin>

From kloch at hotnic.net  Tue Dec 13 15:37:34 2005
From: kloch at hotnic.net (Kevin Loch)
Date: Tue, 13 Dec 2005 15:37:34 -0500
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number
	Policy	Proposal
In-Reply-To: <00c701c60021$29ee9460$8701a8c0@dax>
References: <439D7EC1.2040109@arin.net>	<a06200700bfc39ab5f7e5@[10.31.32.117]><20051213104550.GA4432@srv01.cluenet.de>	<6.2.0.14.2.20051214054738.02d56150@kahuna.telstra.net>
	<00c701c60021$29ee9460$8701a8c0@dax>
Message-ID: <439F310E.7080009@hotnic.net>

Stephen Sprunk wrote:
> I agree the colon is problematic, but it seems every punctuation character
> is already taken for some purpose or looks downright dumb.  Why do we 
> need a separator at all, and are the RIRs really in the business of 
> designating what it is?

I think RIR's should be concerned with the allocation of resources,
not the semantics of how they are written down.  If a notation
is not in common use elsewhere it should be avoided for clarity.
In this case there is no common notation yet to it would be best
to avoid any notation and focus on the integer values themselves
(see below).

> IMHO, the proposal should be revised to eliminate the separator but leave
> enough flexibility for one to be used if the IETF specifies one in the
> future -- or alternate display formats such as hex.

I like hex but that would mean reconfiguring every bgp router on the
planet unless something clumsy like "0x" was prepended in text form for
hex labels.

> I'm also not thrilled with "2-byte only" and "4-byte only" ASN; there's too
> much chance of confusion with "2-byte" and "4-byte" ASNs which have a
> different enough meaning to warrant a better distinction.  I'd prefer
> something like "legacy" vs. "expanded", "low" vs. "high", etc.

I agree.  The most exact definition would be "ASN's greater than 65535"
and "ASN's less than or equal to 65535" but that could be abbreviated as
"legacy/expanded" or "small/big" with proper definitions.

- Kevin


From gih at apnic.net  Tue Dec 13 15:52:38 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 07:52:38 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.LNX.4.62.0512131130540.6721@sokol.elan.net>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
	<Pine.GSO.4.63.0512130933070.10437@troy>
	<6.2.0.14.2.20051214061633.02d337c8@kahuna.telstra.net>
	<Pine.LNX.4.62.0512131130540.6721@sokol.elan.net>
Message-ID: <6.2.0.14.2.20051214075043.02d8c5b8@kahuna.telstra.net>

At 06:38 AM 14/12/2005, william(at)elan.net wrote:

>On Wed, 14 Dec 2005, Geoff Huston wrote:
>
>>I have to disagree with this assertion. As noted in the 4byte AS draft, and
>>as noted in http://www.potaroo.net/ispcol/2005-08/as.html, the transition
>>is entirely different to that associated with IPv6. In this case existing
>>players in the inter-domain routing space have no requirement to do
>>anything now, or in the future. Let me say it again: Folk who have 2 byte
>>AS numbers need do _nothing_ , i.e. the transition allows for "the
>>continued use of AS2  space" indefinitely. Please read these references, as
>>they are intended to describe the transition situation in as comprehensive
>>manner as possible.
>
>That is not quite as easy as you describe. To be able to use 32bit ASNs,
>all routers will need to be upgraded (at least all those who want to 
>directly communicate/peer with somebody with 32bit ASN).


Again, not so. I'll say it again: Please _read_ these references, as they 
are intended to describe the transition situation in as comprehensive 
manner as possible.


>Note that users
>of ASNs are not the same as users of IPv4 space - for ipv4 the end-sites
>are kinds of computer devices and everyone on the internet a user of ipv4 
>space, where as for ASN end-sites are routers and users are the ISPs.
>Since we say that all such devices will need to upgrade software, that
>means that all users of ASNs do indeed need to upgrade.


sigh - this is just not so. Please _read_ these references, as they are 
intended to describe the transition situation in as comprehensive manner as 
possible.

Geoff




From gih at apnic.net  Tue Dec 13 16:00:02 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 08:00:02 +1100
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
 Proposal
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4D48D1B@CL-S-EX-1.stanleyas
	sociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB4D48D1B@CL-S-EX-1.stanleyassociates.com>
Message-ID: <6.2.0.14.2.20051214075636.02d956b0@kahuna.telstra.net>

You raised a interesting question here "Does this need to be a Global Policy?"

My answer is: No I do not see any grounds for this.

The rationale is that the IANA action to create the 4 byte AS number 
registry is part of the IETF 4Byte AS number draft, so there is no need for 
the RIRs to also direct IANA to do the same thing. Now it is true that in 
order to implement this policy the RIRs will need to request 4-byte AS 
number blocks from IANA, but again I see no need for this to be part of a 
global policy.

So while I have submitted the same policy proposal to all 5 RIR policy 
development processes, there is no need for the adoption of this policy to 
be contingent on the actions of any other RIR - each RIR can proceed 
according to its own policy process here.


thanks,

      Geoff






At 06:56 AM 14/12/2005, Howard, W. Lee wrote:
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
> > Behalf Of Geoff Huston
> > Sent: Tuesday, December 13, 2005 2:01 PM
> > To: Daniel Roesen; ppml at arin.net
> > Subject: Re: [ppml] ":" - Re: Proposed Policy: 4-Byte AS
> > Number Policy Proposal
> >
> > At 09:45 PM 13/12/2005, Daniel Roesen wrote:
> > >On Mon, Dec 12, 2005 at 04:35:05PM -0500, Edward Lewis wrote:
> > > > The syntax "a:b" does not appear in that document.  Is it defined
> > > > elsewhere?  The use of the ":" as separator bothers me as that is
> > > > used in IPv6 address notation.
> > >
> > >And in community syntax, for both standard communities and extended
> > >communities (which become very very ugly with this notation).
> > >
> > >But you are right, probably not the place to discuss that, although
> > >this document text would set a precedence.
> >
> > I will revise the proposal with a '.' rather than a ':' delimiter.
> >
> > >A question to Geoff: why will issueing of 4-byte ASNs start only at
> > >2007-01-01, not earlier? To give RIRs two(!) years time to prepare
> > >themselves from 32bit ASN?
> >
> > 1 January 2007 is some 12 1/2 months away. Given that, it
> > will take some
> > months of elapsed time for:
> >
> > - the policy proposal to make it through the RIR and get
> > adopted as RIR policy
>
>Assume an April [1] meeting with universal support.  The AC recommends
>it for last call, ten working days.  Now it's mid-May, and the AC
>meets again and decides that there's been nothing but support in
>last call, and forwards to the Board.  The Board agrees, and
>ratifies the policy.  It's probably June by now, six months from
>the date of the proposal.
>
> > - the IANA action to actually create the expanded registry (a
> > small task in
> > and of itself, but it often takes some time to get to the top
> > of the IANA work list)
> >
> > - the IANA action to allocate 5 blocks to the RIRs from the
> > 4-byte only AS Number pool
>
>Does this need to be a Global Policy?
>
>
> > - The RIR to check that there are no 16 bit restrictions in
> > the code base they are using in their registry code.
>
>Existing data fields will have to be changed.  Code changes and
>template changes are required.  This may be significant; I'm sure
>staff will advise at the public policy meeting.
>
>
> > Doubtless each of these tasks is minor in nature, but it's
> > prudent to allow
> > a 12 month period in order to ensure that all this can be
> > done without having to rush it through.
>
>I agree, and appreciate your work on this.
>
>Lee
>
>
> >    Geoff
>
>[1] April 9-12, 2006, Montreal, Quebec.  Assume there's a plug for
>Member Services here.




From rich at nic.umass.edu  Tue Dec 13 16:09:57 2005
From: rich at nic.umass.edu (Rich Emmings)
Date: Tue, 13 Dec 2005 16:09:57 -0500 (EST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <ACF260D0AA7CB9FD9728F822@odpwrbook.hq.netli.lan>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<ACF260D0AA7CB9FD9728F822@odpwrbook.hq.netli.lan>
Message-ID: <Pine.GSO.4.63.0512131604510.10437@troy>

On Mon, 12 Dec 2005, Owen DeLong wrote:

>
> Why do we need additional private asns instead of just 0:64512-0:65534?
>

Call it a hunch, but I'm guessing folks will want to play in explicit 4 byte 
space with routes that shouldn't leak, and that may be on a network that's 
live enough.  (Ok, no one's supposed to play with live networks, but enough 
people do.  Some even intend to.)

At this point, it's commentary, and not an objection to moving forward with 
the proposal.


From william at elan.net  Tue Dec 13 16:17:07 2005
From: william at elan.net (william(at)elan.net)
Date: Tue, 13 Dec 2005 13:17:07 -0800 (PST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051214075043.02d8c5b8@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
	<Pine.GSO.4.63.0512130933070.10437@troy>
	<6.2.0.14.2.20051214061633.02d337c8@kahuna.telstra.net>
	<Pine.LNX.4.62.0512131130540.6721@sokol.elan.net>
	<6.2.0.14.2.20051214075043.02d8c5b8@kahuna.telstra.net>
Message-ID: <Pine.LNX.4.62.0512131310020.6721@sokol.elan.net>


On Wed, 14 Dec 2005, Geoff Huston wrote:

> At 06:38 AM 14/12/2005, william(at)elan.net wrote:
>
>> On Wed, 14 Dec 2005, Geoff Huston wrote:
>> 
>>> I have to disagree with this assertion. As noted in the 4byte AS draft, 
>>> and
>>> as noted in http://www.potaroo.net/ispcol/2005-08/as.html, the transition
>>> is entirely different to that associated with IPv6. In this case existing
>>> players in the inter-domain routing space have no requirement to do
>>> anything now, or in the future. Let me say it again: Folk who have 2 byte
>>> AS numbers need do _nothing_ , i.e. the transition allows for "the
>>> continued use of AS2  space" indefinitely. Please read these references, 
>>> as
>>> they are intended to describe the transition situation in as 
>>> comprehensive
>>> manner as possible.
>> 
>> That is not quite as easy as you describe. To be able to use 32bit ASNs,
>> all routers will need to be upgraded (at least all those who want to 
>> directly communicate/peer with somebody with 32bit ASN).
>
>
> Again, not so. I'll say it again: Please _read_ these references, as they 
> are intended to describe the transition situation in as comprehensive manner 
> as possible.

Ok. It is possible to peer using this special reserved asn even with 16bit
asn-only capable router but things are not going to be entirely right - 
basically this would be the same as trying to use same private asn with
multiple customer networks and leaking it all out to the net. Not a pretty
picture...

Also I do have to note that anyone who actually got 32bit ASN would need
to have router that is capable of using it. This one is absolutely required.

-- 
William Leibzon
Elan Networks
william at elan.net


From gih at apnic.net  Tue Dec 13 16:33:40 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 08:33:40 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.LNX.4.62.0512131310020.6721@sokol.elan.net>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
	<Pine.GSO.4.63.0512130933070.10437@troy>
	<6.2.0.14.2.20051214061633.02d337c8@kahuna.telstra.net>
	<Pine.LNX.4.62.0512131130540.6721@sokol.elan.net>
	<6.2.0.14.2.20051214075043.02d8c5b8@kahuna.telstra.net>
	<Pine.LNX.4.62.0512131310020.6721@sokol.elan.net>
Message-ID: <6.2.0.14.2.20051214083142.02d80ba0@kahuna.telstra.net>


>
>Ok. It is possible to peer using this special reserved asn even with 16bit
>asn-only capable router but things are not going to be entirely right - 
>basically this would be the same as trying to use same private asn with
>multiple customer networks and leaking it all out to the net. Not a pretty
>picture...


not pretty - and the view outward from these domains would be that AS23456 
would start to appear all over the pace ... but it would work, and there is 
no a priori requirement for the 2-byte AS domain to upgrade its BGP to be 
4-byte capable.


>Also I do have to note that anyone who actually got 32bit ASN would need
>to have router that is capable of using it. This one is absolutely required.


absolutely!

   Geoff





From dr at cluenet.de  Tue Dec 13 18:49:29 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Wed, 14 Dec 2005 00:49:29 +0100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051213194822.GA32278@nokia.com>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<20051213194822.GA32278@nokia.com>
Message-ID: <20051213234929.GA11377@srv01.cluenet.de>

On Tue, Dec 13, 2005 at 11:48:22AM -0800, David Kessens wrote:
> > ok - unless I hear to the contrary I'll run with the notation <high>.<low>
> > 
> > e.g. 10.1
> 
> I would prefer hex notation for the numbers.

And how do you differentiate between AS1234 and AS1234 (being decimal
AS4660)? You'll need syntactic sugar again for that. And ASa5f3 doesn't
look appealing either, neither does ASA5F3 to me.

So: how would you want representation to look like?

Anyhow, that stuff will have interesting consequences to RPSL as well.
Is there any work already in progress examining those? I have to admit
that I have some understanding about the 32bit ASN hack as proposed
technically, but no idea about the discussion of problems surrounding
that. Especially the RPSL one might lead to much longer lead times than
2007-01-01 I fear.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From tme at multicasttech.com  Tue Dec 13 23:57:56 2005
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 13 Dec 2005 23:57:56 -0500
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051213194822.GA32278@nokia.com>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<20051213194822.GA32278@nokia.com>
Message-ID: <A01555C9-49C4-4E76-B18A-F608DAACF962@multicasttech.com>

I would not prefer hex. How many different ways do we need to  
describe 32 bit numbers ? Are we going to
mix  hex and decimal with old and new ASN numbers ?

I do like the <second 16 bits>.<last 16 bits> notation if there is  
going to be any aggregation of ASN numbers, which it seems like there  
will be. In that case, though, why not use CIDR notation ? It seems  
like the  proposal
includes giving each RIR a /16 ASN block - I wonder if geographic  
based addressing models will start asking for ASN blocks (say, a /15  
to give one ASN for each US zip code) ?

Regards
Marshall Eubanks

On Dec 13, 2005, at 2:48 PM, David Kessens wrote:

>
> Geoff,
>
> On Tue, Dec 13, 2005 at 08:14:58PM +1100, Geoff Huston wrote:
>> my mistake - I did mean 16 bit separation - I just didn't type it!
>>
>> ok - unless I hear to the contrary I'll run with the notation  
>> <high>.<low>
>>
>> e.g. 10.1
>
> I would prefer hex notation for the numbers. When numbers get larger,
> the ASCII version gets longer and longer. Hex could compress it's size
> considerably and we might even want to skip the '.' altogether.
>
> David Kessens
> ---
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



From gih at apnic.net  Wed Dec 14 00:14:39 2005
From: gih at apnic.net (Geoff Huston)
Date: Wed, 14 Dec 2005 16:14:39 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <A01555C9-49C4-4E76-B18A-F608DAACF962@multicasttech.com>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<20051213194822.GA32278@nokia.com>
	<A01555C9-49C4-4E76-B18A-F608DAACF962@multicasttech.com>
Message-ID: <6.2.0.14.2.20051214161301.02dd6088@kahuna.telstra.net>

my advice is to stick with something simple that does not assume too much. 
Its just attempting to describe a nomenclature that is easy to use, and 
allows AS numbers to be readily recognized (and remembered).

   Geoff




At 03:57 PM 14/12/2005, Marshall Eubanks wrote:
>I would not prefer hex. How many different ways do we need to
>describe 32 bit numbers ? Are we going to
>mix  hex and decimal with old and new ASN numbers ?
>
>I do like the <second 16 bits>.<last 16 bits> notation if there is
>going to be any aggregation of ASN numbers, which it seems like there
>will be. In that case, though, why not use CIDR notation ? It seems
>like the  proposal
>includes giving each RIR a /16 ASN block - I wonder if geographic
>based addressing models will start asking for ASN blocks (say, a /15
>to give one ASN for each US zip code) ?
>
>Regards
>Marshall Eubanks
>
>On Dec 13, 2005, at 2:48 PM, David Kessens wrote:
>
>>
>>Geoff,
>>
>>On Tue, Dec 13, 2005 at 08:14:58PM +1100, Geoff Huston wrote:
>>>my mistake - I did mean 16 bit separation - I just didn't type it!
>>>
>>>ok - unless I hear to the contrary I'll run with the notation
>>><high>.<low>
>>>
>>>e.g. 10.1
>>
>>I would prefer hex notation for the numbers. When numbers get larger,
>>the ASCII version gets longer and longer. Hex could compress it's size
>>considerably and we might even want to skip the '.' altogether.
>>
>>David Kessens
>>---
>>_______________________________________________
>>PPML mailing list
>>PPML at arin.net
>>http://lists.arin.net/mailman/listinfo/ppml
>




From owen at delong.com  Wed Dec 14 03:41:49 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Dec 2005 00:41:49 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.GSO.4.63.0512130933070.10437@troy>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<6.2.0.14.2.20051213094912.02e56b00@kahuna.telstra.net>
	<Pine.GSO.4.63.0512130933070.10437@troy>
Message-ID: <4B732630E716A09E5E93DB24@odpwrbook.hq.netli.lan>

> More thinking that 1023 could perceived as some as being too large a
> reservation of the top two bytes.
>
I'm afraid I don't understand your issue.  In 4 octet space, we have more
than 4 Billion potential ASNs.  Reserving 1023 of them doesn't really seem
to me like it matters.  Remember, it's not 1023 of each 16 bit block, it's
just 1023 of the first block.  In 32 bit parlance, 0.65520-0.65534 that
is the current private reservation.

I don't think we can really justify shrinking that range given wide 
deployment
that already exists.


> Reservation of the top 1023 2 bytes in 4 byte space is a larger chunk of
> space, than is probably needed, but using the same numbers as in 2 byte
> space is easier to remember -- administrative ease.  The other side is to
> only strip off a few addresses at the top, say: 65520.x - 65534.x,
> instead  of 1023 (in the first 2 bytes of the 4.)
>
Is there some perceived reason to expand the space from it's
current 0.65520-0.65534? I don't see any need for that.  Think of the
current ASNs as the low-order 16 bits of a 32 bit ASN, not the high-order.
Life is much simpler that way.

> ---
>
> AS2 -> AS4 transition will mirror what will happen in IPv6
> implementation.  Won't happen until/if forced, workarounds allowing the
> continued use of AS2  space will probably be developed ala some of the
> tools which extended the  IPv4 lifetime (both good and ugly), they'll be
> some things that won't leave  IPv4 space for 10+ years, if ever, and
> they'll be grumbling all over.  In  other words, same as always.  (but no
> reason not to get started now)

I disagree for the following reasons:

AS2->AS4 transition is much simpler.
AS2 only routers can easily function in an AS2/4 mixed environment.
AS2->AS4 migration only requires changes on BGP speaking routers.
AS2->AS4 migration will essentially occur as a result of natural router
	upgrades whether people intend that to occur or not.
Most BGP Speaking routers tend to get updated relatively often.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051214/3236791b/attachment.sig>

From owen at delong.com  Wed Dec 14 03:49:02 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Dec 2005 00:49:02 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <877ja9m0zl.fsf@valhalla.seastrom.com>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
Message-ID: <30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>



--On December 13, 2005 11:10:38 AM -0500 "Robert E.Seastrom" 
<rs at seastrom.com> wrote:

>
> Geoff Huston <gih at apnic.net> writes:
>
>> ok - unless I hear to the contrary I'll run with the notation
>> <high>.<low>
>>
>> e.g. 10.1
>
> That notation-space is already taken by Appletalk.
>
I'm far less concerned about ambiguities between ASNs and Appletalk
network numbers than I am about ambiguities between 32 bit ASNs and
16 bit ASNs with communities.

Does anyone actually still use Appletalk?

Owen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051214/906c10c8/attachment.sig>

From owen at delong.com  Wed Dec 14 03:58:25 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Dec 2005 00:58:25 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051213194822.GA32278@nokia.com>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<20051213194822.GA32278@nokia.com>
Message-ID: <B6D8512D51BF852CE562D135@odpwrbook.hq.netli.lan>

> I would prefer hex notation for the numbers. When numbers get larger,
> the ASCII version gets longer and longer. Hex could compress it's size
> considerably and we might even want to skip the '.' altogether.
>
David, I would much rather get 5.5 decimal digits to deal with for an ASN
than  8 unseparated hex digits.  5.5 is about the same as a US ZIP code 
(5-4)
in terms of human readability.  It's also on par with many countries
telephone numbers.

Owen


-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051214/04575f45/attachment.sig>

From Michael.Dillon at btradianz.com  Wed Dec 14 05:23:02 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Wed, 14 Dec 2005 10:23:02 +0000
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051214053659.02d887a8@kahuna.telstra.net>
Message-ID: <OFCACD47F9.E6D2D2AC-ON802570D7.00387613-802570D7.0039062A@btradianz.com>

> >Is there something wrong with using 78934526:1234 to refer to
> >community 1234 in AS number 78934526?
> 
> This notation is not formally part of the policy proposal - it is a
> convenience in the same way that the dotted quad notation for
> IPv4 addresses is a convenience. Use it or not as you want.

The dotted quad representation was developped as a 
convenient way to deal with the subnet boundaries between
class A, class B, and class C addresses. As far as I
can see there is no significance of the 16 bit boundary
and, in fact, this discussion of . versus : has led some
people on the list to assume that this boundary does
have some meaning.

This whole issue is silly. AS numbers are 32 bit numbers
with no internal structure whatsoever and there is nothing
wrong with writing an AS number as 78934526. If people are
worried that they are too ordinary they can always write 
them as 0x4B471FE. 

--Michael Dillon



From Michael.Dillon at btradianz.com  Wed Dec 14 05:32:06 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Wed, 14 Dec 2005 10:32:06 +0000
Subject: [ppml] Fw: ":" - Re: Proposed Policy: 4-Byte AS Number
	Policy	Proposal
Message-ID: <OF0448C640.BFB03088-ON802570D7.00393374-802570D7.0039DA9C@btradianz.com>

> I'm also not thrilled with "2-byte only" and "4-byte only" ASN; there's 
too
> much chance of confusion with "2-byte" and "4-byte" ASNs which have a
> different enough meaning to warrant a better distinction.  I'd prefer
> something like "legacy" vs. "expanded", "low" vs. "high", etc.

That's an example of the lack of plain English in the 
proposal. Why don't we just talk about AS numbers greater
than 65535 or AS numbers less than 65536?

1. ARIN begin allocating AS numbers greater than 65535
to those who specifically request them starting on $date.

2. On $date ARIN will not allocate AS numbers less than
65536 unless a small number is specifically requested.

3. On $date, ARIN will no longer make a distinction
between AS numbers less than 65536 and larger ones.

Guess what? I said it in plain English so I don't have to 
define what is an "AS number less than 65536" or an "AS number
greater than 65535". I also don't have to invent silly new
notations so that AS2 looks different after the change. 
A number is a number is a number.

I oppose the policy as stated on the principle that ARIN's
policies must be CLEAR and UNDERSTANDABLE and a lot of work
has gone into rewriting the policy set recently to make them
much easier to understand. THIS IS IMPORTANT!

--Michael Dillon



From Michael.Dillon at btradianz.com  Wed Dec 14 05:37:50 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Wed, 14 Dec 2005 10:37:50 +0000
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051214075043.02d8c5b8@kahuna.telstra.net>
Message-ID: <OFED5D089E.6D1D2502-ON802570D7.003A3356-802570D7.003A6108@btradianz.com>

> Again, not so. I'll say it again: Please _read_ these references, as 
they 
> are intended to describe the transition situation in as comprehensive 
> manner as possible.

That's the problem, they are too darn comprehensive.

Why didn't you just say that people can continue to run
their existing BGP code and they will see any large AS
numbers as a special ASN 23456. People running the new code
will map to and from ASN 23456.

--Michael Dillon



From daniel at unix.za.net  Wed Dec 14 06:04:36 2005
From: daniel at unix.za.net (Daniel Schroder)
Date: Wed, 14 Dec 2005 13:04:36 +0200 (SAST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051213234929.GA11377@srv01.cluenet.de>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<20051213194822.GA32278@nokia.com>
	<20051213234929.GA11377@srv01.cluenet.de>
Message-ID: <20051214130006.D18800@unix.za.net>



On Wed, 14 Dec 2005, Daniel Roesen wrote:

> On Tue, Dec 13, 2005 at 11:48:22AM -0800, David Kessens wrote:
>>> ok - unless I hear to the contrary I'll run with the notation <high>.<low>
>>>
>>> e.g. 10.1
>>
>> I would prefer hex notation for the numbers.
>
> And how do you differentiate between AS1234 and AS1234 (being decimal
> AS4660)? You'll need syntactic sugar again for that. And ASa5f3 doesn't
> look appealing either, neither does ASA5F3 to me.
>
> So: how would you want representation to look like?
>
> Anyhow, that stuff will have interesting consequences to RPSL as well.
> Is there any work already in progress examining those? I have to admit
> that I have some understanding about the 32bit ASN hack as proposed
> technically, but no idea about the discussion of problems surrounding
> that. Especially the RPSL one might lead to much longer lead times than
> 2007-01-01 I fear.

     Just a quick comment, as admins get used to
     IPV6, surely it makes sense to move over to
     hex notation for As numbers as well.

     It will add an extra chapter to the cisco
     manauls, but I guess the internet should
     not be maintained by individuals who are
     easily confused.

     regards, Daniel (Schroder)

>
> Best regards,
> Daniel
>
> -- 
> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>


From Lee.Howard at stanleyassociates.com  Wed Dec 14 10:21:12 2005
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 14 Dec 2005 10:21:12 -0500
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4D48F61@CL-S-EX-1.stanleyassociates.com>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Daniel Schroder

>      Just a quick comment, as admins get used to
>      IPV6, surely it makes sense to move over to
>      hex notation for As numbers as well.
> 
>      It will add an extra chapter to the cisco
>      manauls, but I guess the internet should
>      not be maintained by individuals who are
>      easily confused.

Is that an RFC2119 "should not"?

When creating long strings of digits, I find it easier/faster to 
use keypad characters, i.e., decimal.

Lee

> 
>      regards, Daniel (Schroder)
> 
> >
> > Best regards,
> > Daniel
> >
> > -- 
> > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
> > _______________________________________________
> > PPML mailing list
> > PPML at arin.net
> > http://lists.arin.net/mailman/listinfo/ppml
> >
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From billd at cait.wustl.edu  Wed Dec 14 10:27:29 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Wed, 14 Dec 2005 09:27:29 -0600
Subject: [ppml] ":" - Re: Proposed Policy: 4-Byte AS Number Policy
	Pro	posal
Message-ID: <CC5444841A969F4CBBF6A305E569F008030032@kronos.cait.wustl.edu>

I believe the decimal.decimal is the appropriate reference because people
are used to dotted decimal and they are used to 16bit decimal for ASs.  Just
my dot02  

> 
> I will revise the proposal with a '.' rather than a ':' delimiter.
> 
> 
> thanks,
> 
>    Geoff
> 
> 
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From rich at nic.umass.edu  Wed Dec 14 10:29:14 2005
From: rich at nic.umass.edu (Rich Emmings)
Date: Wed, 14 Dec 2005 10:29:14 -0500 (EST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <54CF4C1F7880491E11A47EDB@odpwrbook.hq.netli.lan>
References: <439D7EC1.2040109@arin.net> <Pine.GSO.4.63.0512121723100.444@troy>
	<ACF260D0AA7CB9FD9728F822@odpwrbook.hq.netli.lan>
	<Pine.GSO.4.63.0512131604510.10437@troy>
	<54CF4C1F7880491E11A47EDB@odpwrbook.hq.netli.lan>
Message-ID: <Pine.GSO.4.63.0512141024310.27101@troy>

On Wed, 14 Dec 2005, Owen DeLong wrote:

>I'm afraid I don't understand your issue.  In 4 octet space, we have more
>than 4 Billion potential ASNs.  Reserving 1023 of them doesn't really seem
>to me like it matters.  Remember, it's not 1023 of each 16 bit block, it's
>just 1023 of the first block.  In 32 bit parlance, 0.65520-0.65534 that
>is the current private reservation.
>
>I don't think we can really justify shrinking that range given wide 
>deployment that already exists.

Ok, trying the simple approach, "4 Byte ASN numbers > 4294836224 and < 
4294967295 are reserved as 4 byte private ASN's.  The existing 2 byte ASN's 
are left as is.  (or use dotted notation if it's of more comfort.)

> I think that play can be done and/or filtered in other ways without requiring
> the creation of an additional block of private ASNs for that purpose.
>
> Not announce filters that exclude your 4-byte ASN are easy enough to build
> pretty reliably.
>

Absolutely can be done, the question is, will it be done?  Ref: the weekly 
reports to nanog that include who is leaking addresses and ASN's.  At least 
in that context, they are tagged as invalid.


From owen at delong.com  Wed Dec 14 10:51:11 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Dec 2005 07:51:11 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <OFCACD47F9.E6D2D2AC-ON802570D7.00387613-802570D7.0039062A@btradianz.com>
References: <OFCACD47F9.E6D2D2AC-ON802570D7.00387613-802570D7.0039062A@btrad
	ianz.com>
Message-ID: <AF54F2A40B776705EC0F1F73@imac-en0.delong.sj.ca.us>

> 
> This whole issue is silly. AS numbers are 32 bit numbers
> with no internal structure whatsoever and there is nothing
> wrong with writing an AS number as 78934526. If people are
> worried that they are too ordinary they can always write 
> them as 0x4B471FE. 
> 
While everything you say above is true, it's bad human engineering.

There are reasons to break numbers into chunks besides just the
presence or absence of internal structure.  Human readability
is on example.  Believe it or not, studies have shown that
humans are far more likely to be able to read/remember/repeat
accurately a number that is 5-5 than a number that is 8 or
more digits in length as a single field.

Studies have also shown that most humans don't cope as well with
Hex as they do with Decimal.  When it comes to ASNs, I'd rather
try and advocate things that will reduce the likelihood of 
human error than increase it.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051214/87c60cbe/attachment.sig>

From gih at apnic.net  Wed Dec 14 14:38:10 2005
From: gih at apnic.net (Geoff Huston)
Date: Thu, 15 Dec 2005 06:38:10 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
	<30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
Message-ID: <6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net>

At 07:49 PM 14/12/2005, Owen DeLong wrote:


>--On December 13, 2005 11:10:38 AM -0500 "Robert E.Seastrom" 
><rs at seastrom.com> wrote:
>
>>
>>Geoff Huston <gih at apnic.net> writes:
>>
>>>ok - unless I hear to the contrary I'll run with the notation
>>><high>.<low>
>>>
>>>e.g. 10.1
>>
>>That notation-space is already taken by Appletalk.
>I'm far less concerned about ambiguities between ASNs and Appletalk
>network numbers than I am about ambiguities between 32 bit ASNs and
>16 bit ASNs with communities.
>
>Does anyone actually still use Appletalk?


I went through a similar thought process and came to the conclusion that 
the combination of Appletalk and BGP and AS numbers was going to be a rare 
one out there in the field!


   Geoff





From gih at apnic.net  Wed Dec 14 15:03:56 2005
From: gih at apnic.net (Geoff Huston)
Date: Thu, 15 Dec 2005 07:03:56 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <OFED5D089E.6D1D2502-ON802570D7.003A3356-802570D7.003A6108@
	btradianz.com>
References: <6.2.0.14.2.20051214075043.02d8c5b8@kahuna.telstra.net>
	<OFED5D089E.6D1D2502-ON802570D7.003A3356-802570D7.003A6108@btradianz.com>
Message-ID: <6.2.0.14.2.20051215065525.03304af8@kahuna.telstra.net>

At 09:37 PM 14/12/2005, Michael.Dillon at btradianz.com wrote:
> > Again, not so. I'll say it again: Please _read_ these references, as
>they
> > are intended to describe the transition situation in as comprehensive
> > manner as possible.
>
>That's the problem, they are too darn comprehensive.
>
>Why didn't you just say that people can continue to run
>their existing BGP code and they will see any large AS
>numbers as a special ASN 23456. People running the new code
>will map to and from ASN 23456.


(we are probably off in the weeds here as this discussion on the cited 
references is now heading well beyond the attributes of the proposal 
itself, so I'll respond on the list this time, but followup 1:1 if required 
- geoff)

The cited references describe how the mechanism operates, and, in 
particular describe how the combination of auto-translation and 
auto-tunnelling at the boundaries of the 2-byte and 4-byte AS realms 
jointly preserve the essential attributes of the AS_PATH attribute in the 
context of inter-domain Routing: namely preservation of the inter-AS path 
metric and loop detection. For many folk reading those articles the 
description of how this is achieved is as, or more, important as the 
description of the outcome of these mechanisms.


thanks,

    Geoff



From ppml at rs.seastrom.com  Wed Dec 14 16:34:22 2005
From: ppml at rs.seastrom.com (Robert E.Seastrom)
Date: Wed, 14 Dec 2005 16:34:22 -0500
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net> (Geoff
	Huston's message of "Thu, 15 Dec 2005 06:38:10 +1100")
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
	<30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net>
Message-ID: <87ek4f1hy9.fsf@valhalla.seastrom.com>


Geoff Huston <gih at apnic.net> writes:

> I went through a similar thought process and came to the conclusion that 
> the combination of Appletalk and BGP and AS numbers was going to be a rare 
> one out there in the field!

That was an attempt to be funny whilst punchy from jet lag.

On a more serious note, I think what you're suggesting is actually
three separate proposals..

The first proposal (start allocating 32 bit ASNs upon request), I'm
all for, and the sooner the better.

The second proposal (start allocating 32 bit ASNs by default), my
problem is not with the body of the proposal so much as I take issue
with the notion that we can set a date for it before we have some
operational experience with proposal 1.  I would fully support this
phase as part of an omnibus roll-up if it were altered to say "after
no less than $MONTHS of operational experience with 32 bit ASNs, at
the registry staff's discretion, $REGISTRY may change its operational
procedures to issue 32 bit ASNs by default and only issue 16 bit ASNs
upon special request." or words to that effect.

The third proposal (discontinue issuance of 16 bit ASNs), is one for
which I don't see any compelling reason.  If we let them be available
upon request indefinitely, they'll be requested with lower and lower
frequency, until finally there are no more.  Beyond the notion to
"save for a rainy day" (or maybe a router museum with CSC2s and
Proteons and a BBN C30 speaking EGP on a VDH or X.25 interface),
what's the motivation?

Assuming that there's actually a good reason for the third propsal
which I am not understanding, I would think it would be premature to
propose such a policy change until the first and second proposals are
solidly behind us and executed.

My $0.02 on the notation: It's just a u_int32.  Write it that way.  It
will be easy for humans to differentiate between old style and new
style by the fact that the 32 bit ASNs are all bigger than 65535.

                                        ---Rob



From gih at apnic.net  Wed Dec 14 17:30:51 2005
From: gih at apnic.net (Geoff Huston)
Date: Thu, 15 Dec 2005 09:30:51 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <87ek4f1hy9.fsf@valhalla.seastrom.com>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
	<30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net>
	<87ek4f1hy9.fsf@valhalla.seastrom.com>
Message-ID: <6.2.0.14.2.20051215090718.02b55238@kahuna.telstra.net>

At 08:34 AM 15/12/2005, Robert E.Seastrom wrote:

>Geoff Huston <gih at apnic.net> writes:
>
> > I went through a similar thought process and came to the conclusion that
> > the combination of Appletalk and BGP and AS numbers was going to be a rare
> > one out there in the field!
>
>That was an attempt to be funny whilst punchy from jet lag.
>
>On a more serious note, I think what you're suggesting is actually
>three separate proposals..


not really - I am trying to identify particular phases in transition and 
place reasonable milestone dates against each phase that generate some 
predictability for the industry to work to.


>The first proposal (start allocating 32 bit ASNs upon request), I'm
>all for, and the sooner the better.


As has already been noted it cannot be any sooner given the preconditions 
to get this undertaken.


>The second proposal (start allocating 32 bit ASNs by default), my
>problem is not with the body of the proposal so much as I take issue
>with the notion that we can set a date for it before we have some
>operational experience with proposal 1.  I would fully support this
>phase as part of an omnibus roll-up if it were altered to say "after
>no less than $MONTHS of operational experience with 32 bit ASNs, at
>the registry staff's discretion, $REGISTRY may change its operational
>procedures to issue 32 bit ASNs by default and only issue 16 bit ASNs
>upon special request." or words to that effect.

I had thought of this and thought that the notion of a fixed 24 month lead 
period of 32 bite AS numbers being available upon request was adequate in 
terms of vendor actions to deploy BGP code versions that supported this, 
and also to avoid having to place registry staff in the position of having 
to make calls relating to operational readiness. The date also implies that 
there should be a reasonable remaining pool of unallocated 16 bit AS 
Numbers (some 15,000) so that in this second phase the criteria for 16 bit 
AS numbers allocations upon request should be exactly that  - that the 
client has requested a 16 bit AS number. If we leave this second phase too 
late we will get into "allocation upon request as justified" and then head 
off into all kinds of justification criteria. I thought that by specifying 
the date we will have a better assurance that there will be an adequate 
pool of 16 bit AS numbers left that would be able to satisfy requests 
without providing any further justification and evaluation and assessment 
of the justification by registry staff.


>The third proposal (discontinue issuance of 16 bit ASNs), is one for
>which I don't see any compelling reason.  If we let them be available
>upon request indefinitely, they'll be requested with lower and lower
>frequency, until finally there are no more.  Beyond the notion to
>"save for a rainy day" (or maybe a router museum with CSC2s and
>Proteons and a BBN C30 speaking EGP on a VDH or X.25 interface),
>what's the motivation?


There is no proposal to discontinue issue of 16 bit ASNs. The proposal 
states that as of the third date the 32 bit AS number pool is treated as a 
single pool, and there is no further special treatment of 16 bit ASNs or 32 
bit ASNs. Its all just one big AS number pool as of the third date.


>Assuming that there's actually a good reason for the third propsal
>which I am not understanding, I would think it would be premature to
>propose such a policy change until the first and second proposals are
>solidly behind us and executed.

The third part of the proposal is in fact the removal of this temporary 
policy, because as of that date we are back to allocating AS numbers from a 
AS number pool - _precisely_ the same as today.

>My $0.02 on the notation: It's just a u_int32.  Write it that way.  It
>will be easy for humans to differentiate between old style and new
>style by the fact that the 32 bit ASNs are all bigger than 65535.


So are IP v4 addresses. The dotted quad IPv4 notation is a human use 
convenience. The splitting into two decimal numbers on the 16 bit position 
is also just a simple human use convenience.

thanks,

     Geoff




From owen at delong.com  Wed Dec 14 23:45:35 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Dec 2005 20:45:35 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051215090718.02b55238@kahuna.telstra.net>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
	<30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net>
	<87ek4f1hy9.fsf@valhalla.seastrom.com>
	<6.2.0.14.2.20051215090718.02b55238@kahuna.telstra.net>
Message-ID: <4E6925D7C09BE759CA1698A5@odpwrbook.hq.netli.lan>

While I think Rob's concerns are somewhat valid, I would suggest the 
following:

1.	Geoff makes excellent points about needing to set target dates
	in order to provide incentive towards operational experience
	moving forward.  These dates will help overcome inertia prior
	to needing a crisis to do so.  A crisis based change would
	be bad for a number of reasons.

2.	I think that the ARIN BOD emergency policy rescind authority can
	be an adequate safeguard against phase two starting in some
	form of catastrophically early.  It's not like they tend to be
	asleep at the switch on such issues.

Just my $0.02.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051214/c04e020b/attachment.sig>

From william at elan.net  Thu Dec 15 08:22:16 2005
From: william at elan.net (william(at)elan.net)
Date: Thu, 15 Dec 2005 05:22:16 -0800 (PST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <4E6925D7C09BE759CA1698A5@odpwrbook.hq.netli.lan>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
	<30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net>
	<87ek4f1hy9.fsf@valhalla.seastrom.com>
	<6.2.0.14.2.20051215090718.02b55238@kahuna.telstra.net>
	<4E6925D7C09BE759CA1698A5@odpwrbook.hq.netli.lan>
Message-ID: <Pine.LNX.4.62.0512150515200.26465@sokol.elan.net>


We should not rely on the emergency powers - there is a reason why it
is called emergency after all...

My view is that we should avoid putting dates several years in the future 
in the policy proposals without very good reason to believe it can 
happen at the time proposal is made. It is better to leave deciding
exact date to the discretion of ARIN and I think ARIN staff on its
own can be bring this issue on the meeting & mail lists and base
actual date on the consensus of the community.

P.S. Do any of you still remember how many times date for discontinuing
6bone was moved?

On Wed, 14 Dec 2005, Owen DeLong wrote:

> While I think Rob's concerns are somewhat valid, I would suggest the 
> following:
>
> 1.	Geoff makes excellent points about needing to set target dates
> 	in order to provide incentive towards operational experience
> 	moving forward.  These dates will help overcome inertia prior
> 	to needing a crisis to do so.  A crisis based change would
> 	be bad for a number of reasons.
>
> 2.	I think that the ARIN BOD emergency policy rescind authority can
> 	be an adequate safeguard against phase two starting in some
> 	form of catastrophically early.  It's not like they tend to be
> 	asleep at the switch on such issues.
>
> Just my $0.02.
>
> Owen


From billd at cait.wustl.edu  Thu Dec 15 09:26:01 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Thu, 15 Dec 2005 08:26:01 -0600
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>

Rarely do things happen if there is not a sense of urgency or a clear path
or a lever that influences change.
I see in Geoff's proposal a clear path precipitated by a declining resource
that would have severe impact and the policy with dates established provides
the leverage to move.  If you think the dates cannot be met, then those
stakes can be driven further out perhaps, but I see the timeline as being a
principle quality of the proposal.  Given dates that one thinks are
reasonable milestones, then there is nothing wrong with using the
extraordinary power of the BOD, because it would be an extraordinary
circumstance when the community agreed that the timeline was reasonable and
achievable and it was not for reasons that could not be foreseen...IMO.

bd

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of william(at)elan.net
> Sent: Thursday, December 15, 2005 7:22 AM
> To: Owen DeLong
> Cc: ppml at arin.net
> Subject: Re: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
> 
> 
> 
> We should not rely on the emergency powers - there is a 
> reason why it is called emergency after all...
> 
> My view is that we should avoid putting dates several years 
> in the future 
> in the policy proposals without very good reason to believe it can 
> happen at the time proposal is made. It is better to leave 
> deciding exact date to the discretion of ARIN and I think 
> ARIN staff on its own can be bring this issue on the meeting 
> & mail lists and base actual date on the consensus of the community.
> 
> P.S. Do any of you still remember how many times date for 
> discontinuing 6bone was moved?
> 
> On Wed, 14 Dec 2005, Owen DeLong wrote:
> 
> > While I think Rob's concerns are somewhat valid, I would suggest the
> > following:
> >
> > 1.	Geoff makes excellent points about needing to set target dates
> > 	in order to provide incentive towards operational experience
> > 	moving forward.  These dates will help overcome inertia prior
> > 	to needing a crisis to do so.  A crisis based change would
> > 	be bad for a number of reasons.
> >
> > 2.	I think that the ARIN BOD emergency policy rescind authority can
> > 	be an adequate safeguard against phase two starting in some
> > 	form of catastrophically early.  It's not like they tend to be
> > 	asleep at the switch on such issues.
> >
> > Just my $0.02.
> >
> > Owen
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From william at elan.net  Thu Dec 15 09:34:04 2005
From: william at elan.net (william(at)elan.net)
Date: Thu, 15 Dec 2005 06:34:04 -0800 (PST)
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
Message-ID: <Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>


On Thu, 15 Dec 2005, Bill Darte wrote:

> the leverage to move.  If you think the dates cannot be met,

No, I don't think these dates will be met. Nor does IETF have a good
record in meeting proposed dates for introduction of new technologies
or meeting its own deadlines in WGs for that matter...

> then those stakes can be driven further out perhaps, but I see the 
> timeline as being a principle quality of the proposal.

I believe its good to mention that specific timeline will be posted
as agreed by the community. I just don't think specific timeline
should be set in stone at this stage as part of policy text.

-- 
William Leibzon
Elan Networks
william at elan.net


From billd at cait.wustl.edu  Thu Dec 15 10:16:52 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Thu, 15 Dec 2005 09:16:52 -0600
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
Message-ID: <CC5444841A969F4CBBF6A305E569F008030038@kronos.cait.wustl.edu>


> 
> On Thu, 15 Dec 2005, Bill Darte wrote:
> 
> > the leverage to move.  If you think the dates cannot be met,
> 
> No, I don't think these dates will be met. Nor does IETF have 
> a good record in meeting proposed dates for introduction of 
> new technologies or meeting its own deadlines in WGs for that 
> matter...

Suggest a more appropriate timeline?

> 
> I believe its good to mention that specific timeline will be 
> posted as agreed by the community. I just don't think 
> specific timeline should be set in stone at this stage as 
> part of policy text.

ARIN policy is not stone.  It is prescribed practice by consensus.  The
credo is to try to get it right by bringing lots of smart stakeholders
together and let them decide...if it goes badly for unforeseen reasons, then
remedy it in practice by changing the policy....if there is inadequate time
for the policy remedy by normal channels and procedure, then the BOT
modifies it as necessary and the community catches up at the next regular
meeting. 

This is the REGULAR and prescribed mechanism.  There are no emergency powers
really, and the policy process in very flexible.

> 
> -- 
> William Leibzon
> Elan Networks
> william at elan.net
> 

bd


From gih at apnic.net  Thu Dec 15 14:38:37 2005
From: gih at apnic.net (Geoff Huston)
Date: Fri, 16 Dec 2005 06:38:37 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
	<Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
Message-ID: <6.2.0.14.2.20051216061657.02d956d0@kahuna.telstra.net>

At 01:34 AM 16/12/2005, william(at)elan.net wrote:

>On Thu, 15 Dec 2005, Bill Darte wrote:
>
> > the leverage to move.  If you think the dates cannot be met,
>
>No, I don't think these dates will be met. Nor does IETF have a good
>record in meeting proposed dates for introduction of new technologies
>or meeting its own deadlines in WGs for that matter...


When you say "the dates cannot be met" don't forget that the industry is 
positioning itself against a very hard barrier - namely the exhaustion of 
the 6 bit AS number space, and the transition into a larger 4 byte pool is 
one that cannot be deferred for anyone's particular convenience. So if this 
date will not be met, the only alternative is ... ? This is not a 
choice-rich environment here, and exhaustion of a finite resource pool 
tends to drive a set of imperatives that, ultimately, are not easy to argue 
with.

The essential element of this proposal is to commence a transition well in 
advance of an exhaustion crisis, and provide some clear signals to vendors 
as to the dates by which 4 byte AS number capability is required in BGP 
products, and clear signals to network operators and admins that if they 
need AS numbers, the dates by which they will need to be fielding these 
4-byte AS number products. Of course if you don't plan to be needing 
further AS numbers sometime after 2009, then this is of no particular 
consequence for you,

> > then those stakes can be driven further out perhaps, but I see the
> > timeline as being a principle quality of the proposal.
>
>I believe its good to mention that specific timeline will be posted
>as agreed by the community. I just don't think specific timeline
>should be set in stone at this stage as part of policy text.

Pragmatically it is not possible to make this process significantly faster, 
and if you are advocating here to make it much slower then all that will be 
achieved is  creating policy stands the strong risk of unglueing itself 
from any form of reality, simply because there is also this issue of the 
timeline of AS number exhaustion to consider, which is still looking like 
happening in October 2010, absent any changes in AS allocation behaviours. 
The entire concept of this policy is to avoid an expensive and needless 
industry crisis through decent advance planning, and, yes, perhaps 
surprisingly, planning typically involves the specification of milestones 
and dates. Through this planning process we can make this transition 
painless and relatively simple. Or we can, collectively, simply stuff it 
up! :-)

regards,

     Geoff






From tony.li at tony.li  Thu Dec 15 15:05:23 2005
From: tony.li at tony.li (Tony Li)
Date: Thu, 15 Dec 2005 12:05:23 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051216061657.02d956d0@kahuna.telstra.net>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
	<Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
	<6.2.0.14.2.20051216061657.02d956d0@kahuna.telstra.net>
Message-ID: <E02B3B94-7927-41F9-8931-C4FB7255E931@tony.li>


On Dec 15, 2005, at 11:38 AM, Geoff Huston wrote:
>
> When you say "the dates cannot be met" don't forget that the  
> industry is
> positioning itself against a very hard barrier - namely the  
> exhaustion of
> the 6 bit AS number space, and the transition into a larger 4 byte  
> pool is
> one that cannot be deferred for anyone's particular convenience. So  
> if this
> date will not be met, the only alternative is ... ? This is not a
> choice-rich environment here, and exhaustion of a finite resource pool
> tends to drive a set of imperatives that, ultimately, are not easy  
> to argue
> with.


Might I suggest that this argument is so strong that it completely  
overwhelms any
dates that we care to specify.  Until there is exhaustion, there will  
not be enough
pain to drive deployment.  When there is exhaustion, that will  
definitely drive
deployment.

Thus, arguing about dates is largely pointless.

Regards,
Tony



From gih at apnic.net  Thu Dec 15 15:24:22 2005
From: gih at apnic.net (Geoff Huston)
Date: Fri, 16 Dec 2005 07:24:22 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <6.2.0.14.2.20051216061657.02d956d0@kahuna.telstra.net>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
	<Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
	<6.2.0.14.2.20051216061657.02d956d0@kahuna.telstra.net>
Message-ID: <6.2.0.14.2.20051216072138.02dd5ca0@kahuna.telstra.net>

I just realized that in that last posting I introduced a new AS number 
space - namely the "6 bit AS Number"

No, this is not a resurgence of those often bizarre coding formats of the 
1960's - just put it down to brain - finger interaction problems. Obviously 
I meant to say "16 bit" :-)


thanks,

   Geoff


  06:38 AM 16/12/2005, Geoff Huston wrote:
>At 01:34 AM 16/12/2005, william(at)elan.net wrote:
>
> >On Thu, 15 Dec 2005, Bill Darte wrote:
> >
> > > the leverage to move.  If you think the dates cannot be met,
> >
> >No, I don't think these dates will be met. Nor does IETF have a good
> >record in meeting proposed dates for introduction of new technologies
> >or meeting its own deadlines in WGs for that matter...
>
>
>When you say "the dates cannot be met" don't forget that the industry is
>positioning itself against a very hard barrier - namely the exhaustion of
>the 6 bit AS number space, and the transition into a larger 4 byte pool is
>one that cannot be deferred for anyone's particular convenience. So if this
>date will not be met, the only alternative is ... ? This is not a
>choice-rich environment here, and exhaustion of a finite resource pool
>tends to drive a set of imperatives that, ultimately, are not easy to argue
>with.




From owen at delong.com  Fri Dec 16 02:29:10 2005
From: owen at delong.com (Owen DeLong)
Date: Thu, 15 Dec 2005 23:29:10 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.LNX.4.62.0512150515200.26465@sokol.elan.net>
References: <439D7EC1.2040109@arin.net>
	<8E46DADC591AE2836023BEEB@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213171209.02d13e20@kahuna.telstra.net>
	<E78B27E3879D1FFA792D8955@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051213201331.02de9208@kahuna.telstra.net>
	<877ja9m0zl.fsf@valhalla.seastrom.com>
	<30E602CE6C38AE928943FEA5@odpwrbook.hq.netli.lan>
	<6.2.0.14.2.20051215063702.02db7da8@kahuna.telstra.net>
	<87ek4f1hy9.fsf@valhalla.seastrom.com>
	<6.2.0.14.2.20051215090718.02b55238@kahuna.telstra.net>
	<4E6925D7C09BE759CA1698A5@odpwrbook.hq.netli.lan>
	<Pine.LNX.4.62.0512150515200.26465@sokol.elan.net>
Message-ID: <064A4584A80066C3EC72D73D@odpwrbook.hq.netli.lan>



--On December 15, 2005 5:22:16 AM -0800 "william(at)elan.net" 
<william at elan.net> wrote:

>
> We should not rely on the emergency powers - there is a reason why it
> is called emergency after all...
>
While I generally agree with you, I think it is reasonable to make policies
based on what seems to be reasonable time limits at the time the policy
is made.  If things change, then, it will either be an emergency, or,
it will get rectified through subsequent policy process.  If it is an
emergency, then, that is what the emergency powers are there for.  To
allow the BOD to deal with situations that come up and require action faster
than the policy process can act.

Having worked in actual emergency services (I was an ambulance driver/tech. 
for
a few years some years back), I can tell you that the definition of the
term emergency is very context sensitive.  In ARIN terms, the "emergency"
powers granted to the BOD are oriented towards a definition of emergency
as I conveyed above.  To a 911 dispatcher, the term "emergency" generally
means any situation for which you require a response from some form of
emergency services, preferably one in which said response is urgent.
For my current management, the definition of emergency is whatever customer
is yanking their chain today.

> My view is that we should avoid putting dates several years in the future
> in the policy proposals without very good reason to believe it can happen
> at the time proposal is made. It is better to leave deciding
> exact date to the discretion of ARIN and I think ARIN staff on its
> own can be bring this issue on the meeting & mail lists and base
> actual date on the consensus of the community.
>
I think we have good reason to believe that the timeframe proposed in
this policy is not only achievable, but, may well be necessary if we
have any hope of avoiding an emergency.  Having a deadline at the
discretion of the ARIN staff in this context is inappropriate and unfair
to the ARIN staff.  The community should set policy, and, delegating the
authority to do so to the staff, especially on something like this,
places them in an unfair hotseat.  It is important for the staff to
be able to apply these guidelines in a fair and equitable manner.
It is equally important for them to be able to show that the policy
is the result of community consensus and that there is a community
based process for making changes to it.  If we make the date at
their discretion, we make both of those things problematic for them.

> P.S. Do any of you still remember how many times date for discontinuing
> 6bone was moved?
>
The issuance of 32 bit ASNs is far less difficult than the decommissioning
of 6bone or the switch to IPv6.  It is not a fair comparison.  I do not 
believe
the date for the cessation of issuing 6bone addresses was moved.  I believe
that date was put in place and was adhered to.  Perhaps I remember wrong, 
but,
that's what I recall.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051215/f8783b22/attachment.sig>

From owen at delong.com  Fri Dec 16 02:39:48 2005
From: owen at delong.com (Owen DeLong)
Date: Thu, 15 Dec 2005 23:39:48 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
	<Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
Message-ID: <8CF409BCCB00BC404F9B27F6@odpwrbook.hq.netli.lan>

>> then those stakes can be driven further out perhaps, but I see the
>> timeline as being a principle quality of the proposal.
>
> I believe its good to mention that specific timeline will be posted
> as agreed by the community. I just don't think specific timeline
> should be set in stone at this stage as part of policy text.

I think that if we don't set targets in the text of the policy, the policy
loses most of it's value.

Owen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051215/93957c52/attachment.sig>

From dlw+arin at tellme.com  Fri Dec 16 11:36:56 2005
From: dlw+arin at tellme.com (David Williamson)
Date: Fri, 16 Dec 2005 08:36:56 -0800
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <8CF409BCCB00BC404F9B27F6@odpwrbook.hq.netli.lan>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
	<Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
	<8CF409BCCB00BC404F9B27F6@odpwrbook.hq.netli.lan>
Message-ID: <20051216163656.GI18824@shell01.corp.tellme.com>

On Thu, Dec 15, 2005 at 11:39:48PM -0800, Owen DeLong wrote:
> >I believe its good to mention that specific timeline will be posted
> >as agreed by the community. I just don't think specific timeline
> >should be set in stone at this stage as part of policy text.
> 
> I think that if we don't set targets in the text of the policy, the policy
> loses most of it's value.

I've been quietly watching this thread, and the timeline seems to be biggest
point of concern.  (I think there's strong agreement that a 4-byte AS is
rather inevitable.)

I completely agree with Owen that a set timeline is vital to the
policy.  Without it, it's just a simple guideline that identifies that
we'll run out of 2-byte AS space "soon".  That's not an interesting
policy, but rather a statement of facts.  The timeline is what gives
the policy teeth.  Let's not take the bite out of it!

-David


From gih at apnic.net  Fri Dec 16 15:55:06 2005
From: gih at apnic.net (Geoff Huston)
Date: Sat, 17 Dec 2005 07:55:06 +1100
Subject: [ppml] Proposed Policy: 4-Byte AS Number Policy Proposal
In-Reply-To: <20051216163656.GI18824@shell01.corp.tellme.com>
References: <CC5444841A969F4CBBF6A305E569F008030037@kronos.cait.wustl.edu>
	<Pine.LNX.4.62.0512150625590.26465@sokol.elan.net>
	<8CF409BCCB00BC404F9B27F6@odpwrbook.hq.netli.lan>
	<20051216163656.GI18824@shell01.corp.tellme.com>
Message-ID: <6.2.0.14.2.20051217075409.02ca26e8@kahuna.telstra.net>

At 03:36 AM 17/12/2005, David Williamson wrote:
>I completely agree with Owen that a set timeline is vital to the
>policy.  Without it, it's just a simple guideline that identifies that
>we'll run out of 2-byte AS space "soon".  That's not an interesting
>policy, but rather a statement of facts.  The timeline is what gives
>the policy teeth.  Let's not take the bite out of it!


Personally, I prefer to use the word "substance" rather than "teeth"
in this context. :-)

Geoff




From memsvcs at arin.net  Mon Dec 19 17:54:19 2005
From: memsvcs at arin.net (Member Services)
Date: Mon, 19 Dec 2005 17:54:19 -0500
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
Message-ID: <43A73A1B.1000102@arin.net>

On December 15, 2005, the ARIN Advisory Council concluded its review of
proposed policy 4-Byte AS Number Policy Proposal and agreed to forward 
it as a formal proposal for discussion by the community. This proposal 
is designated Policy Proposal 2005-9: 4-Byte AS Number. The policy 
proposal text is below and can be found at:

http://www.arin.net/policy/proposals/2005_9.html

All persons in the community are encouraged to discuss Policy Proposal
2005-9 in the weeks leading to the ARIN Public Policy Meeting in
Montreal scheduled for April 10-11, 2006. Both the discussion on the
Public Policy Mailing List and at the public policy meeting will be used
to determine the community consensus regarding this policy proposal.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

ARIN's Policy Proposal Archive can be found at:
http://www.arin.net/policy/proposals/proposal_archive.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###


Policy Proposal Name: 4-Byte AS Number

Author: Geoff Huston

Policy Term: Temporary (1 January 2007 - 1 January 2010)

Policy Statement:

          This policy proposal nominates 3 dates for changes to the
          current AS Number allocation policy for the registry:

          On 1 January 2007 the registry will process applications that
          specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.

          On 1 January 2009 the registry will process applications that
          specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.

          On 1 January 2010 the registry will cease to make any
          distinction between 2-byte only AS Numbers and 4-byte only AS
          Numbers, and will operate AS number allocations from an
          undifferentiated 4-byte AS Number allocation pool.

          Nomenclature

          It is proposed to identify 4-byte AS Numbers using a syntax of
          <high order 16 bit value in decimal>:<low order 16 bit value
          in decimal>. Accordingly, a 4-byte AS number of value 65546
          (decimal) would be identified as "1:10".

          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)

Rationale:

          Recent studies of AS number consumption rates indicate that
          the existing 2-byte pool of unallocated AS Numbers will be
          exhausted sometime in the period between 2010 and 2016, absent
          of any concerted efforts of recovery of already-allocated AS
          Numbers [1] [2]. Standardization work in the IETF has produced
          a document that is currently being submitted as a Proposed
          Standard that will expand the AS Number space to a 4-byte
          field [3].

          It is noted that some advance period may be required by
          network operators to undertake the appropriate procedures
          relating to support of 4-byte AS numbers, and while no flag
          day is required in the transition to the longer AS Number
          field, it is recognised that a prudent course of action is to
          allow for allocation of these extended AS numbers well in
          advance of an anticipated 2-byte AS Number exhaustion date.

          This policy proposal details a set of actions and associated
          dates for RIR AS Number allocation policies to assist in an
          orderly transition to use of the 4-byte AS Number space.

          The essential attributes of this policy proposal are to
          facilitate the ease of transitional arrangements by equipment
          vendors, network managers and network operations staff, to
          provide the industry with some predictability in terms of
          dates and associated actions with respect to registry
          operational procedures for AS Number allocations.

          References

          [1]  Daily AS Number Report,
               http://www.potaroo.net/tools/asns
          [2]  ASNs MIA: A Comparision of RIR Statistics and RIS
               Reality, http://www.nanog.org/mtg-0510/wilhelm.html
          [3]  BGP Support for Four-octet AS Number Space,
               draft-ietf-idr-as4bytes-12.txt

Timetable for implementation:

	Procedures to support this proposal need to be implemented
	by 1 January 2007



From gih at apnic.net  Mon Dec 19 19:37:17 2005
From: gih at apnic.net (Geoff Huston)
Date: Tue, 20 Dec 2005 11:37:17 +1100
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <43A73A1B.1000102@arin.net>
References: <43A73A1B.1000102@arin.net>
Message-ID: <6.2.0.14.2.20051220113527.02dfad00@kahuna.telstra.net>

Discussion to date on the pml mailing list has highlighted the potential 
ambiguity in the nomenclature section, specifically with the use of the 
colon (':') separator character, and a period ('.') has been proposed instead.

regards,

   Geoff


At 09:54 AM 20/12/2005, Member Services wrote:
>On December 15, 2005, the ARIN Advisory Council concluded its review of
>proposed policy 4-Byte AS Number Policy Proposal and agreed to forward
>it as a formal proposal for discussion by the community. This proposal
>is designated Policy Proposal 2005-9: 4-Byte AS Number. The policy
>proposal text is below and can be found at:
>
>http://www.arin.net/policy/proposals/2005_9.html
>
>All persons in the community are encouraged to discuss Policy Proposal
>2005-9 in the weeks leading to the ARIN Public Policy Meeting in
>Montreal scheduled for April 10-11, 2006. Both the discussion on the
>Public Policy Mailing List and at the public policy meeting will be used
>to determine the community consensus regarding this policy proposal.
>
>The ARIN Internet Resource Policy Evaluation Process can be found at:
>http://www.arin.net/policy/irpep.html
>
>ARIN's Policy Proposal Archive can be found at:
>http://www.arin.net/policy/proposals/proposal_archive.html
>
>Regards,
>
>Member Services
>American Registry for Internet Numbers (ARIN)
>
>
>### * ###
>
>
>Policy Proposal Name: 4-Byte AS Number
>
>Author: Geoff Huston
>
>Policy Term: Temporary (1 January 2007 - 1 January 2010)
>
>Policy Statement:
>
>           This policy proposal nominates 3 dates for changes to the
>           current AS Number allocation policy for the registry:
>
>           On 1 January 2007 the registry will process applications that
>           specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.
>
>           On 1 January 2009 the registry will process applications that
>           specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.
>
>           On 1 January 2010 the registry will cease to make any
>           distinction between 2-byte only AS Numbers and 4-byte only AS
>           Numbers, and will operate AS number allocations from an
>           undifferentiated 4-byte AS Number allocation pool.
>
>           Nomenclature
>
>           It is proposed to identify 4-byte AS Numbers using a syntax of
>           <high order 16 bit value in decimal>:<low order 16 bit value
>           in decimal>. Accordingly, a 4-byte AS number of value 65546
>           (decimal) would be identified as "1:10".
>
>           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)
>
>Rationale:
>
>           Recent studies of AS number consumption rates indicate that
>           the existing 2-byte pool of unallocated AS Numbers will be
>           exhausted sometime in the period between 2010 and 2016, absent
>           of any concerted efforts of recovery of already-allocated AS
>           Numbers [1] [2]. Standardization work in the IETF has produced
>           a document that is currently being submitted as a Proposed
>           Standard that will expand the AS Number space to a 4-byte
>           field [3].
>
>           It is noted that some advance period may be required by
>           network operators to undertake the appropriate procedures
>           relating to support of 4-byte AS numbers, and while no flag
>           day is required in the transition to the longer AS Number
>           field, it is recognised that a prudent course of action is to
>           allow for allocation of these extended AS numbers well in
>           advance of an anticipated 2-byte AS Number exhaustion date.
>
>           This policy proposal details a set of actions and associated
>           dates for RIR AS Number allocation policies to assist in an
>           orderly transition to use of the 4-byte AS Number space.
>
>           The essential attributes of this policy proposal are to
>           facilitate the ease of transitional arrangements by equipment
>           vendors, network managers and network operations staff, to
>           provide the industry with some predictability in terms of
>           dates and associated actions with respect to registry
>           operational procedures for AS Number allocations.
>
>           References
>
>           [1]  Daily AS Number Report,
>                http://www.potaroo.net/tools/asns
>           [2]  ASNs MIA: A Comparision of RIR Statistics and RIS
>                Reality, http://www.nanog.org/mtg-0510/wilhelm.html
>           [3]  BGP Support for Four-octet AS Number Space,
>                draft-ietf-idr-as4bytes-12.txt
>
>Timetable for implementation:
>
>         Procedures to support this proposal need to be implemented
>         by 1 January 2007
>
>_______________________________________________
>PPML mailing list
>PPML at arin.net
>http://lists.arin.net/mailman/listinfo/ppml




From sleibrand at internap.com  Mon Dec 19 20:41:14 2005
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 19 Dec 2005 20:41:14 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <6.2.0.14.2.20051220113527.02dfad00@kahuna.telstra.net>
References: <43A73A1B.1000102@arin.net>
	<6.2.0.14.2.20051220113527.02dfad00@kahuna.telstra.net>
Message-ID: <Pine.LNX.4.58.0512192038040.5719@sleibrand.acs.internap.com>

To reiterate for the record now that this is a formal policy proposal, I
would agree with the apparent ppml consensus that the colon separator
should be changed to a period to avoid confusion with the nomenclature
used by BGP communities.  With that change, I agree this is a very
sensible and necessary policy proposal that I would support.

-Scott

On 12/20/05 at 11:37am +1100, Geoff Huston <gih at apnic.net> wrote:

> Discussion to date on the pml mailing list has highlighted the potential
> ambiguity in the nomenclature section, specifically with the use of the
> colon (':') separator character, and a period ('.') has been proposed instead.
>
> regards,
>
>    Geoff
>
>
> At 09:54 AM 20/12/2005, Member Services wrote:
> >On December 15, 2005, the ARIN Advisory Council concluded its review of
> >proposed policy 4-Byte AS Number Policy Proposal and agreed to forward
> >it as a formal proposal for discussion by the community. This proposal
> >is designated Policy Proposal 2005-9: 4-Byte AS Number. The policy
> >proposal text is below and can be found at:
> >
> >http://www.arin.net/policy/proposals/2005_9.html
> >
> >All persons in the community are encouraged to discuss Policy Proposal
> >2005-9 in the weeks leading to the ARIN Public Policy Meeting in
> >Montreal scheduled for April 10-11, 2006. Both the discussion on the
> >Public Policy Mailing List and at the public policy meeting will be used
> >to determine the community consensus regarding this policy proposal.
> >
> >The ARIN Internet Resource Policy Evaluation Process can be found at:
> >http://www.arin.net/policy/irpep.html
> >
> >ARIN's Policy Proposal Archive can be found at:
> >http://www.arin.net/policy/proposals/proposal_archive.html
> >
> >Regards,
> >
> >Member Services
> >American Registry for Internet Numbers (ARIN)
> >
> >
> >### * ###
> >
> >
> >Policy Proposal Name: 4-Byte AS Number
> >
> >Author: Geoff Huston
> >
> >Policy Term: Temporary (1 January 2007 - 1 January 2010)
> >
> >Policy Statement:
> >
> >           This policy proposal nominates 3 dates for changes to the
> >           current AS Number allocation policy for the registry:
> >
> >           On 1 January 2007 the registry will process applications that
> >           specifically request 4-byte only AS Numbers and allocate 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 allocated by the registry.
> >
> >           On 1 January 2009 the registry will process applications that
> >           specifically request 2-byte only AS Numbers and allocate 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 allocated by the registry.
> >
> >           On 1 January 2010 the registry will cease to make any
> >           distinction between 2-byte only AS Numbers and 4-byte only AS
> >           Numbers, and will operate AS number allocations from an
> >           undifferentiated 4-byte AS Number allocation pool.
> >
> >           Nomenclature
> >
> >           It is proposed to identify 4-byte AS Numbers using a syntax of
> >           <high order 16 bit value in decimal>:<low order 16 bit value
> >           in decimal>. Accordingly, a 4-byte AS number of value 65546
> >           (decimal) would be identified as "1:10".
> >
> >           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)
> >
> >Rationale:
> >
> >           Recent studies of AS number consumption rates indicate that
> >           the existing 2-byte pool of unallocated AS Numbers will be
> >           exhausted sometime in the period between 2010 and 2016, absent
> >           of any concerted efforts of recovery of already-allocated AS
> >           Numbers [1] [2]. Standardization work in the IETF has produced
> >           a document that is currently being submitted as a Proposed
> >           Standard that will expand the AS Number space to a 4-byte
> >           field [3].
> >
> >           It is noted that some advance period may be required by
> >           network operators to undertake the appropriate procedures
> >           relating to support of 4-byte AS numbers, and while no flag
> >           day is required in the transition to the longer AS Number
> >           field, it is recognised that a prudent course of action is to
> >           allow for allocation of these extended AS numbers well in
> >           advance of an anticipated 2-byte AS Number exhaustion date.
> >
> >           This policy proposal details a set of actions and associated
> >           dates for RIR AS Number allocation policies to assist in an
> >           orderly transition to use of the 4-byte AS Number space.
> >
> >           The essential attributes of this policy proposal are to
> >           facilitate the ease of transitional arrangements by equipment
> >           vendors, network managers and network operations staff, to
> >           provide the industry with some predictability in terms of
> >           dates and associated actions with respect to registry
> >           operational procedures for AS Number allocations.
> >
> >           References
> >
> >           [1]  Daily AS Number Report,
> >                http://www.potaroo.net/tools/asns
> >           [2]  ASNs MIA: A Comparision of RIR Statistics and RIS
> >                Reality, http://www.nanog.org/mtg-0510/wilhelm.html
> >           [3]  BGP Support for Four-octet AS Number Space,
> >                draft-ietf-idr-as4bytes-12.txt
> >
> >Timetable for implementation:
> >
> >         Procedures to support this proposal need to be implemented
> >         by 1 January 2007
> >
> >_______________________________________________
> >PPML mailing list
> >PPML at arin.net
> >http://lists.arin.net/mailman/listinfo/ppml
>
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>


From Michael.Dillon at btradianz.com  Tue Dec 20 06:59:24 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Tue, 20 Dec 2005 11:59:24 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <Pine.LNX.4.58.0512192038040.5719@sleibrand.acs.internap.com>
Message-ID: <OFADD9E6FB.6D54B832-ON802570DD.0041367A-802570DD.0041DB92@btradianz.com>

>To reiterate for the record now that this is a formal policy proposal, I
> would agree with the apparent ppml consensus 

Consensus?

>that the colon separator
> should be changed to a period to avoid confusion with the nomenclature
> used by BGP communities. 

Several people pointed out that there is no need
for any special separator since the decimal number system
in common use already allows for representing numbers 
greater than 65535. In other words, there was not any
CONSENSUS about sticking spurious punctuation marks
into AS numbers.

Is the number 0.63535 a valid AS number?
What about 0.65553?

When the dot notation was introduced for IP addresses,
they marked an important bit boundary that was a fundamental
part of the IP address. The 32 bit identifier was divided
into a NETWORK portion and a HOST portion. This division
was done on one of three 8-bit boundaries depending on
address class and therefore there are 3 dots in an IP 
address marking the boundaries.

AS numbers are simple integers with no such internal
structure.

--Michael Dillon



From owen at delong.com  Tue Dec 20 08:14:25 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Dec 2005 05:14:25 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <OFADD9E6FB.6D54B832-ON802570DD.0041367A-802570DD.0041DB92@btradianz.com>
References: <OFADD9E6FB.6D54B832-ON802570DD.0041367A-802570DD.0041DB92@btrad
	ianz.com>
Message-ID: <782F637C9D0D764430340298@odpwrbook.hq.netli.lan>



--On December 20, 2005 11:59:24 AM +0000 Michael.Dillon at btradianz.com wrote:

>> To reiterate for the record now that this is a formal policy proposal, I
>> would agree with the apparent ppml consensus
>
> Consensus?
>
>> that the colon separator
>> should be changed to a period to avoid confusion with the nomenclature
>> used by BGP communities.
>
> Several people pointed out that there is no need
> for any special separator since the decimal number system
> in common use already allows for representing numbers
> greater than 65535. In other words, there was not any
> CONSENSUS about sticking spurious punctuation marks
> into AS numbers.
>

While it is true that there were a few comments of this nature, the vast
majority of respondents who commented on this did seem to favor the use
of the decimal and segmenting the AS number into 16 bit chunks for
human readability.  I know you don't agree, but, I think there was a
strong enough majority to call it consensus.

> Is the number 0.63535 a valid AS number?

yes

> What about 0.65553?

I would say that it is equally valid to 0.0.0.384 as an IP address.

Technically, I suppose, an argument could be made that it is valid, but,
I doubt most parsers would treat it the way you would expect.

> When the dot notation was introduced for IP addresses,
> they marked an important bit boundary that was a fundamental
> part of the IP address. The 32 bit identifier was divided
> into a NETWORK portion and a HOST portion. This division

However, there's three dots and only one boundary for any given
address.  I don't know whether you'll accept this or not, but,
I do believe that a portion of the thinking of using dotted quads
was to make IP addresses more human-readable and reduce human
audio transmission/reception errors.

> was done on one of three 8-bit boundaries depending on
> address class and therefore there are 3 dots in an IP
> address marking the boundaries.
>
I'll also point out that dotted quad did not go away with the
advent of CIDR and that there was no dot to mark the difference
between unicast and multicast space or multicast and experimental
E/F/G/... space.  The dots remain today because they are useful
for human readability.

> AS numbers are simple integers with no such internal
> structure.
>
IP addresses today are simple integers as well.  You can either say they 
have
no such internal structure, or, you can say that the internal structure is 
no
longer related to octet boundaries.  Either way, the position of the dots
in IP addresses is no longer related to that structure, but, the dots have
not moved or been abandoned.

When was the last time you saw someone write an address within a /16 as
141.32892?  (sure, it's a legal representation, but, nobody writes IP
addresses that way).

There are a lot of parallels between ASNs and Postal Codes.  I would expect
that when ICANN/IANA starts issuing 32 bit ASNs, they will likely issue
16bit blocks to RIRs who will then allocate individual ASNs from them.
As such, it might be useful to have A.B format notation where A can be
related back to:
	A=0	=	Original ASN swamp, non RIR specific
	A>0	=	Specific RIR to which that chunk was assigned

Of course, if that happens, then, while not technically structure within the
ASN, it does mean the bits have somewhat separate meaning.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051220/b26e8b71/attachment.sig>

From billd at cait.wustl.edu  Tue Dec 20 09:17:05 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Tue, 20 Dec 2005 08:17:05 -0600
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
Message-ID: <CC5444841A969F4CBBF6A305E569F00803005A@kronos.cait.wustl.edu>

That is what this forum is for or course to get feedback IN ADVANCE of
assessing consensus on this forum and at the next regularly schedule Public
Policy meeting.

I might add related to your remarks below...that dots appear within network
identifiers today and do serve as a fundamental service to
intelligibility...  128.252.53.46 /16 for instance... and since two 16 bit
AS entities are being stuck together or the original 16 bits is be appended
by another 16 (if you prefer)...the dot serves the same purpose and doesn't
fundamentally alter its definition in its format....

According to Wikipedia...
A unique AS number (or ASN) is allocated to each AS for use in BGP routing.
With BGP, AS numbers are important because the ASN uniquely identifies each
network on the internet.  AS numbers are assigned by the IANA, which also
allocate IP addresses, to regional internet registries (RIRs) in blocks. The
local RIR then assigns an AS number to an entity from the block assigned by
the IANA. Entities wishing to receive an ASN must complete the application
process of their local RIR and be approved before being assigned an ASN.

Note that they refer to an IP address as an entity...which is of course
subdivided into dotted decimal for convenience and they refer to AS numbers
as an entity which could be dotted decimal as well..... what difference
then?


bd


> When the dot notation was introduced for IP addresses,
> they marked an important bit boundary that was a fundamental 
> part of the IP address. The 32 bit identifier was divided 
> into a NETWORK portion and a HOST portion. This division was 
> done on one of three 8-bit boundaries depending on address 
> class and therefore there are 3 dots in an IP 
> address marking the boundaries.
> 
> AS numbers are simple integers with no such internal
> structure.
> 
> --Michael Dillon
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From Michael.Dillon at btradianz.com  Tue Dec 20 09:30:34 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Tue, 20 Dec 2005 14:30:34 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <782F637C9D0D764430340298@odpwrbook.hq.netli.lan>
Message-ID: <OFFA507CCD.247EE6A9-ON802570DD.004D5024-802570DD.004FB240@btradianz.com>

> While it is true that there were a few comments of this nature, the vast
> majority of respondents who commented on this did seem to favor the use
> of the decimal and segmenting the AS number into 16 bit chunks for
> human readability.  I know you don't agree, but, I think there was a
> strong enough majority to call it consensus.

Why must you butcher the English language in this way?
Consensus is not the same as majority. In fact, I went
to Google and looked for "consenus majority". The first
result has this sentence in section 5 of the intro:

   So far, unanimity or consensus has been contrasted 
   with majority decisions

Read this if you are interested.
http://www.arena.uio.no/publications/working-papers1998/papers/wp98_10.htm

If someone would take the trouble to count the positions
in the emails, I think they would find that there is no
"vast majority" since there is not even a "vast" number
of people commenting. In addition, a number of people 
speaking in favor of the dot were doing so to get rid
of the ambiguity of the colon notation. 

This is an entirely separate question from the question
of introducing a special notation in the first place.
It's not a simple binary partition of positions and 
I don't believe the discussion demonstrated any significant
support for any of the positions discussed. The discussion
raised serious questions:

   Should there be a special notation for AS numbers
   greater than 65535?

   Should a dot be preferred to a colon in such a 
   special notation?

However, the discussion did not decide the answers to
these questions.

> > Is the number 0.63535 a valid AS number?
> 
> yes

How can you tell?

> > What about 0.65553?
> 
> I would say that it is equally valid to 0.0.0.384 as an IP address.

Huh? Everyone knows that is not a valid IP address 
because each segment is an 8 bit number which cannot
be greater than 255.

> Technically, I suppose, an argument could be made that it is valid, but,
> I doubt most parsers would treat it the way you would expect.

The point is that big numbers, such as the maximum unsigned
representation of 16 bits, are not terribly intuitive, not
as easy for people to remember and understand as 256, and not
as easy to figure out when the question is put to you about the 
validity of a number. People can understand 256 possibilities 
because you can almost visualize them and millions of people 
have seen illustrations of tables of 256 eight-bit character
codes. The same cannot be said for 16 bit codes. In addition,
millions of people know that the maximum 16 bit integer is 
32,767 but that is not the same as the maximum 16 bit positive
number used in the definition of an AS number.

> > When the dot notation was introduced for IP addresses,
> > they marked an important bit boundary that was a fundamental
> > part of the IP address. The 32 bit identifier was divided
> > into a NETWORK portion and a HOST portion. This division
> 
> However, there's three dots and only one boundary for any given
> address.  I don't know whether you'll accept this or not, but,
> I do believe that a portion of the thinking of using dotted quads
> was to make IP addresses more human-readable and reduce human
> audio transmission/reception errors.

That was at a time before the existence of text messages
and email and IM and ...

> I'll also point out that dotted quad did not go away with the
> advent of CIDR

That's not the point. The point is that it CAME IN for
a good reason related to the structure of IP addresses 
and there use in subnet and host addressing. There is
no structural and usage related reason to INTRODUCE a
new AS number notation superceding the old one.

> IP addresses today are simple integers as well.

Not so. That's why we have slash notation. There is
still an important distinction between network and
host addresses even though CIDR allows for more variation
in network sizes.

>  Either way, the position of the dots
> in IP addresses is no longer related to that structure, but, the dots 
have
> not moved or been abandoned.

Exactly! When IPv4 subnetting was changed by CIDR, we
stayed with the convention of representing IPv4 address 
as they always had been. That's why I believe we should
also STICK WITH THE CONVENTION of representing AS numbers
as simple decimal integers with optional prefixes like
AS or ASN.

There is no need to change things at all.

There is no need to write AS number 65536 as AS 65536 and AS 1.0
There is no need to explain to people that 1.324 is not actually
a real number but it is a 32 bit integer.

--Michael Dillon



From Lee.Howard at stanleyassociates.com  Tue Dec 20 11:07:42 2005
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Tue, 20 Dec 2005 11:07:42 -0500
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4E1DD69@CL-S-EX-1.stanleyassociates.com>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Bill Darte
> Sent: Tuesday, December 20, 2005 9:17 AM
> To: 'Michael.Dillon at btradianz.com'; ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
> 
> According to Wikipedia...
> A unique AS number (or ASN) is allocated to each AS for use 
> in BGP routing.
> With BGP, AS numbers are important because the ASN uniquely 
> identifies each
> network on the internet.  AS numbers are assigned by the 
> IANA, which also
> allocate IP addresses, to regional internet registries (RIRs) 
> in blocks. The
> local RIR then assigns an AS number to an entity from the 
> block assigned by
> the IANA. Entities wishing to receive an ASN must complete 
> the application
> process of their local RIR and be approved before being 
> assigned an ASN.
> 
> Note that they refer to an IP address as an entity...

Er, I read "entities" as meaning "persons or organizations,"
i.e., the one who fills out the ASN application.  An ASN is
assigned to a person or organization, not to an IP address.

An IP address is an entity in the same sense that {5} is an
entity.

Lee

> 
> 
> bd
> 
> 
> > When the dot notation was introduced for IP addresses,
> > they marked an important bit boundary that was a fundamental 
> > part of the IP address. The 32 bit identifier was divided 
> > into a NETWORK portion and a HOST portion. This division was 
> > done on one of three 8-bit boundaries depending on address 
> > class and therefore there are 3 dots in an IP 
> > address marking the boundaries.
> > 
> > AS numbers are simple integers with no such internal
> > structure.
> > 
> > --Michael Dillon
> > 
> > _______________________________________________
> > PPML mailing list
> > PPML at arin.net
> > http://lists.arin.net/mailman/listinfo/ppml
> > 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


From owen at delong.com  Tue Dec 20 18:28:36 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Dec 2005 15:28:36 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <OFFA507CCD.247EE6A9-ON802570DD.004D5024-802570DD.004FB240@btradianz.com>
References: <OFFA507CCD.247EE6A9-ON802570DD.004D5024-802570DD.004FB240@btrad
	ianz.com>
Message-ID: <82B5C6894C2BD8AEC8697A8A@imac-en0.delong.sj.ca.us>

> This is an entirely separate question from the question
> of introducing a special notation in the first place.
> It's not a simple binary partition of positions and 
> I don't believe the discussion demonstrated any significant
> support for any of the positions discussed. The discussion
> raised serious questions:
> 
>    Should there be a special notation for AS numbers
>    greater than 65535?
> 
No.  However, once we start using 32 bit AS numbers, having a divided
notation for them is desirable as an adjunct to human readability.
Thus, I favor the future notation of existing AS numbers as 0.ASN
and AS numbers in excess of 65535 as A.B where A=int(ASN/65536)
and B=ASN mod 65536.

>    Should a dot be preferred to a colon in such a 
>    special notation?
> 
Absolutely.  Colons are ambiguous with current use of community notation.

> However, the discussion did not decide the answers to
> these questions.
> 
OK, well... I guess there will be more discussion on this.  You now have
my votes on these two questions.

>> > Is the number 0.63535 a valid AS number?
>> 
>> yes
> 
> How can you tell?
> 
What do you mean?

0.63535 is the 32 bit representation of what is currently 63535.
There is no difference between 0.63535 and 63535.

>> > What about 0.65553?
>> 
>> I would say that it is equally valid to 0.0.0.384 as an IP address.
> 
> Huh? Everyone knows that is not a valid IP address 
> because each segment is an 8 bit number which cannot
> be greater than 255.
> 
Exactly.

>> Technically, I suppose, an argument could be made that it is valid, but,
>> I doubt most parsers would treat it the way you would expect.
> 
> The point is that big numbers, such as the maximum unsigned
> representation of 16 bits, are not terribly intuitive, not
> as easy for people to remember and understand as 256, and not
> as easy to figure out when the question is put to you about the 
> validity of a number. People can understand 256 possibilities 
> because you can almost visualize them and millions of people 
> have seen illustrations of tables of 256 eight-bit character
> codes. The same cannot be said for 16 bit codes. In addition,
> millions of people know that the maximum 16 bit integer is 
> 32,767 but that is not the same as the maximum 16 bit positive
> number used in the definition of an AS number.
> 
I'm betting most of the people who know that 32767 is the maximum
16 bit integer are well aware that 65535 is the maximum unsigned
16 bit integer.

>> However, there's three dots and only one boundary for any given
>> address.  I don't know whether you'll accept this or not, but,
>> I do believe that a portion of the thinking of using dotted quads
>> was to make IP addresses more human-readable and reduce human
>> audio transmission/reception errors.
> 
> That was at a time before the existence of text messages
> and email and IM and ...
> 
What's your point?  As someone who works in an actual NOC, I can
guarantee you that IP addresses and ASNs are still exchanged
in telephone conversations on a regular basis today.

>> I'll also point out that dotted quad did not go away with the
>> advent of CIDR
> 
> That's not the point. The point is that it CAME IN for
> a good reason related to the structure of IP addresses 
> and there use in subnet and host addressing. There is
> no structural and usage related reason to INTRODUCE a
> new AS number notation superceding the old one.
> 
I guess we'll have to agree to disagree on this.  I think that
the readability issue is a good reason.

>> IP addresses today are simple integers as well.
> 
> Not so. That's why we have slash notation. There is
> still an important distinction between network and
> host addresses even though CIDR allows for more variation
> in network sizes.
> 
Please explain the purpose of the dots in IP addresses as
it relates to this?  Please explain the purpose of the :s
separating 16 bit chunks in IPv6 addresses as it relates
to this.  It just doesn't fit.

>>  Either way, the position of the dots
>> in IP addresses is no longer related to that structure, but, the dots 
> have
>> not moved or been abandoned.
> 
> Exactly! When IPv4 subnetting was changed by CIDR, we
> stayed with the convention of representing IPv4 address 
> as they always had been. That's why I believe we should
> also STICK WITH THE CONVENTION of representing AS numbers
> as simple decimal integers with optional prefixes like
> AS or ASN.
> 
> There is no need to change things at all.
> 
I suppose that when the US went from phone numbers like BR549 to
NPA-NXX-SUFX, you would have preferred to continue representing
those phone numbers as two letters followed by a larger string of
numbers.  

> There is no need to write AS number 65536 as AS 65536 and AS 1.0
> There is no need to explain to people that 1.324 is not actually
> a real number but it is a 32 bit integer.
> 
Need is an interesting term.  However, I would argue that there is
also no need to make people look at ASNs like AS129391243 and that
it is much better to, instead, represent that as AS1974.23179.

Just as I prefer +1.408.555.1212 to 14085551212 and prefer
95121-1520 to 951211520 and 123-45-6789 to 123456789[1].  Sure,
there is some structural significance in each of these cases,
but, said structure is not important to most common usages of
those data.  Instead, it is primarily there to improve
readability.

Owen

[1] These numbers are, respectively, NANP (North America) Telephon Number,
united States Postal code, United States Social Security Number.

--
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051220/6ca5b167/attachment.sig>

From bmanning at vacation.karoshi.com  Tue Dec 20 18:48:39 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 20 Dec 2005 23:48:39 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <82B5C6894C2BD8AEC8697A8A@imac-en0.delong.sj.ca.us>
References: <OFFA507CCD.247EE6A9-ON802570DD.004D5024-802570DD.004FB240@btradianz.com>
	<82B5C6894C2BD8AEC8697A8A@imac-en0.delong.sj.ca.us>
Message-ID: <20051220234839.GA8111@vacation.karoshi.com.>

On Tue, Dec 20, 2005 at 03:28:36PM -0800, Owen DeLong wrote:
> > This is an entirely separate question from the question
> > of introducing a special notation in the first place.
> > It's not a simple binary partition of positions and 
> > I don't believe the discussion demonstrated any significant
> > support for any of the positions discussed. The discussion
> > raised serious questions:
> > 
> >    Should there be a special notation for AS numbers
> >    greater than 65535?
> > 
> No.  However, once we start using 32 bit AS numbers, having a divided
> notation for them is desirable as an adjunct to human readability.
> Thus, I favor the future notation of existing AS numbers as 0.ASN
> and AS numbers in excess of 65535 as A.B where A=int(ASN/65536)
> and B=ASN mod 65536.
> 
> >    Should a dot be preferred to a colon in such a 
> >    special notation?
> > 
> Absolutely.  Colons are ambiguous with current use of community notation.

	hum... human readability is the only factor here?
	i'd settle for a '-' or even '*' or... '#' ... perhaps 'x'
	would be a fine choice.

--bill

> 
> > However, the discussion did not decide the answers to
> > these questions.
> > 
> OK, well... I guess there will be more discussion on this.  You now have
> my votes on these two questions.
> 
> >> > Is the number 0.63535 a valid AS number?
> >> 
> >> yes
> > 
> > How can you tell?
> > 
> What do you mean?
> 
> 0.63535 is the 32 bit representation of what is currently 63535.
> There is no difference between 0.63535 and 63535.
> 
> >> > What about 0.65553?
> >> 
> >> I would say that it is equally valid to 0.0.0.384 as an IP address.
> > 
> > Huh? Everyone knows that is not a valid IP address 
> > because each segment is an 8 bit number which cannot
> > be greater than 255.
> > 
> Exactly.
> 
> >> Technically, I suppose, an argument could be made that it is valid, but,
> >> I doubt most parsers would treat it the way you would expect.
> > 
> > The point is that big numbers, such as the maximum unsigned
> > representation of 16 bits, are not terribly intuitive, not
> > as easy for people to remember and understand as 256, and not
> > as easy to figure out when the question is put to you about the 
> > validity of a number. People can understand 256 possibilities 
> > because you can almost visualize them and millions of people 
> > have seen illustrations of tables of 256 eight-bit character
> > codes. The same cannot be said for 16 bit codes. In addition,
> > millions of people know that the maximum 16 bit integer is 
> > 32,767 but that is not the same as the maximum 16 bit positive
> > number used in the definition of an AS number.
> > 
> I'm betting most of the people who know that 32767 is the maximum
> 16 bit integer are well aware that 65535 is the maximum unsigned
> 16 bit integer.
> 
> >> However, there's three dots and only one boundary for any given
> >> address.  I don't know whether you'll accept this or not, but,
> >> I do believe that a portion of the thinking of using dotted quads
> >> was to make IP addresses more human-readable and reduce human
> >> audio transmission/reception errors.
> > 
> > That was at a time before the existence of text messages
> > and email and IM and ...
> > 
> What's your point?  As someone who works in an actual NOC, I can
> guarantee you that IP addresses and ASNs are still exchanged
> in telephone conversations on a regular basis today.
> 
> >> I'll also point out that dotted quad did not go away with the
> >> advent of CIDR
> > 
> > That's not the point. The point is that it CAME IN for
> > a good reason related to the structure of IP addresses 
> > and there use in subnet and host addressing. There is
> > no structural and usage related reason to INTRODUCE a
> > new AS number notation superceding the old one.
> > 
> I guess we'll have to agree to disagree on this.  I think that
> the readability issue is a good reason.
> 
> >> IP addresses today are simple integers as well.
> > 
> > Not so. That's why we have slash notation. There is
> > still an important distinction between network and
> > host addresses even though CIDR allows for more variation
> > in network sizes.
> > 
> Please explain the purpose of the dots in IP addresses as
> it relates to this?  Please explain the purpose of the :s
> separating 16 bit chunks in IPv6 addresses as it relates
> to this.  It just doesn't fit.
> 
> >>  Either way, the position of the dots
> >> in IP addresses is no longer related to that structure, but, the dots 
> > have
> >> not moved or been abandoned.
> > 
> > Exactly! When IPv4 subnetting was changed by CIDR, we
> > stayed with the convention of representing IPv4 address 
> > as they always had been. That's why I believe we should
> > also STICK WITH THE CONVENTION of representing AS numbers
> > as simple decimal integers with optional prefixes like
> > AS or ASN.
> > 
> > There is no need to change things at all.
> > 
> I suppose that when the US went from phone numbers like BR549 to
> NPA-NXX-SUFX, you would have preferred to continue representing
> those phone numbers as two letters followed by a larger string of
> numbers.  
> 
> > There is no need to write AS number 65536 as AS 65536 and AS 1.0
> > There is no need to explain to people that 1.324 is not actually
> > a real number but it is a 32 bit integer.
> > 
> Need is an interesting term.  However, I would argue that there is
> also no need to make people look at ASNs like AS129391243 and that
> it is much better to, instead, represent that as AS1974.23179.
> 
> Just as I prefer +1.408.555.1212 to 14085551212 and prefer
> 95121-1520 to 951211520 and 123-45-6789 to 123456789[1].  Sure,
> there is some structural significance in each of these cases,
> but, said structure is not important to most common usages of
> those data.  Instead, it is primarily there to improve
> readability.
> 
> Owen
> 
> [1] These numbers are, respectively, NANP (North America) Telephon Number,
> united States Postal code, United States Social Security Number.
> 
> --
> If it wasn't crypto-signed, it probably didn't come from me.



> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



From bicknell at ufp.org  Tue Dec 20 21:46:40 2005
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 20 Dec 2005 21:46:40 -0500
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <6.2.0.14.2.20051220113527.02dfad00@kahuna.telstra.net>
References: <43A73A1B.1000102@arin.net>
	<6.2.0.14.2.20051220113527.02dfad00@kahuna.telstra.net>
Message-ID: <20051221024640.GA67045@ussenterprise.ufp.org>

In a message written on Tue, Dec 20, 2005 at 11:37:17AM +1100, Geoff Huston wrote:
> Discussion to date on the pml mailing list has highlighted the potential 
> ambiguity in the nomenclature section, specifically with the use of the 
> colon (':') separator character, and a period ('.') has been proposed instead.

I have to wonder why the choice of separator is an ARIN matter.  It
seems to me that there should be a global standard for what separator
is used, probably from the IETF or similar.  It would be rather
stupid if ARIN chose one separator and RIPE chose another.

In reality, whatever vendor has the first widely deployed 32 ASN
supporting image will probably determine what separator becomes the
most common.

So the question becomes, what separator has been proposed in the 32
bit ASN documentation in the IETF land?  However poor a choice was
made there, is there any defendable reason for ARIN to use something
different?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051220/1dc481d1/attachment.sig>

From william at elan.net  Tue Dec 20 22:05:59 2005
From: william at elan.net (william(at)elan.net)
Date: Tue, 20 Dec 2005 19:05:59 -0800 (PST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <20051220234839.GA8111@vacation.karoshi.com.>
References: <OFFA507CCD.247EE6A9-ON802570DD.004D5024-802570DD.004FB240@btradianz.com>
	<82B5C6894C2BD8AEC8697A8A@imac-en0.delong.sj.ca.us>
	<20051220234839.GA8111@vacation.karoshi.com.>
Message-ID: <Pine.LNX.4.62.0512201550370.23251@sokol.elan.net>


On Tue, 20 Dec 2005 bmanning at vacation.karoshi.com wrote:

>> Absolutely.  Colons are ambiguous with current use of community notation.
>
> 	hum... human readability is the only factor here?
> 	i'd settle for a '-' or even '*' or... '#' ... perhaps 'x'
> 	would be a fine choice.

We should minimize number of symbols used to describe network addresses
as both ip addresses and ASNs are used in the context where they need
to be separated as part of more complex data part.

Using "." or ":" makes sense because these are already in use for ip
and other addresses. It has also become a kind-of tradition that ":" 
separates parts of the numbers when they are written in hexadecimal 
where as "." separates when parts are written as decimal.

Also that we separate 32-bit number into several parts in writing does
not mean somebody else can not write and use the same number as full
32-bit [unsigned] integer. In fact as many of you probably know you can 
use use full 32-bit number as IPv4 address, for example just for fun
try "ping 3231054855" from your dos/unix prompt and then also try
"http://3231054855" at the browser and see where it gets you :)

---
William Leibzon
Elan Networks
william at elan.net


From drc at virtualized.org  Tue Dec 20 22:14:48 2005
From: drc at virtualized.org (David Conrad)
Date: Tue, 20 Dec 2005 19:14:48 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <20051220234839.GA8111@vacation.karoshi.com.>
References: <OFFA507CCD.247EE6A9-ON802570DD.004D5024-802570DD.004FB240@btradianz.com>
	<82B5C6894C2BD8AEC8697A8A@imac-en0.delong.sj.ca.us>
	<20051220234839.GA8111@vacation.karoshi.com.>
Message-ID: <F1422F02-1F93-47B6-B9B9-90DC096C87FF@virtualized.org>

Hi,

Speaking only for myself, it isn't clear to me that presentation  
layer stuff is a policy issue.  Perhaps the right answer would be to  
remove references to presentation layer separators and let the whois  
client software writers deal with it?

Rgds,
-drc
--------
My opinions are my own and do not necessarily represent the
opinion of any organization I may be a part of. So there.

On Dec 20, 2005, at 3:48 PM, bmanning at vacation.karoshi.com wrote:
> On Tue, Dec 20, 2005 at 03:28:36PM -0800, Owen DeLong wrote:
>>>    Should a dot be preferred to a colon in such a
>>>    special notation?
>> Absolutely.  Colons are ambiguous with current use of community  
>> notation.
> 	hum... human readability is the only factor here?
> 	i'd settle for a '-' or even '*' or... '#' ... perhaps 'x'
> 	would be a fine choice.



From billd at cait.wustl.edu  Wed Dec 21 00:05:43 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Tue, 20 Dec 2005 23:05:43 -0600
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
Message-ID: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>

William,
Your post below is excellent....thanks.


Using "." or ":" makes sense because these are already in use for ip
and other addresses. It has also become a kind-of tradition that ":" 
separates parts of the numbers when they are written in hexadecimal 
where as "." separates when parts are written as decimal.

Also that we separate 32-bit number into several parts in writing does
not mean somebody else can not write and use the same number as full
32-bit [unsigned] integer. In fact as many of you probably know you can 
use use full 32-bit number as IPv4 address, for example just for fun
try "ping 3231054855" from your dos/unix prompt and then also try
"http://3231054855" at the browser and see where it gets you :)



---
William Leibzon
Elan Networks
william at elan.net
_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml


From tme at multicasttech.com  Wed Dec 21 07:42:10 2005
From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 21 Dec 2005 07:42:10 -0500
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
Message-ID: <46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>

Hello;

Here is my take on things

1.) I support 2005-9 with the exception of the "Nomenclature"  
section, and I have  a suggestion for the text.

2.) I think that much of the nomenclature discussion is pretty silly,  
including some of mine. Unless someone comes up with a scheme to  
really burn through them, I would  predict that we would not need to  
use more than 6 digits for ASN's a few decades to come (I estimate  
about 20 years).

- We can live with expressing 5 digit ASN's as simple decimal  
numbers. The existence proof for that is that we do.
I see no reason to worry about adding a digit to that, and I can  
certainly live with 6 digit decimal numbers.

- If someone does come up with a scheme to burn through lots more  
ASN, I predict that will involve applying
some sort of structure or aggregation or overlay to ASN numbers, and  
that will likely impose its own numbering convention. In that case,  
anything we do now will likely be superseded.

- If people years from now feel that they need more order to ASN  
numbers, there is nothing stopping them from doing it.

- So, my vote is for simple decimal numbers to describe ASN. This is  
a preference, not a MUST. If this
comes up at the meeting  with the current nomenclature, I would  
support it.

3.) 2005-9 says nothing about whether or not people requesting 4 byte  
ASN can request specific 4 byte
ASN. I think that the current sequential assignment should continue.  
The text

On 1 January 2007 the registry will process applications that  
specifically request 4-byte only AS Numbers and allocate 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  
allocated by the registry.

is ambiguous. I predict that if specific numbers CAN be requested,  
they WILL be and a land rush will ensue.
(I want ASN 1,000,000 or ASN  1.11111, depending on  the nomenclature  
adopted.) So, I would add

In accordance with current policy, applications will only be able to  
request AS Numbers that require 4 bytes to express, not specific AS  
Numbers.

Regards
Marshall Eubanks


On Dec 21, 2005, at 12:05 AM, Bill Darte wrote:

> William,
> Your post below is excellent....thanks.
>
>
> Using "." or ":" makes sense because these are already in use for ip
> and other addresses. It has also become a kind-of tradition that ":"
> separates parts of the numbers when they are written in hexadecimal
> where as "." separates when parts are written as decimal.
>
> Also that we separate 32-bit number into several parts in writing does
> not mean somebody else can not write and use the same number as full
> 32-bit [unsigned] integer. In fact as many of you probably know you  
> can
> use use full 32-bit number as IPv4 address, for example just for fun
> try "ping 3231054855" from your dos/unix prompt and then also try
> "http://3231054855" at the browser and see where it gets you :)
>
>
>
> ---
> William Leibzon
> Elan Networks
> william at elan.net
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



From jeroen at unfix.org  Wed Dec 21 08:07:43 2005
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 21 Dec 2005 14:07:43 +0100
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
Message-ID: <43A9539F.5060005@unfix.org>

Marshall Eubanks wrote:
[..]
> 2.) I think that much of the nomenclature discussion is pretty silly,  
> including some of mine. Unless someone comes up with a scheme to  
> really burn through them, I would  predict that we would not need to  
> use more than 6 digits for ASN's a few decades to come (I estimate  
> about 20 years).

The 'burn through' is very easy. IANA can allocate a block of 65k ASN's
to each RIR. RIR's won't have to bother IANA then and it makes it easy
for whois-like tools to find the RIR in question.

As for the separator, I am for the use of '.', thus:
 * 8298   = 2 byte ASN
 * 0.8298 = 4 byte ASN (2 byte space)
 * 1.8298 = 4 byte ASN (RIR X space)
 * 2.8298 = 4 byte ASN (RIR Y space)
etc.

But that also depends on decisions by IANA and if they want to be so
nice in giving out such large blocks. Their IPv6 policy seems to have
changed finally though.

[..]
> 3.) 2005-9 says nothing about whether or not people requesting 4 byte  
> ASN can request specific 4 byte
> ASN. I think that the current sequential assignment should continue.  
> The text
[..]
> In accordance with current policy, applications will only be able to  
> request AS Numbers that require 4 bytes to express, not specific AS  
> Numbers.

IMHO This is a very valid point and should really be considered to be
incorporated into the policy.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051221/4760ed16/attachment.sig>

From rich at nic.umass.edu  Wed Dec 21 10:44:30 2005
From: rich at nic.umass.edu (Rich Emmings)
Date: Wed, 21 Dec 2005 10:44:30 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
Message-ID: <Pine.GSO.4.63.0512211029540.7946@troy>

I'm in concurrance with this:

On Wed, 21 Dec 2005, Marshall Eubanks wrote:

> - We can live with expressing 5 digit ASN's as simple decimal
> numbers. The existence proof for that is that we do.
> I see no reason to worry about adding a digit to that, and I can
> certainly live with 6 digit decimal numbers.
>

IP addresses in aggregate express a hierarchy.  AS numbers do not.

2 byte ASN's 0 - 65535 unsigned, and 4 byte are 65536-4294967295.  ASN 
1,000,000 would mean the AS space has grown an additional ~15 times the 
existing space.

Most of us can deal with with 7 digit phone numbers.  I leave it to someone 
else to figure out the burn rate of ASN's but it'll probably take double 
digit years to reach 100,000, least of all > 7 digit ASNs.

The router shouldn't have a problem figuring this out either, when it can 
support 32 bits in the ASN bucket, it can just zero the field and stuff the 
ASN in there, and it doesn't matter if it's 16 or 32 bits.

KISS applies here.


From owen at delong.com  Wed Dec 21 15:09:25 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 21 Dec 2005 12:09:25 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <Pine.GSO.4.63.0512211029540.7946@troy>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<Pine.GSO.4.63.0512211029540.7946@troy>
Message-ID: <D55C686C00F281098ACDD52F@imac-en0.delong.sj.ca.us>


> 
> IP addresses in aggregate express a hierarchy.  AS numbers do not.
> 
Or at least do not yet.

> 2 byte ASN's 0 - 65535 unsigned, and 4 byte are 65536-4294967295.  ASN 
> 1,000,000 would mean the AS space has grown an additional ~15 times the 
> existing space.
> 
Not quite.  16 bit ASNs are 0-65535 unsigned.  32 bit ASNs are 0-4294967295
also unsigned.  32 bit ASNs which overlap the same integer space as the
16 bit ASNs are equivalent and all 32 bit ASN software is required to
support 16 bit representations thereof.

> Most of us can deal with with 7 digit phone numbers.  I leave it to
> someone  else to figure out the burn rate of ASN's but it'll probably
> take double  digit years to reach 100,000, least of all > 7 digit ASNs.
> 
How many 7 digit phone numbers have you seen without separators?
Most I've seen are either XX-XX-XXX or XXX-XXXX.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051221/0d1e8695/attachment.sig>

From rich at nic.umass.edu  Wed Dec 21 15:21:34 2005
From: rich at nic.umass.edu (Rich Emmings)
Date: Wed, 21 Dec 2005 15:21:34 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <D55C686C00F281098ACDD52F@imac-en0.delong.sj.ca.us>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu> 
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<Pine.GSO.4.63.0512211029540.7946@troy>
	<D55C686C00F281098ACDD52F@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.GSO.4.63.0512211510400.7946@troy>

On Wed, 21 Dec 2005, Owen DeLong wrote:
>
>>
>> IP addresses in aggregate express a hierarchy.  AS numbers do not.
>>
> Or at least do not yet.
>

I'll hope not, pending a *real* good reason.

>
>> 2 byte ASN's 0 - 65535 unsigned, and 4 byte are 65536-4294967295.  ASN
>> 1,000,000 would mean the AS space has grown an additional ~15 times the
>> existing space.
>>
> Not quite.  16 bit ASNs are 0-65535 unsigned.  32 bit ASNs are 0-4294967295
> also unsigned.  32 bit ASNs which overlap the same integer space as the
> 16 bit ASNs are equivalent and all 32 bit ASN software is required to
> support 16 bit representations thereof.
>

Point conceded: the low range can be 16 or 32 bit, and the high only 32. 
When all systems are 32 bit, then it doesn't matter.

(Problem is if a 32 Bit number gets stuffed into a 16 bit data bucket and 
does something strange, but that's a problem for the routing code 
programmers to not screw up.)

>
> How many 7 digit phone numbers have you seen without separators?
> Most I've seen are either XX-XX-XXX or XXX-XXXX.
>

I'll wager when you recall a phone number, you just rattle off all 7 digits, 
and don't recall or vocalize the delimiters that are commonly used in 
writing.  If it's written down, I'd guess that old fashion , or . delimiters 
depending on the side of the ocean you're on, will work for human representation.


From gih at apnic.net  Wed Dec 21 15:54:28 2005
From: gih at apnic.net (Geoff Huston)
Date: Thu, 22 Dec 2005 07:54:28 +1100
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
Message-ID: <6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>


>
>3.) 2005-9 says nothing about whether or not people requesting 4 byte
>ASN can request specific 4 byte
>ASN. I think that the current sequential assignment should continue.


It was never my intention to alter the AS Number assignment policy to allow 
the request of specific numbers.

Now the policy, as written, had a definition of "4-Byte only AS Numbers" in 
the terminology section, and I suspect that this definition is adequate in 
terms of equating this phrase with the concept of numbers with non-zero 
high order bits.

regards,

    Geoff





From bmanning at vacation.karoshi.com  Wed Dec 21 16:48:57 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 21 Dec 2005 21:48:57 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
Message-ID: <20051221214857.GF19115@vacation.karoshi.com.>

On Thu, Dec 22, 2005 at 07:54:28AM +1100, Geoff Huston wrote:
> 
> >
> >3.) 2005-9 says nothing about whether or not people requesting 4 byte
> >ASN can request specific 4 byte
> >ASN. I think that the current sequential assignment should continue.
> 
> 
> It was never my intention to alter the AS Number assignment policy to allow 
> the request of specific numbers.
> 
> Now the policy, as written, had a definition of "4-Byte only AS Numbers" in 
> the terminology section, and I suspect that this definition is adequate in 
> terms of equating this phrase with the concept of numbers with non-zero 
> high order bits.

	not to confuse policy w/ design but...

	hum... an i had thought that -all- ASN's were defined in 4 byte
	space - but historically only the low order bytes were delegated.
	e.g. there is no such thing as a 2 byte ASN, just a 2 byte representation.

--bill	

> 
> regards,
> 
>     Geoff
> 
> 
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml


From tony.li at tony.li  Wed Dec 21 16:54:43 2005
From: tony.li at tony.li (Tony Li)
Date: Wed, 21 Dec 2005 13:54:43 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <20051221214857.GF19115@vacation.karoshi.com.>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
	<20051221214857.GF19115@vacation.karoshi.com.>
Message-ID: <8EBB0BB2-BDAB-44F7-BBD7-B1185B3B79DD@tony.li>


> 	not to confuse policy w/ design but...
>
> 	hum... an i had thought that -all- ASN's were defined in 4 byte
> 	space - but historically only the low order bytes were delegated.
> 	e.g. there is no such thing as a 2 byte ASN, just a 2 byte  
> representation.
>


Bill,

That would have been nice...  however, that doesn't match reality.

Tony



From Michael.Dillon at btradianz.com  Thu Dec 22 07:09:54 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Thu, 22 Dec 2005 12:09:54 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
Message-ID: <OFAAA58B17.975FA72F-ON802570DF.00425C69-802570DF.0042D326@btradianz.com>

> Now the policy, as written, had a definition of "4-Byte only AS Numbers" 
in 
> the terminology section, and I suspect that this definition is adequate 
in 
> terms of equating this phrase with the concept of numbers with non-zero 
> high order bits.

This is the type of language that I am attacking when
I suggested that the policy proposal needs a complete
rewrite to put into PLAIN ENGLISH.

Convoluted language may be acceptable in academic papers
but it has no place in ARIN's policies!

As far as I can see, there is no such thing as a 4-byte
AS number and therefore no such thing as a 4-byte only 
AS number. All the AS numbers that I have ever seen have
been simple decimal numbers, positive integers if you want
a more technical definition. If the BGP protocol needs to
allocate some number of bytes to transmit the number, then
that is an implementation issue, not a policy issue.

On the policy level I see that we are lifting the maximum
AS number beyond the 65535 that is the current maximum.
As far as policy is concerned, I don't see what bytes
have to do with this at all.

If people want to talk about bytes, I suggest that they
should join the IETF list or the BGP implementors list.

--Michael Dillon




From Michael.Dillon at btradianz.com  Thu Dec 22 08:53:05 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Thu, 22 Dec 2005 13:53:05 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <87k6dxxptr.fsf@valhalla.seastrom.com>
Message-ID: <OF899CC58F.78B8B625-ON802570DF.004BD405-802570DF.004C4593@btradianz.com>

> Conversely, there is such a thing a two bytes of AS number.  They are
> not represented as ASCII strings on the wire.  The fact that you see
> them as decimal numbers is simply an artifact of where you sit.  For
> instance, see rfc1771, section 4.2 and look at the diagram of the open
> message.

I see that as an implementation issue, not a policy issue.

> IF it is postulated that migrating to a longer ASN representation over
> time is a good thing, AND it is understood that this is experimental
> at this time, AND it is understood as a consequence of previous
> experience that having registry services from day 0 is a Good Thing,
> THEN it makes perfect sense to have a policy that says "registries
> will make this available".  It's unclear to me from your email whether
> you have a problem with this.

I agree that the registries should make available
AS numbers greater than 65535 for those organizations
who need to put the new BGP protocol into production
and who need to ensure that the quirks of large AS 
numbers (mapping to AS 23456) are working OK.

> I have a lesser degree of support for the sunset provisions that Geoff
> includes in his proposal, and I think he and I are going to have to
> agree to disagree on whether this should actually be three separate
> policies.

Since ARIN has revised the policy set into a policy 
handbook, I don't think it matters how many changed
clauses are included in a policy proposal. However,
the proposal does need to be clear, understandable, 
and easy to relate to the existing policy set. I would
prefer to see plain English wording, and I would prefer
to see the proposal as a list of adds, changes, and
deletions to the existing policy set.

In one respect, you are right that not all elements
of Geoff's proposal are equally urgent. So in the 
interests of simplicity, it makes sense to deal
with first things first.

--Michael Dillon



From tme at multicasttech.com  Thu Dec 22 09:02:44 2005
From: tme at multicasttech.com (Marshall Eubanks)
Date: Thu, 22 Dec 2005 09:02:44 -0500
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
Message-ID: <9C206919-9F08-404D-BF76-4E03E59F3A77@multicasttech.com>


On Dec 21, 2005, at 3:54 PM, Geoff Huston wrote:

>
>>
>> 3.) 2005-9 says nothing about whether or not people requesting 4 byte
>> ASN can request specific 4 byte
>> ASN. I think that the current sequential assignment should continue.
>
>
> It was never my intention to alter the AS Number assignment policy  
> to allow the request of specific numbers.
>

Dear Goeff;

I never doubted this; however, I think that the language should not  
be ambiguous.

> Now the policy, as written, had a definition of "4-Byte only AS  
> Numbers" in the terminology section, and I suspect that this  
> definition is adequate in terms of equating this phrase with the  
> concept of numbers with non-zero high order bits.
>

I agree. Just to be clear, this of course says nothing about  
sequentiality.


> regards,
>
>    Geoff
>

Regards
Marshall

>
>



From sleibrand at internap.com  Thu Dec 22 09:38:44 2005
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 22 Dec 2005 09:38:44 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <OFAAA58B17.975FA72F-ON802570DF.00425C69-802570DF.0042D326@btradianz.com>
References: <OFAAA58B17.975FA72F-ON802570DF.00425C69-802570DF.0042D326@btradianz.com>
Message-ID: <Pine.LNX.4.58.0512220800490.5719@sleibrand.acs.internap.com>

On 12/22/05 at 12:09pm -0000, Michael.Dillon at btradianz.com wrote:

> > Now the policy, as written, had a definition of "4-Byte only AS
> > Numbers"  in the terminology section, and I suspect that this
> > definition is adequate in terms of equating this phrase with the
> > concept of numbers with non-zero high order bits.
>
> This is the type of language that I am attacking when
> I suggested that the policy proposal needs a complete
> rewrite to put into PLAIN ENGLISH.
>
> Convoluted language may be acceptable in academic papers
> but it has no place in ARIN's policies!

The problem with "plain English" is that it conveys less information
and/or is more ambiguous than precisely defining and then properly using
new terminology.  If that were not the case, jargon would not be so
prevalent nor so useful.

> As far as I can see, there is no such thing as a 4-byte
> AS number and therefore no such thing as a 4-byte only
> AS number. All the AS numbers that I have ever seen have
> been simple decimal numbers, positive integers if you want
> a more technical definition. If the BGP protocol needs to
> allocate some number of bytes to transmit the number, then
> that is an implementation issue, not a policy issue.
>
> On the policy level I see that we are lifting the maximum
> AS number beyond the 65535 that is the current maximum.
> As far as policy is concerned, I don't see what bytes
> have to do with this at all.
>
> If people want to talk about bytes, I suggest that they
> should join the IETF list or the BGP implementors list.

The problem here is that it's not just an implementation issue, it's a
standards issue.  The RFC's defined by the IETF et. al. dictate that
existing autonomous system numbers, because they are two-byte unsigned
integers, must be in the range of 1-65535.  Because the real world drives
ARIN policy, ARIN cannot simply ignore that fact and blithely continue to
allocate autonomous system numbers of 65536 and above without working with
the routing community (represented by the IETF, BGP implementors, NANOG,
et. al.) to ensure such numbers will be usable.  That's why this policy
has been proposed.

The reason for defining 2-byte, 4-byte, and 4-byte-only ASNs in this
*temporary* policy is to clarify to those who must actually use the
policy what their options are.  If your version of IOS doesn't support
4-byte ASNs, you need a 2-byte one.  If you want to test whether your new
bleeding-edge code properly supports 4-byte ASNs, you need a 4-byte-only
ASN.  If your mainline well-tested code supports 4-byte ASNs and you're
trying to operate a production network, any 4-byte ASN will do.

While you could remove the 2-byte, 4-byte, and 4-byte-only definitions and
simply refer to ranges of unsigned integers in the policy, that would
provide less information to ARIN members when they must decide whether to
request an ASN from a specific range.  If it's plain on my ASN request
form that I can requesting a 2-byte or 4-byte-only ASN, I'm much more
likely to be able to Google for "2-byte vs. 4-byte ASN" and get useful
guidance on which my router supports.

-Scott


From Michael.Dillon at btradianz.com  Thu Dec 22 10:17:58 2005
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Thu, 22 Dec 2005 15:17:58 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <Pine.LNX.4.58.0512220800490.5719@sleibrand.acs.internap.com>
Message-ID: <OFFC57DCD7.4252BA4A-ON802570DF.0052B446-802570DF.00540B16@btradianz.com>

> The problem with "plain English" is that it conveys less information
> and/or is more ambiguous than precisely defining and then properly using
> new terminology. 

This is not so. Please read the Securities and
Exchange Commission's handbook on Plain English.
You only need to read the Preface, Introduction and
the first chapter to the end of page 6. After that
it will be clear that PLAIN ENGLISH does not convey
less information, is less ambiguous and does not require
the audience to be an expert in any particular NEW
terminology.

http://www.sec.gov/pdf/handbook.pdf

>If that were not the case, jargon would not be so
> prevalent nor so useful.

Jargon is useful because it is a shared language
among a small group of people who are "special". 
Thieves use it, kid use it, and scientists use it.
In all cases they use it to make communication
between themselves clearer while obscuring their
meaning to outsiders. You can see this clearly in 
scientific papers and technical books which go to
great pains to define the language that they use.
The end result is that the language is not intelligible
to people who do not pass through these "gateways" 
and learn the special language.

I will admit that we cannot entirely avoid Internet
related terminology in ARIN, however there is no need
for POLICIES to use obscure terminology in an organization
that claims to act for the benefit of all citizens of 
the countries in its service area.

>  Because the real world drives
> ARIN policy, ARIN cannot simply ignore that fact and blithely continue 
to
> allocate autonomous system numbers of 65536 and above without working 
with
> the routing community (represented by the IETF, BGP implementors, NANOG,
> et. al.) to ensure such numbers will be usable.  That's why this policy
> has been proposed.

There you go, writing in PLAIN ENGLISH. Do you support 
a policy that says:

On 1 January 2007, applicants for an AS number may
request that ARIN issue them a number greater than 
65535. If the applicant does not request such a number
then ARIN will issue a number less than or equal to
65535.

That is plain English, covers exactly the 1st clause of
2005-9, doesn't require a nomenclature or terminology
section, and is the kind of text I would prefer to see
in ARIN's policy handbook. The main improvement that I
can see to my suggested text is that it should have a
section number to identify where it will be added within
the policy handbook. It would also be useful for the AS
number application form to have a warning to applicants
not to apply for large AS numbers unless they know that
such numbers are supported by their equipement.

> The reason for defining 2-byte, 4-byte, and 4-byte-only ASNs in this
> *temporary* policy 

All policies are temporary.

--Michael Dillon



From sleibrand at internap.com  Thu Dec 22 11:39:56 2005
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 22 Dec 2005 11:39:56 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <OFFC57DCD7.4252BA4A-ON802570DF.0052B446-802570DF.00540B16@btradianz.com>
References: <OFFC57DCD7.4252BA4A-ON802570DF.0052B446-802570DF.00540B16@btradianz.com>
Message-ID: <Pine.LNX.4.58.0512221121320.13145@sleibrand.acs.internap.com>

On 12/22/05 at 3:17pm -0000, Michael.Dillon at btradianz.com wrote:

> > The problem with "plain English" is that it conveys less information
> > and/or is more ambiguous than precisely defining and then properly using
> > new terminology.
>
> This is not so. Please read the Securities and
> Exchange Commission's handbook on Plain English.
> After that it will be clear that PLAIN ENGLISH does not convey
> less information, is less ambiguous and does not require
> the audience to be an expert in any particular NEW
> terminology.
>
> http://www.sec.gov/pdf/handbook.pdf
>
> I will admit that we cannot entirely avoid Internet
> related terminology in ARIN, however there is no need
> for POLICIES to use obscure terminology in an organization
> that claims to act for the benefit of all citizens of
> the countries in its service area.

I don't believe that "2-byte ASN" and "4-byte ASN" constitute obscure
terminology.  Anyone tangentially familiar with Internet terminology knows
what a byte is, and can figure out the most important differences between
ASNs of 2 vs. 4 bytes in length.  However, if a reader is unclear as to
the meaning of those terms, he needs only read six lines of the policy to
fully understand them in plain English (decimal) terms.

> >  Because the real world drives ARIN policy, ARIN cannot simply ignore
> > that fact and blithely continue to allocate autonomous system numbers
> > of 65536 and above without working with the routing community
> > (represented by the IETF, BGP implementors, NANOG, et. al.) to ensure
> > such numbers will be usable.  That's why this policy has been
> > proposed.
>
> There you go, writing in PLAIN ENGLISH. Do you support
> a policy that says:
>
> On 1 January 2007, applicants for an AS number may
> request that ARIN issue them a number greater than
> 65535. If the applicant does not request such a number
> then ARIN will issue a number less than or equal to
> 65535.
>
> That is plain English, covers exactly the 1st clause of
> 2005-9, doesn't require a nomenclature or terminology
> section, and is the kind of text I would prefer to see
> in ARIN's policy handbook.

I would support such a policy if it were proposed, yes.  However, it has
not been proposed.  The policy that has been proposed takes pains to
express as much information about the ASN distinction as possible.  It
defines all terms that may be unfamiliar to someone who hasn't yet learned
how BGP works.  So in my opinion it is unnecessary to make such a change
to Geoff's proposal.

The SEC Plain English handbook you cited states that "a common
misconception about plain English writing" is that it means "deleting
complex information to make the document easier to understand."  I would
argue that by deleting references to the number of bytes used to hold an
ASN, you are deleting complex information to make the document easier to
understand.

-Scott


From andrew.dul at quark.net  Thu Dec 22 11:57:02 2005
From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=)
Date: Thu, 22 Dec 2005 16:57:02 +0000
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
Message-ID: <20051222165702.4508.qmail@hoster908.com>

>  -------Original Message-------
>  From: Michael.Dillon at btradianz.com
>  Subject: Re: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
>  Sent: 22 Dec '05 07:17
>  
>  All policies are temporary.
>  

Yes & no, this is true because we can change policies in the future, but in the case of a "temporary ARIN policy" it will automatically be removed from the NPRM at the expiration date without further action by the community.  That is different from a "permanent" policy which would require a new policy proposal to make a change.

In this case, this policy proposal, if it is added to the NPRM, will automatically be removed from the NPRM on Jan 1, 2010, unless the community takes other action.

Andrew 


From gih at apnic.net  Thu Dec 22 14:41:28 2005
From: gih at apnic.net (Geoff Huston)
Date: Fri, 23 Dec 2005 06:41:28 +1100
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <OF899CC58F.78B8B625-ON802570DF.004BD405-802570DF.004C4593@
	btradianz.com>
References: <87k6dxxptr.fsf@valhalla.seastrom.com>
	<OF899CC58F.78B8B625-ON802570DF.004BD405-802570DF.004C4593@btradianz.com>
Message-ID: <6.2.0.14.2.20051223063821.02bac788@kahuna.telstra.net>

At 12:53 AM 23/12/2005, Michael.Dillon at btradianz.com wrote:
> > Conversely, there is such a thing a two bytes of AS number.  They are
> > not represented as ASCII strings on the wire.  The fact that you see
> > them as decimal numbers is simply an artifact of where you sit.  For
> > instance, see rfc1771, section 4.2 and look at the diagram of the open
> > message.
>
>I see that as an implementation issue, not a policy issue.


No Michael - its a _protocol_ issue. This, in turn, leads to transition 
issues. This, in turn, leads to policy issues.






From owen at delong.com  Thu Dec 22 17:17:15 2005
From: owen at delong.com (Owen DeLong)
Date: Thu, 22 Dec 2005 14:17:15 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <9C206919-9F08-404D-BF76-4E03E59F3A77@multicasttech.com>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
	<9C206919-9F08-404D-BF76-4E03E59F3A77@multicasttech.com>
Message-ID: <DF0839283A691E61CA69FD92@imac-en0.delong.sj.ca.us>

I think Geoff's point is that as a proposal to change existing policy,
anything
which is not mentioned is not changed.

As such, the existing sequential policy remains unchanged and no further
clarification
should be required.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051222/e9df9f4f/attachment.sig>

From owen at delong.com  Thu Dec 22 17:25:56 2005
From: owen at delong.com (Owen DeLong)
Date: Thu, 22 Dec 2005 14:25:56 -0800
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <Pine.LNX.4.58.0512221121320.13145@sleibrand.acs.internap.com>
References: <OFFC57DCD7.4252BA4A-ON802570DF.0052B446-802570DF.00540B16@btradi
	anz.com> <Pine.LNX.4.58.0512221121320.13145@sleibrand.acs.internap.com>
Message-ID: <2784850864CF543FAA6BD288@imac-en0.delong.sj.ca.us>

> I don't believe that "2-byte ASN" and "4-byte ASN" constitute obscure
> terminology.  Anyone tangentially familiar with Internet terminology knows
> what a byte is, and can figure out the most important differences between
> ASNs of 2 vs. 4 bytes in length.  However, if a reader is unclear as to
> the meaning of those terms, he needs only read six lines of the policy to
> fully understand them in plain English (decimal) terms.
> 
While I agree in principle, and, do not advocate rewording the policy
in terms of integer ranges, I do think it would be an improvement to
speak in terms of 16 bit and 32 bit.  After all, while the term byte
these days usually refers to an octet or 8 bits, this has not always
been true.  In fact, the term byte actually can mean anywhere between
5 and 9 bits, depending on machine architecture, encoding scheme,
etc.  Byte has never been an unambiguous term.  This is one of the
reasons almost every RFC is written in terms of bits and octets
and use of the term byte is rare indeed.

Owen



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051222/1ed8a7c2/attachment.sig>

From gih at apnic.net  Thu Dec 22 17:22:56 2005
From: gih at apnic.net (Geoff Huston)
Date: Fri, 23 Dec 2005 09:22:56 +1100
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <DF0839283A691E61CA69FD92@imac-en0.delong.sj.ca.us>
References: <CC5444841A969F4CBBF6A305E569F00803006A@kronos.cait.wustl.edu>
	<46F7B3D4-866B-4FDB-B5BB-86C7CBEA4F28@multicasttech.com>
	<6.2.0.14.2.20051222075015.02adbc60@kahuna.telstra.net>
	<9C206919-9F08-404D-BF76-4E03E59F3A77@multicasttech.com>
	<DF0839283A691E61CA69FD92@imac-en0.delong.sj.ca.us>
Message-ID: <6.2.0.14.2.20051223092220.02b7f160@kahuna.telstra.net>

At 09:17 AM 23/12/2005, Owen DeLong wrote:
>I think Geoff's point is that as a proposal to change existing policy,
>anything
>which is not mentioned is not changed.
>
>As such, the existing sequential policy remains unchanged and no further
>clarification
>should be required.


yes - that was the point - thanks for the clarification

   Geoff





From sleibrand at internap.com  Thu Dec 22 20:32:08 2005
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 22 Dec 2005 20:32:08 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <2784850864CF543FAA6BD288@imac-en0.delong.sj.ca.us>
References: <OFFC57DCD7.4252BA4A-ON802570DF.0052B446-802570DF.00540B16@btradi
	anz.com> <Pine.LNX.4.58.0512221121320.13145@sleibrand.acs.internap.com>
	<2784850864CF543FAA6BD288@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.58.0512222028230.5719@sleibrand.acs.internap.com>

On 12/22/05 at 2:25pm -0800, Owen DeLong <owen at delong.com> wrote:

> > I don't believe that "2-byte ASN" and "4-byte ASN" constitute obscure
> > terminology.
>
> While I agree in principle, and, do not advocate rewording the policy
> in terms of integer ranges, I do think it would be an improvement to
> speak in terms of 16 bit and 32 bit.  After all, while the term byte
> these days usually refers to an octet or 8 bits, this has not always
> been true.  In fact, the term byte actually can mean anywhere between
> 5 and 9 bits, depending on machine architecture, encoding scheme,
> etc.  Byte has never been an unambiguous term.  This is one of the
> reasons almost every RFC is written in terms of bits and octets
> and use of the term byte is rare indeed.

That's a good point.  The IETF work on this refers to 4-octet ASNs, not
4-byte.  I would have no objections to a s/byte/octet/g replacement,
though I'm curious if Geoff or anyone else has any comments on the
matter...

-Scott


From gih at apnic.net  Thu Dec 22 20:42:09 2005
From: gih at apnic.net (Geoff Huston)
Date: Fri, 23 Dec 2005 12:42:09 +1100
Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number
In-Reply-To: <Pine.LNX.4.58.0512222028230.5719@sleibrand.acs.internap.co
 m>
References: <OFFC57DCD7.4252BA4A-ON802570DF.0052B446-802570DF.00540B16@btradi
	anz.com>
	<Pine.LNX.4.58.0512221121320.13145@sleibrand.acs.internap.com>
	<2784850864CF543FAA6BD288@imac-en0.delong.sj.ca.us>
	<Pine.LNX.4.58.0512222028230.5719@sleibrand.acs.internap.com>
Message-ID: <6.2.0.14.2.20051223123900.02bac4a8@kahuna.telstra.net>

I took the lead from the name of the IETF draft ("draft-ietf-idr-as4bytes") 
rather than the document's title or its body (which uses "octet").

Frankly, I didn't think much about this choice at the time, and I've no 
particular opinion either way and if folk think that its more consistent to 
use the terminology "octet" in the place of "byte" in the proposal then I 
have no problem in making such a change.


Geoff




  At 12:32 PM 23/12/2005, Scott Leibrand wrote:
>On 12/22/05 at 2:25pm -0800, Owen DeLong <owen at delong.com> wrote:
>
> > > I don't believe that "2-byte ASN" and "4-byte ASN" constitute obscure
> > > terminology.
> >
> > While I agree in principle, and, do not advocate rewording the policy
> > in terms of integer ranges, I do think it would be an improvement to
> > speak in terms of 16 bit and 32 bit.  After all, while the term byte
> > these days usually refers to an octet or 8 bits, this has not always
> > been true.  In fact, the term byte actually can mean anywhere between
> > 5 and 9 bits, depending on machine architecture, encoding scheme,
> > etc.  Byte has never been an unambiguous term.  This is one of the
> > reasons almost every RFC is written in terms of bits and octets
> > and use of the term byte is rare indeed.
>
>That's a good point.  The IETF work on this refers to 4-octet ASNs, not
>4-byte.  I would have no objections to a s/byte/octet/g replacement,
>though I'm curious if Geoff or anyone else has any comments on the
>matter...
>
>-Scott
>_______________________________________________
>PPML mailing list
>PPML at arin.net
>http://lists.arin.net/mailman/listinfo/ppml