Fwd: Re: RPSL support for 32 bit ASN

Henk Uijterwaal wrote:
> 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.

  I guess I wasn't being clear.  I was speaking of the input processor
for the routing registry itself.    For example, the RIPE software will
convert inetnum attributes from CIDR prefix format to range format.

  The point is that a number tools using the registry.   Some use the
whois interface, while others do bulk downloads of the registry
data to process it.     While not a huge population of users,  I think you
may underestimate the number and variety of tools.    Further, these
tools will not always reference objects registered by the user.  There
may be object references to external route-set's/as-set's, etc..    
Tools that
do bulk processing of registry files will scan through all the objects 
(looking
for particular AS numbers in route: objects for example).

   -Larry




>
>>> 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
>
>