-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ralph
Ralph Droms wrote: > Seiichi - I agree that (1) and (2) are appropriate goals for this draft > and that those two goals have different requirement levels. > > It seems to me that there is value in describing the representation and > the application of the standard can be separated, so that the > representation itself is described with "MUST" and "MUST NOT" language, > while the applications can be described with "SHOULD" or "If the > <application, document, etc.> is compliant with the standard > representation...". The key, I think, is that the specification of the > representation should be unambiguous, while the specification can be > applied selectively Thanks. I agree to this. Let me try to revise the draft and I'll send to the list once I'm done. Regards, Seiichi > > - Ralph > > On Feb 8, 2010, at 7:30 AM 2/8/10, Seiichi Kawamura wrote: > > 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 >>>> [email protected] >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktwpf8ACgkQcrhTYfxyMkIuLgCeLAgzmXrjowUiUMSuxRU590uD /iwAniN58Ud6mbeW98cbpbSb6trfmV7b =GrOM -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
