-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bob
There's two things this document asks for. (1) for people to document IPv6 address in the recommended way. (2) implementations to display(or save to text/log) IPv6 addresses in the recommended way. (1) can never become a MUST. (2), yes but not so that new implementations and old implementations will not work together. So I was thinking tightening the wording of Section 4,5,6 and saying, "implementations following this specification MUST display them as such, and also it is advised that humas also try to document addresses as such" may work. Or, a few days ago when I was reading IESG's review I was thinking this document should go back to Informational for now. There are no guidelines out there today and this problem needs immediate attention. >> I was thinking that we should have a strict canonical form >> along the line of what is proposed in Section 8. This format >> SHOULD always be used when an IPv6 address is saved to a file >> or log as text (as opposed to binary). The canonical format >> would not support any of the embedded formats. Everything >> would look like: I can agree to this, except for the doing away with dot decimal part. IMHO doing away with dot decimal will make life harder for most people. Log files and text files are what get passed around when troubleshooting. Regards, Seiichi Brian E Carpenter wrote: > Bob, > > On 2010-02-06 09:47, Bob Hinden wrote: > ... >> I was thinking that we should have a strict canonical form >> along the line of what is proposed in Section 8. This format >> SHOULD always be used when an IPv6 address is saved to a file >> or log as text (as opposed to binary). The canonical format >> would not support any of the embedded formats. Everything >> would look like: >> >> 2001:db8:0:0:1:22::1 >> >> 2001:db8:0:0:1::1 >> >> 2001:db8:0:11:222:3333:c000:0201 >> >> Tools could be built that would allow alternative ways to >> display the addresses in the file. For example in the second >> case above, it could be displayed as: >> >> 2001:db8:0:11:222:3333:192.0.2.1 >> >> All operations used to compare and search against entries in >> the file would performed against the canonical format. A >> search tool could allow an address to be entered in an >> embedded format (or any format defined in RFC4291), but it >> would convert the address to the canonical format before the >> search is performed. >> >> This is similar to the way something a spread sheet deals >> with dates and times. The underlying data does not change if >> the user decides to change the format it is displayed. Or >> this is the way that I think tools like tcpdump deal with >> saved packet traces. It gives the user control over how the >> data is displayed, but the data in the file is in a general >> format. >> >> In this approach, a specific tool would always work to show >> the user consistent address formats and avoid the problems >> enumerated in the draft. For example, if a tool knew how to >> detect and show IPv6 addresses with embedded IPv4 addresses, >> it would show everything that way. If the tool didn't it >> would still provide the user a consistent view of the >> addresses. I think this is the overall intent of this draft. > > But this would mean losing the ability for a human to write > an address in the most appropriate way (which may or may not > show a dotted decimal suffix) and then store it in that format > for future use by both humans and software. And it would mean > that tools with misconceptions about valid WKPs would work > differently. That would break the Law of Least Astonishment. > >> I think this would be a better approach and allow us to solve >> the problem originally as intended when the w.g. took this >> work on. > > I thought we started this effort to help operators by reducing > confusion. Discarding dotted deimal when entered by a human will > not do that, IMHO. > > There's no doubt that internal searches and comparisons should > be done against the canonical representation, of course. But I > believe that dotted decimal MUST NOT be discarded by tools > if entered by a human. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktwBAIACgkQcrhTYfxyMkLEOACfSyJZAekdvLEJyWI9uFrup1GA idEAnj0oyyzRlzjQQ5EjGsocLA6cctOe =vXlP -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
