[ppml] Policy Proposal 2005-9: 4-Byte AS Number

Tue Dec 20 18:48:39 EST 2005

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