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
- Ralph
On Feb 8, 2010, at 7:30 AM 2/8/10, Seiichi Kawamura wrote:
-----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
[email protected]
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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
