Subject: next steps with 6man-text-addr-representation

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Feb 2010 14:53:38 +0200

This draft was on the IESG review yesterday, and did not get approved 
due to a number of Discusses from the other ADs.

There's a number of small details that we can talk about separately, but 
I wanted to talk to the working group about the high level issues. 
Generally speaking the reviewers were surprised about the lack of 
preciseness in the definition of the canonical form. This had to do with 
the IPv4-embedded addresses, the specification style and lack of MUST 
keywords, and so on. I think everyone believed the draft as currently 
written will already improve things, but many reviewers felt that it 
could have been much stricter. The reviewers were also wondering about 
the role of the draft, will it affect everything or just other 
specifications that decide to adopt the new format.

I explained the situation with the IPv4-embedded addresses -- this is a 
design tradeoff where we can either nail down everything now and not 
have a nice textual representation in some cases, or we can leave some 
flexibility. We've already had this discussion in the working group, and 
I believe we keep the current approach in the draft. However, we need to 
add the rationale to the draft so that future readers are not asking the 
same questions as our reviewers did now.

Then we talked about the strictness. I explained that this is largely a 
specification style issue, and in the real world there will always be 
old code that doesn't produce the canonical form, and that we hope that 
this RFC will convince all new code to do the right thing. However, we 
came up with the following proposal to make the specification stricter:

- Use RFC 2119 language and MUST. Implementations conforming to this 
specification MUST ...
- Provide a reference to the currently defined WKPs
- In the section that talks about ports, please make sure that for URIs 
everyone MUST follow RFC 3986, and for the rest, the default can be 
again RFC 3986. The current language leaves everything open, even for URIs.
- There's a part about reducing longest sequence of 0s -- it would be 
great if we could point to some publicly available code that already 
does this, as an informational reference to implementors
- We will keep the specification on the Standards Track, i.e., publish 
it as a Proposed Standard
- This specification Updates RFC 4291

Would these changes be acceptable to the working group?

Jari

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Feb 2010 00:17:05 +1100

> does this, as an informational reference to implementors

ISC's inet_ntop() was released in 1996 as part of BIND 8.  It's also in
BIND 9.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Feb 2010 15:32:15 +0200

Mark,

> ISC's inet_ntop() was released in 1996 as part of BIND 8.  It's also in

Ah, great! Thanks for the information.

Jari

---

From: Bob Hinden <[email-masked]>
Date: Fri, 5 Feb 2010 12:47:20 -0800

Jari,

> Then we talked about the strictness. I explained that this is largely a specification style issue, and in the real world there will always be old code that doesn't produce the canonical form, and that we hope that this RFC will convince all new code to do the right thing. However, we came up with the following proposal to make the specification stricter:
> 
> - Use RFC 2119 language and MUST. Implementations conforming to this specification MUST ...
> - In the section that talks about ports, please make sure that for URIs everyone MUST follow RFC 3986, and for the rest, the default can be again RFC 3986. The current language leaves everything open, even for URIs.
> - There's a part about reducing longest sequence of 0s -- it would be great if we could point to some publicly available code that already does this, as an informational reference to implementors
> - We will keep the specification on the Standards Track, i.e., publish it as a Proposed Standard

[No hats on]

I was thinking about this over the past few days after reading the IESG comments and a discussion with Brian Haberman.  My personal take is that we lost sight of the original goal while trying to meet the broad requirements of the different variants of embedded addresses.

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.

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 would appreciate your and the w.g.'s comments.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Feb 2010 10:04:32 +1300

[repeating  with the CC's this time]

On 2010-02-06 01:53, Jari Arkko wrote:
...
> - Use RFC 2119 language and MUST. Implementations conforming to this

No real objection, but its impact of this change in the real world
will be nil IMHO.

> again RFC 3986. The current language leaves everything open, even for URIs.

We have to phrase this rather carefully. There is valid normative ABNF
for the RFC 4291 representation in RFC 3986, but it does not generate
only the proposed canonical representation. It allows leading zeroes,
for example, and allows zeroes instead of ::.

Also, I just came across something "interesting". RFC 3986 cites RFC 2234.
In the latter, we find
HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Unfortunately, that means that the URI format (and dependencies such
as SIP) don't allow lower case hex. That is inconsistent with
the current draft. Oops.

[Note to self - this also messes up draft-ietf-sip-ipv6-abnf-fix-04,
of which I'm a co-author.]

> does this, as an informational reference to implementors

Seichi has some code
http://tools.bgp4.jp/IPv6canonical/IPv6canonical.txt

> - This specification Updates RFC 4291

In that case we need to state explicitly that lower case hex is
allowed; 4291 only shows upper case examples.

---

From: Роман Донченко <[email-masked]>
Date: Sat, 06 Feb 2010 00:14:39 +0300

Brian E Carpenter <[email-masked]> писал в своём письме Sat,  

> of which I'm a co-author.]

ABNF string literals are case-insensitive.

Roman.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Feb 2010 11:37:20 +1300

On 2010-02-06 10:09, Alexey Melnikov wrote:
> Hi Brian,

...
> Actually no, all quoted strings in ABNF are case-insensitive. So "A"
> matches both "A" and "a", etc.

Oh, OK, that is fine for conformance of course, but leaves things
open when you are talking about generating strings. If we want the
new recommendation to be a MUST, we may have to consider wording to
make it clear how widely it applies. Many existing specs may be
affected implicitly.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Feb 2010 11:51:03 +1300

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
> 
> 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:
> 
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Feb 2010 11:53:13 +1300

On 2010-02-06 10:14, Роман Донченко wrote:
> Brian E Carpenter <[email-masked]> писал в своём письме
> Sat, 06 Feb 2010 00:04:32 +0300:
> 

As I noted to Alexey, that's fine for conformance but not
for generation.

   Bian

---

From: Doug Barton <[email-masked]>
Date: Fri, 05 Feb 2010 15:59:11 -0800

> make it clear how widely it applies. Many existing specs may be

Would something like this work?

In the absence of a conflicting specification, ... MUST ... At the time
of this writing the following specifications are known to conflict: <list>

Doug

PS, I'm sure the thought has occurred to others already, but the fact
that something like this has become so complicated is almost certainly a
symptom that something is wrong on a more fundamental level ....

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

	Computers are useless. They can only give you answers.
			-- Pablo Picasso

---

From: Bob Hinden <[email-masked]>
Date: Fri, 5 Feb 2010 16:19:00 -0800

Doug,

> of this writing the following specifications are known to conflict: <list>

That's essentially the definition of SHOULD.  It's what you do unless there is a compelling reason not to do it.

Bob

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Feb 2010 21:09:06 +0000

Hi Brian,

Brian E Carpenter wrote:
 [...]

>of which I'm a co-author.]
 [...]

>allowed;
Showing such examples would be fine, but see above.

>4291 only shows upper case examples.
>  
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Feb 2010 10:40:21 +1300

> That's essentially the definition of SHOULD.  It's what you do unless there is a compelling reason not to do it.

[Digression: a sad fact of life is that this is what MUST means
in practice. And SHOULD means "product managers who are short
of programmers MAY leave this out".]

I was rather thinking that we have to say MUST (as the IESG
wishes) and then add something like:
 The following specifications, among others, are affected by
 this requirement: RFC 3986, ...
I think this will demonstrate the scope of this change from
SHOULD to MUST.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Sat, 06 Feb 2010 18:19:39 -0800

> of programmers MAY leave this out".]

Heh.

> I think this will demonstrate the scope of this change from

Yeah, I was opposed to there even being a SHOULD in 2119, but IIRC I
never even bothered to voice that opinion. There are only so many
windmills I can tilt at.

However, getting away from the digression to the digression to the
digression, FWIW I agree with your suggestion Brian, and I would have
also preferred "MUST" from the beginning in any case.

Doug

--

---

From: Lars Eggert <[email-masked]>
Date: Mon, 8 Feb 2010 12:06:08 +0200

Hi,

what Bob outlines below is pretty exactly what I thought the intent of this ID was supposed to be, and going in this direction would certainly address my discuss.

Lars

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 08 Feb 2010 20:38:03 +0900

Finally catching up to the thread...
It is mentioned in the Appendix that
inet_ntop is a good code reference.

There's also ipv6calc
http://www.deepspace6.net/projects/ipv6calc.html

Regards,
Seiichi

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 08 Feb 2010 21:30:58 +0900

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.

>> would not support any of the embedded formats.  Everything

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

---

From: Ralph Droms <[email-masked]>
Date: Mon, 8 Feb 2010 07:57:40 -0500

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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAktwBAIACgkQcrhTYfxyMkLEOACfSyJZAekdvLEJyWI9uFrup1GA
> idEAnj0oyyzRlzjQQ5EjGsocLA6cctOe
> =vXlP
> -----END PGP SIGNATURE-----

---

From: Seiichi Kawamura <[email-masked]>
Date: Tue, 09 Feb 2010 09:02:07 +0900

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 8 Feb 2010 13:19:45 -0500

+1