Fwd: Re: RPSL support for 32 bit ASN

Larry,

>        The tool could convert from "x.y" when processing for submission,
>so you wouldn't have to deal with 2 different formats.

Yes, it could.  I'm not sure if it will though.  There is a canonical
representation for printing these numbers and as a developper I'd
use that.  If somebody wants another format internally because that
is easier, I expect him to do that in his tool.

For the same reason, I allow people to enter an IPv4 adress as
193.0.1.49, I don't expect them to do the artimethic to convert it
to 3238002993 even if in my code, I use unsigned int's.

>>An AS has been a 16 bit number forever (in terms of the lifetime of the
>>Internet) and authors have implicitly used that when writing their tools.
>>That means: regular int's (or even short unsigned ints) in the code,
>>checks on input that numbers entered are below 65536 and/or 5 digits,
>>arrays dimensioned to 65536, etc.  All this code will have to be
>>checked and updated.  I would definitely not feel comfortable using
>>code with numbers outside the range of the original spec.
>
>   The original spec doesn't specify a range.   Some code will have problems
>with numbers greater than 16-bit, others won't.   Certainly fewer 
>implementations
>will have issues with 32-bit numbers than "x.y" notation.

The AS spec does.

Then, nothing prevents you to convert "x.y" into an unsigned int in
your code and use that internally.

Henk


------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

1160438400 + 381600 = 1160820000.