Hi Larry,
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach.
That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me.
<skip> I support Henk in this. To strictly follow the RPSL extention guidelines, one has to add 12 new attributes to existing objects and 7 new classes (with total of 30+ new attributes) to accept 32bit ASn. Following RPSL extention guidelines where possible is good, but I think here alternative approach is justified. -- Katie Petrusha RIPE NCC