Re: that 4byte ASN you were considering...
On 10 Oct 2006, at 22:54, Per Gregers Bilse wrote: [This isn't meant to be flippant or anything else of the kind, it's a genuinely heartfelt thing, albeit maybe a bit off topic.] What all things computer related has needed from day one is a way of pronouncing (reading out loud) hexadecimal. My first computer was a 6502, and I've resented numbers larger than FF since then (been working with AMD Opterons for a couple of years now, disturbing). If you print and read in hex, you don't need dots or any other syntactic aids, the human eye/brain can easily group the requisite number of digits, at least for the time being. The problem is that from and including A we can't talk about the damned things any more -- we resort to spelling out each number, with no inherent and natural feel for what we're taling about. An A380 has a maximum take-off weight of around 24E (two-four-E) tonnes. An A380 has a maximum take-off weight of around 590 (five hundred and ninety) tonnes. Solve that, and we don't need any new notations beyond subtle groupings, just like we group thousands and millions in decimal notation. - Per This is so, so off topic it's not true. I started this as an off-list reply to Per but I'm so pleased with my solution that I can't help sharing it. Take the solution from natural languages. Most languages I speak (or have a smattering of) have a regular or semi-regular way of pronouncing numbers. Single digit numbers have a unique name. 10 (the base) has a unique name. Numbers from 11 to 19 have a name with a suffix and a sound similar to the terminating digit usually with a break from the rule for 11 and 12. (nine, nineteen) (fünf, fünfzehn) We'd regularize that and not have Two digit numbers with a zero in the lowest position have a name using, again, suffix and a similar sound to the name of the single significant digit involved. (four, fourty) (vier, vierzig) 100 has a unique name. 1000 has a unique name. Multiples of either are said digit name multiplier name. That's enough rules apart from the rules for combining all the above rules. So, we just need:- 1) Unique names for all the single digit numbers. 2) A unique name for the base. 3) A suffix sound for 1x form numbers. 4) A suffix sound for x0 form numbers. 5) As many unique names for x0... form numbers as we feel we need. 6) A combining rule(s). So: 1) Use the english names for 0..9. A..F may need new names if combined versions sound too similar to the compound forms. 2) 0x10 = hen 3) Use the suffix -heen for 0x11 .. 0x1f 4) Use the suffix -he for 0xX0 5) 0x100 = hexdred, 0x1000 = hexdrend 6) use the english combining rules 7) Try lots of combinations and then revisit 1. e.g 0xA0 becomes 'Aye'-he which sounds too much like eighty for comfort; so A may need a new name. So: 0x5432 = five hexdrend, four hexdred and thirhe two. 0x1017 = one hexdrend and sevenheen 0x1 = hen hexdrend Happy counting, Ian
Re: that 4byte ASN you were considering...
On Tue, 10 Oct 2006 22:54:03 BST, Per Gregers Bilse said: The problem is that from and including A we can't talk about the damned things any more -- we resort to spelling out each number, with no inherent and natural feel for what we're taling about. An A380 has a maximum take-off weight of around 24E (two-four-E) tonnes. An A380 has a maximum take-off weight of around 590 (five hundred and ninety) tonnes. I've seen somebody pronounce C48C as 'ceety four hundred and eighty cee' - and the person listening grokked it. aety, beety, ceety, deety, eety, effty. aety and eighty are a bit too similar, unfortunately. The thousands/millions probably comes easier to those of us who did a lot of octal work - the newcomers seem to like to clump hex numbers in clumps of 2 and 4. pgpB6pvkaP5kT.pgp Description: PGP signature
Re: that 4byte ASN you were considering...
On Oct 11, 2006, at 9:07 AM, [EMAIL PROTECTED] wrote: On Tue, 10 Oct 2006 22:54:03 BST, Per Gregers Bilse said: The problem is that from and including A we can't talk about the damned things any more -- we resort to spelling out each number, with no inherent and natural feel for what we're talking about. An A380 has a maximum take-off weight of around 24E (two-four-E) tonnes. An A380 has a maximum take-off weight of around 590 (five hundred and ninety) tonnes. I've seen somebody pronounce C48C as 'ceety four hundred and eighty cee' - and the person listening grokked it. aety, beety, ceety, deety, eety, effty. aety and eighty are a bit too similar, unfortunately. There is also a convention defined at- 'x' prefix/suffix convention for pronouncing hexadecimal numbers http://en.wikipedia.org/wiki/Hexadecimal -Doug
Re: that 4byte ASN you were considering...
- 'Canonical representation of 4-byte AS numbers ' http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing? It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token. For the purposes of parsing a string into internal representation, an application can treat IP addresses, netmasks and inverse masks identically. We all know that the Internet is awash in homegrown scripts written in PERL or TCL or bash or Ruby or Python. It is likely that many authors have, in the past 15 years, written scripts which contain regular expressions like [0123456789.]* to match a string containing only digits and the period. Those scripts will be confused by this AS number notation. Also, any script which recognizes IP address-like objects when it hits the first period in a numeric string. The real question is what does the notation 1.0 add that the notation 65536 does not provide? All I can see is that it adds the risk of broken scripts and the confusion of AS numbers that look like decimal numbers. If the IETF had really wanted to create a universal notation then they should have recommended that AS numbers be represented in the form AS65536 which is completely unambiguous. When IP addresses were created, it was important to indicate the boundaries between the network number and the host address. Originally, the periods represented this boundary for the three classes of IP address, class A, class B and class C. Long ago, we removed this classfulness attribute, but the notation remains because lots of applications expect this notation. So why on earth are we changing AS number notation today? --Michael Dillon
Re: that 4byte ASN you were considering...
At 10:44 10/10/2006, [EMAIL PROTECTED] wrote: - 'Canonical representation of 4-byte AS numbers ' http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing? It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token. Well, it will break an applications that considers everything consisting of numbers and dots to be an IP address/netmask/inverse mask. I don't think many applications do this, as they will then treat the typo 193.0.1. as an IP address. It won't break applications that check if there are exactly 4 numbers in the 0-255 range and 3 dots. The alternative notation (x:y) is much worse in this respect. x:y is something (a community string). x.y is not. The real question is what does the notation 1.0 add that the notation 65536 does not provide? It is (for me, and I guess most other humans) much easier to read and remember, just as 193.0.1.49 is easier to read and remember than 3238002993. It also reflects that on the wire there are two 16 bit numbers, rather than 1 32-bit number. More important: I think it is a mistake to assume that using AS65536 will NOT break things: 1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just the next one in the line, it is an AS that will have to be treated differently. The code has to recognize it and replace it by the transistion mechanism AS. 2. Just as people having used the regexps that you mentioned, I'm also certain that people have used unsigned short int's or signed long int's in their code. In short, like it or not, you will have to check and update your tools anyway. If the IETF had really wanted The IETF process is open and you can still comment on the issue. 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 NetherlandsThe NetherlandsMobile: +31.6.55861746 -- 1160438400 + 381600 = 116082.
Re: that 4byte ASN you were considering...
Using '.' as a delimiter will be somewhat annoying when used in regular expressions and likely to induce errors. Would '-' be a better choice? somehow we seem to have survived similar issues in IP quad representation. randy
Re: that 4byte ASN you were considering...
Well, it will break an applications that considers everything consisting of numbers and dots to be an IP address/netmask/inverse mask. I don't think many applications do this, as they will then treat the typo 193.0.1. as an IP address. An application using [0123456789.]* will not break when it sees the above typo. 193.0.1. *IS* an IP address-like object and any existing code will likely report it as mistyped IP address or mask. It won't break applications that check if there are exactly 4 numbers in the 0-255 range and 3 dots. True, however my point is that I do not believe that all existing applications do this. Therefore, changing their input in an unexpected way will break them. The real question is what does the notation 1.0 add that the notation 65536 does not provide? It is (for me, and I guess most other humans) much easier to read and remember, just as 193.0.1.49 is easier to read and remember than 3238002993. It also reflects that on the wire there are two 16 bit numbers, rather than 1 32-bit number. In my experience, ISPs do not transmit numbers by phone calls and paper documents. They use emails and web pages which allow cut'n'paste to avoid all transcription errors. And I know of no earthly reason why a general written representation needs to represent the format of bits on the wire. How many people know or care whether their computer is bid-endian or little endian? 1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just the next one in the line, it is an AS that will have to be treated differently. The code has to recognize it and replace it by the transistion mechanism AS. And how is a special notation superior to if asnum 65535 then process_big_as else process_little_as In any case, people wishing to treat big asnums differently will need to write new code so the dot notation provides them zero benefit. 2. Just as people having used the regexps that you mentioned, I'm also certain that people have used unsigned short int's or signed long int's in their code. Typically ISPs are using apps written in higher level languages which are more likely to treat integers as 32-bit signed quantities. In any case, this is a length issue, not an issue of notation. In short, like it or not, you will have to check and update your tools anyway. My point is that if we do NOT introduce a special notation for ASnums greater than 65536, then tools only need to be checked, not updated. If your tool was written by someone who left the company 7 years ago then you might want to do such checking by simply testing it with large as numbers, not by inspecting the code. The dot notation requires that somebody goes in and updates/fixes all these old tools. --Michael Dillon
Re: that 4byte ASN you were considering...
At 13:34 10/10/2006, [EMAIL PROTECTED] wrote: My point is that if we do NOT introduce a special notation for ASnums greater than 65536, then tools only need to be checked, not updated. If your tool was written by someone who left the company 7 years ago then you might want to do such checking by simply testing it with large as numbers, not by inspecting the code. The dot notation requires that somebody goes in and updates/fixes all these old tools. I don't agree with you but this is a valid argument. I suggest you make it to the IESG before they decide. 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 NetherlandsThe NetherlandsMobile: +31.6.55861746 -- 1160438400 + 381600 = 116082.
RE: that 4byte ASN you were considering...
somehow we seem to have survived similar issues in IP quad representation. true but we don't typically user them in regex expressions as much (at least I haven't). Its more masks and inverted masks... Regards, Neil. -- Neil J. McRae - Alive and Kicking - Team Hong Nor [EMAIL PROTECTED]
AW: that 4byte ASN you were considering...
My point is that if we do NOT introduce a special notation for ASnums greater than 65536, then tools only need to be checked, not updated. If your tool was written by someone who left the company 7 years ago then you might want to do such checking by simply testing it with large as numbers, not by inspecting the code. The dot notation requires that somebody goes in and updates/fixes all these old tools. I don't agree with you but this is a valid argument. I suggest you make it to the IESG before they decide. Henk Yes, I agree too. Please make sure to introduce your proposal within time. If you need some (virtual) signatures of supporters just ask on the list :-) Gunther
Re: that 4byte ASN you were considering...
Henk Uijterwaal wrote:
At 13:34 10/10/2006, [EMAIL PROTECTED] wrote:
My point is that if we do NOT introduce a special notation
for ASnums greater than 65536, then tools only need to be
checked, not updated. If your tool was written by someone
who left the company 7 years ago then you might want to
do such checking by simply testing it with large as numbers,
not by inspecting the code. The dot notation requires that
somebody goes in and updates/fixes all these old tools.
I don't agree with you but this is a valid argument. I suggest you
make it to the IESG before they decide.
Henk
RFC2622 uses the following Flex macro for AS numbers --
INT[[:digit:]]+
ASNOAS{INT}
Note that this does not limit the length of the AS number. While
it's no guarantee that an RPSL tool wouldn't break with longer AS
numbers, it would seem less likely than with the . notation.
-Larry Blunk
Merit
Re: that 4byte ASN you were considering...
At 9:44 +0100 10/10/06, [EMAIL PROTECTED] wrote: It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token. I can't believe grown engineers are afraid of a dot. We all know that the Internet is awash in homegrown scripts written in PERL or TCL or bash or Ruby or Python. It is likely I find that more of a reason to do a change than to leave well enough alone. What's gonna happen when all of the current generation (the writers of the scripts) retire and close the door on their careers? How will the Internet live on? Shouldn't a technical beast be able to thrive on technical changes? But that question isn't germane to the issue at hand. The real question is what does the notation 1.0 add that the notation 65536 does not provide? Fair enough - my answer is it provides the same as the dotted quad for IP, it makes it easier for human to human conveyance. It also makes the transition from 2 byte to 4 byte more obvious in the interim. If the IETF had really wanted to create a universal notation The IETF really doesn't want to create anything. The IETF is just a forum where folks can gather to discuss an issue like this. (Pardon my second non-germane comment on this thread.) When IP addresses were created, it was important to indicate the boundaries between the network number and the host address. Originally, the periods represented this boundary for the three classes of IP address, class A, class B and class C. Long ago, we removed this classfulness attribute, but the notation remains because lots of applications expect this notation. So why on earth are we changing AS number notation today? For the same reason - to distinguish the boundaries between what the old engineers know from what the future young engineers will take for granted. The dot would outlast the old engineers just as the dotted quad persists into the CIDR age. Why on earth? Because there aren't [m]any IP addresses on the moon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
Re: that 4byte ASN you were considering...
I can't believe grown engineers are afraid of a dot. they are not. but they have enough free time on their hands to endlessly discuss a dot. randy
Re: that 4byte ASN you were considering...
On 2006-10-10 09:41:37, Edward Lewis wrote: I can't believe grown engineers are afraid of a dot. People have been burned in the past, and this leads them to exaggerate the cost. But even if the cost is not as large as they fear, it is not zero. If you are in favor of a new notation because you think it will save work overall by reducing confusion, or because you prefer it aesthetically, or because you want change for the sake of change in order to flush out old tools, then you should write up your arguments and get them included in the document. It would be much more efficient to explain the benefits once in the RFC, rather than a thousand times whenever someone complains that they don't like it. Whatever the benefits are, it's apparent from the thread here that many operators are not convinced, and that they have concerns that may not have been considered. Although this subject is relatively on-topic for NANOG, talking about it here is not going to have any effect on the draft. If you feel strongly about it, you should join the IDR or IESG lists. -- Shields.
Re: that 4byte ASN you were considering...
On Oct 10, 2006, at 4:34 AM, [EMAIL PROTECTED] wrote: Well, it will break an applications that considers everything consisting of numbers and dots to be an IP address/netmask/inverse mask. I don't think many applications do this, as they will then treat the typo 193.0.1. as an IP address. An application using [0123456789.]* will not break when it sees the above typo. 193.0.1. *IS* an IP address-like object and any existing code will likely report it as mistyped IP address or mask. Actually, most code will parse it as equivalant of 193.0.0.1. Most of the IP address parsers I have encountered will do zero insertion in the middle, such that 10.253 is parsed the same as 10.0.0.253, 10.3.24 is parsed as 10.0.3.24, 192.159.8 is parsed as 192.159.0.8, etc. I'm not saying I think this is necessarily good, but, it is the behavior observed. The real question is what does the notation 1.0 add that the notation 65536 does not provide? It is (for me, and I guess most other humans) much easier to read and remember, just as 193.0.1.49 is easier to read and remember than 3238002993. It also reflects that on the wire there are two 16 bit numbers, rather than 1 32-bit number. In my experience, ISPs do not transmit numbers by phone calls and paper documents. They use emails and web pages which allow cut'n'paste to avoid all transcription errors. And I know of no earthly reason why a general written representation needs to represent the format of bits on the wire. How many people know or care whether their computer is bid-endian or little endian? Your experience differs from mine. There are lots of situations where ASNs are discussed on telephone calls and/or transcribed to/from yellow stickies, etc. As to matching bits on the wire, no, it's not necessary, but, it is a convenient side-effect. 1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just the next one in the line, it is an AS that will have to be treated differently. The code has to recognize it and replace it by the transistion mechanism AS. And how is a special notation superior to if asnum 65535 then process_big_as else process_little_as In any case, people wishing to treat big asnums differently will need to write new code so the dot notation provides them zero benefit. The dot notation is an improvement in human readability. It offers no benefit to machines as they don't care as long as they have a good parser for whatever notation is chosen. The notation is for the human interface. My point is that if we do NOT introduce a special notation for ASnums greater than 65536, then tools only need to be checked, not updated. If your tool was written by someone who left the company 7 years ago then you might want to do such checking by simply testing it with large as numbers, not by inspecting the code. The dot notation requires that somebody goes in and updates/fixes all these old tools. So will the colon notation for IPv6 addresses. Owen PGP.sig Description: This is a digitally signed message part
Re: that 4byte ASN you were considering...
On Tue, Oct 10, 2006 at 01:59:22AM -0500, Randy Bush wrote: somehow we seem to have survived similar issues in IP quad representation. Or domain names. I'm concerned by the kind of discussion I'm seeing here. RFC's are not law, and if your router vendor adopts this informational document in such a way that it breaks your scripts then that's an issue to take up with your router vendor(s). I don't see why there's any reason it can't be made so (excuse me for using what little Cisco configuration language I can remember): o 'conf t' accepts: router bgp 255.255.255.254 neighbor 10.0.0.1 remote-as 255.255.255.255 o 'wr mem/term' writes out: router bgp 4294967294 # 255.255.255.254 neighbor 10.0.0.1 remote-as 4294967295 # 255.255.255.255 or even: # BGP 255.255.255.254 router bgp 4294967294 # EZ-ASN: 255.255.255.255 neighbor 10.0.0.1 remote-as 4294967295 One or both of which probably won't break anyone's scripts. The point is that this is a configuration language versioning issue, which isn't something I think of the IETF having either a lot of interest or ability to define. As Shields has indicated, email the IETF mailing lists if you must. I'm in favor of people sending mail to lists to which I do not subscribe. But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpBgptt6Z5i1.pgp Description: PGP signature
Re: that 4byte ASN you were considering...
On Tue, 10 Oct 2006, Kevin Loch wrote: Randy Bush wrote: - 'Canonical representation of 4-byte AS numbers ' draft-michaelson-4byte-as-representation-01.txt as an Informational RFC and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing? Using '.' as a delimiter will be somewhat annoying when used in regular expressions and likely to induce errors. Would '-' be a better choice? No. We already use . for number of ip resources so this is good. I suspect new tools config systems will also accept full 32bit number as well (just like its sometimes possible with ip addresses) which will give you way out if you do not like . in ASN. And regular ASNs 65k will work without 0. in this way as well. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: that 4byte ASN you were considering...
On 10-Oct-2006, at 12:01, David W. Hankins wrote: But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill. It's not so weird when you realise that the notation adopted has an impact on other IETF work (RPSL is the obvious example that springs to mind). Joe
Re: that 4byte ASN you were considering...
On Tue, Oct 10, 2006 at 02:53:53PM -0500, Joe Abley wrote: On 10-Oct-2006, at 12:01, David W. Hankins wrote: But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill. It's not so weird when you realise that the notation adopted has an impact on other IETF work (RPSL is the obvious example that springs to mind). I think you misunderstand me... It's not weird that this document exists. It is weird, to me, that people who have concerns about their router's configuration syntax expect to be able to take this up with the IETF, rather than their router manufacturer. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpeITfRTo47o.pgp Description: PGP signature
Re: that 4byte ASN you were considering...
On 2006-10-10 13:41:42, David W. Hankins wrote: It is weird, to me, that people who have concerns about their router's configuration syntax expect to be able to take this up with the IETF, rather than their router manufacturer. Personally, I care less about which notation we choose to express four-byte ASNs than that *everyone choose one notation*. Choosing a mediocre notation and using it consistently would be better than having to live forever with multiple notations. Operating a heterogenous network is hard enough already. As to whether this is within the scope of the IETF, note that they are already going far, far beyond this in the Netconf WG, which is defining a complete router configuration protocol. http://www.ietf.org/html.charters/netconf-charter.html http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt -- Shields.
Re: that 4byte ASN you were considering...
[This isn't meant to be flippant or anything else of the kind, it's a genuinely heartfelt thing, albeit maybe a bit off topic.] What all things computer related has needed from day one is a way of pronouncing (reading out loud) hexadecimal. My first computer was a 6502, and I've resented numbers larger than FF since then (been working with AMD Opterons for a couple of years now, disturbing). If you print and read in hex, you don't need dots or any other syntactic aids, the human eye/brain can easily group the requisite number of digits, at least for the time being. The problem is that from and including A we can't talk about the damned things any more -- we resort to spelling out each number, with no inherent and natural feel for what we're taling about. An A380 has a maximum take-off weight of around 24E (two-four-E) tonnes. An A380 has a maximum take-off weight of around 590 (five hundred and ninety) tonnes. Solve that, and we don't need any new notations beyond subtle groupings, just like we group thousands and millions in decimal notation. - Per
Re: that 4byte ASN you were considering...
On Tue, Oct 10, 2006 at 09:23:54PM +, Michael Shields wrote: Personally, I care less about which notation we choose to express four-byte ASNs than that *everyone choose one notation*. Choosing a Totally, and I would be surprised if that were not the eventual outcome. In the absence of any other format, the dotted quad will probably bubble up into user interfaces eventually. I think everyone else is wrong that there is going to be some sort of heinous y2k doomsday scenario here in regards to breaking their current-day scripts or operational practices, or if there were that this is an issue to take up with the IETF rather than the vendors making said changes. As to whether this is within the scope of the IETF, note that they are already going far, far beyond this in the Netconf WG, which is defining a complete router configuration protocol. Netconf absolutely, and zeroconf too. These are machine languages, they aren't user interfaces. So this is just a level of indirection. If someone were suggesting a change to the netconf wire format that is not reverse compatible, that's obviously something that should be brought up at the IETF! But a change to the config file or web/scripting interface or whatever that you use to trigger Netconf into action? Totally not their bag. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpSNKKJe8Itg.pgp Description: PGP signature
that 4byte ASN you were considering...
FYI... ifyou think you have an opinion about this, it might be worth a read before the IESG dictates how you can use/code these badboys... - The IESG has received a request from an individual submitter to consider the following document: - 'Canonical representation of 4-byte AS numbers ' draft-michaelson-4byte-as-representation-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt --bill
Re: that 4byte ASN you were considering...
- 'Canonical representation of 4-byte AS numbers ' draft-michaelson-4byte-as-representation-01.txt as an Informational RFC and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing? randy
Re: that 4byte ASN you were considering...
Randy Bush wrote: - 'Canonical representation of 4-byte AS numbers ' draft-michaelson-4byte-as-representation-01.txt as an Informational RFC and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing? Using '.' as a delimiter will be somewhat annoying when used in regular expressions and likely to induce errors. Would '-' be a better choice? - Kevin
