Subject: draft-ietf-6man-text-addr-representation AUTH48 change

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 04 Aug 2010 20:26:09 +0900

Hi

This already came up on the list once before,
and since its in AUTH48 now, I would like to
make the changes to the document.

Current section 4.2 has 3 parts, and the first two are

4.2.1.  Shorten as Much as Possible

   The use of the symbol "::" MUST be used to its maximum capability.
   For example, 2001:db8::0:1 is not acceptable, because the symbol "::"
   could have been used to produce a shorter representation 2001:db8::1.

4.2.2.  Handling One 16-Bit 0 Field

   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
   2001:db8::1:1:1:1:1 is not correct.

I would like to combine these two, and also clarify that you MUST
use "::" when there are more then two consecutive 0 fields.
The following is the text I plan to use.

4.2.1.  When to use "::"

   If the address contains at least two consecutive 16-bit 0 fields, "::"
   MUST be used to compress all consecutive 16-bit 0 fields.
   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
   2001:db8::1:1:1:1:1 is not correct.

Please let me know by Aug 6, 2010 if you have any objections to this.

Thanks and Regards,
Seiichi

---

From: "t.petch" <[email-masked]>
Date: Wed, 4 Aug 2010 16:04:21 +0200

I object.

I think that the existing text is clearer than the text you want to replace it
with.

Tom Petch

----- Original Message -----
From: "Seiichi Kawamura" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 04, 2010 1:26 PM
Subject: draft-ietf-6man-text-addr-representation AUTH48 change

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkxZTlAACgkQcrhTYfxyMkLNnACfbaXV00gkSPn0ZtsLvmgONr72
> 5WIAn0zKEaW61ab/H/jSWiAT80y7ORLT
> =kEsX
> -----END PGP SIGNATURE-----
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Wed, 4 Aug 2010 17:34:39 +0200

I think this is a mis-use of AUTH48; the working group has considered the draft and said what it wanted to say, and at this point the RFC Editor is asking you whether they changed the intent of the draft in the editing process or whether perhaps your address has changed. Changing the draft in a substantive way is out of scope of the question you are being asked.

> -----END PGP SIGNATURE-----

http://www.ipinc.net/IPv4.GIF

---

From: Роман Донченко <[email-masked]>
Date: Wed, 04 Aug 2010 19:39:55 +0400

Seiichi Kawamura <[email-masked]> писал в своём письме Wed, 04 Aug  

> Please let me know by Aug 6, 2010 if you have any objections to this.

This drops one of the examples, which makes it less informative. Plus, it  
sort of implies that all sequences of 0 fields must be shortened, which is  
not legal. I'd suggest moving 4.2.2 to 4.2.1 and merging 4.2.1 with 4.2.3  
instead. For example:

4.2.1.  Handling One 16-bit 0 Field

4.2.2.  Handling Consecutive 16-bit 0 Fields

    If the address contains at least two consecutive 16-bit 0 fields, "::"
    MUST be used to fully compress the longest run of consecutive 16-bit
    0 fields in the address. For example, 2001::1:0:0:0:1 is incorrect
    because the shorter run was compressed, and 2001:0:0:1::0:1 is
    incorrect because the run is only partially compressed. The correct
    representation is 2001:0:0:1::1. If there are two or more runs of
    the same maximal length, the first such run MUST be chosen. For
    example, 2001:db8::1:0:0:1 is a correct representation.

Regards,
Roman.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 11:33:36 -0400

Hi Tom,
   The existing text does not make it clear whether "::" MUST
always be used if there are at least two consecutive 16-bit 0 fields. 
This leads to ambiguity in address representations. Hence, I support the 
modified text that Kawamura-san proposed.

Cheers
Suresh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Aug 2010 17:56:10 +0200

On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:

> I think this is a mis-use of AUTH48; the working group has
> considered the draft and said what it wanted to say, and at this
> point the RFC Editor is asking you whether they changed the intent
> of the draft in the editing process or whether perhaps your address
> has changed. Changing the draft in a substantive way is out of scope
> of the question you are being asked.

So the idea is to publish the wording as is and once the RFC pops up
we file an errata that clarifies that the sentence

  The use of symbol "::" MUST be used to its maximum capability.

also implies that "::" MUST be used if there are at least two
consecutive 16-bit 0 fields. Or can we compromise on a less heavy
change, e.g. adding just before the quoted sentence.

  If at least two consecutive 16-bit 0 fields are present, the
  symbol "::" MUST be used.

This is a less invasive change (and I think the WG had previously some
concensus on this, but the WG chairs will know). But yes, the formally
correct procedure is likely the errata approach.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 04 Aug 2010 11:58:05 -0400

Seiichi,

     First off, this type of change is not appropriate for AUTH48.

>    2001:db8::1:1:1:1:1 is not correct.

Secondly, this text loses the context of Section 4.2.1 in that there is
no guidance on maximizing the compression.

Regards,
Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 12:15:56 -0400

Hi Brian,

>      First off, this type of change is not appropriate for AUTH48.

I am not certain whether this is appropriate, but I think this issue 
should be fixed before publication. Otherwise the document fails to 
achieve its stated goal. e.g. An address

2001:db8:0:0:0:0:2:1

can still show up as either

2001:db8:0:0:0:0:2:1 or 2001:db8::2:1

and still be compliant to this document.

My original suggestion to fix this was to add a sub section

4.2.0 Mandatory usage
    If the address contains at least two consecutive 16-bit 0 fields,
"::" MUST be used to compress consecutive 16-bit 0 fields as described
in the following sections.

I also like Roman's suggested text.

Cheers
Suresh

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Aug 2010 09:20:17 -0700

Seiichi,

These changes are out of scope for an AUTH48 change.  AUTH48 is only to verify the edits that the RFC-Editor performed and for other editorial changes.

If you really think these changes are very important, then the document would need to come back to the working group and restart the process.  Given the comments on the list, I wouldn't advise that.  It would mean another working group last call, AD review, IETF last call, IESG review, directorate reviews, RFC-Editor edit pass, etc.  

Bob

---

From: Brian Haberman <[email-masked]>
Date: Wed, 04 Aug 2010 13:08:06 -0400

> 2001:db8:0:0:0:0:2:1 or 2001:db8::2:1

I don't see how given the text in section 4.2.1 says that the symbol
"::" MUST be used to its maximum capability.

---

From: "t.petch" <[email-masked]>
Date: Wed, 4 Aug 2010 19:30:07 +0200

errrrrrrr

Tom Petch

----- Original Message -----
From: "Suresh Krishnan" <[email-masked]>
To: "Brian Haberman" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 04, 2010 6:15 PM
Subject: Re: draft-ietf-6man-text-addr-representation AUTH48 change

> 2001:db8:0:0:0:0:2:1 or 2001:db8::2:1

No it cannot
>>    The use of the symbol "::" MUST be used to its maximum capability.
tells me utterly and explicitly that the second of these two is right and that
the first is wrong! IMHO!

---

From: Fred Baker <[email-masked]>
Date: Wed, 4 Aug 2010 20:44:46 +0200

>  symbol "::" MUST be used.

So, 2001:0db8:0000:0000 : 0000:0300:0000:0000

could be encoded

    2001:0db8::0300::

Because in both cases there are adjacent fields of 0000

:-)

I agree that the way to fix this is either to withdraw and resubmit the draft or file an erratum. I suspect the sentence might need more work. The entire original purpose of the draft, as I understood it, was to clarify this type of example.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 14:46:10 -0400

Hi Tom,

> Subject: Re: draft-ietf-6man-text-addr-representation AUTH48 change
...
> the first is wrong! IMHO!

Not really. The text you quoted does not state whether "::" MUST always 
be used if it is possible to do so. It only states that when used, it 
must be used to the maximum capability.

Cheers
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Wed, 04 Aug 2010 15:21:56 -0400

Suresh,

> must be used to the maximum capability.

I disagree.  The rule plainly states that "::" must be used to its
maximum capability.  I view that as saying you must use it if it is at
all possible AND use it where it creates the highest level of
compression.  I don't see any wiggle room in the rule to allow someone
to not use "::" when it can be applied.

Regards,
Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 17:15:51 -0400

Hi Brian,

...
> to not use "::" when it can be applied.

Since we are reading the same text and coming up with different 
conclusions, I would argue that the text needs tightening. In fact this 
issue came up because of a post to the IPv6 mailing list by Brett Tate 
in April asking the exact same question.

http://www.ietf.org/mail-archive/web/ipv6/current/msg11684.html

The exact question he asked was

"Concerning "::" usage, is the requirement that
1) "::" MUST be used when valid, or
2) only that if used, it MUST be used to its maximum capability?"

Cheers
Suresh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Aug 2010 23:49:35 +0200

> Because in both cases there are adjacent fields of 0000

You have to read the whole text of course. Nice try.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Aug 2010 10:05:12 +1200

> 2) only that if used, it MUST be used to its maximum capability?"

It seems clear to me that
a) the text needs clarifying to answer this;
b) the clarification should be done in as few words as possible;
c) this is a substantive technical change, not editing;
d) the document is not fit for purpose without this clarification.

Therefore, I see no alternative to withdrawing the draft from
the RFC Editor, and going once more through the WGLC/IETF LC/IESG
process.

Sorry, but those are the rules of our game. If done smartly, it should
only take 6 or 7 weeks. And I thank the authors for their work; this
is a minor glitch.

   Brian Carpenter

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 05 Aug 2010 09:39:22 +0900

Its 9:00am in the morning in Tokyo
(my excuss for the late response)
and thanks to everyone for their comments.
I really have to appologise for the misuse of the AUTH48.

While most people would think that the original
text is good enough (at least that's
what we agreed on at first), I understand
that the question that was asked by Brett may be
asked by others.

I guess the question is, would an erratum be
sufficient to address this?

Regards,
Seiichi

> Please let me know by Aug 6, 2010 if you have any objections to this.
- --------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
- --------------------------------------------------------------------

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 05 Aug 2010 10:15:40 +0900

> correct procedure is likely the errata approach.

This is a very nice approach. So 4.2.1 would be like

   symbol "::" MUST be used, and used to its maximum capacity.

Regards,
Seiichi

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 05 Aug 2010 13:05:45 +0900

snip

> correct procedure is likely the errata approach.

This was bothering me a bit and I went back to past versions.
The Conclusion section (a terse version of section 4) was removed
in -05 becuase it was redundant, but that section stated

(5) do not shorten one 16 bit 0 field, but always shorten when
      there are two or more consecutive 16 bit 0 fields

which I admit is the more explicit than section4.

Regards,
Seiichi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Aug 2010 08:11:39 +0200

>    could have been used to produce a shorter representation 2001:db8::1.

I think this change makes it read better:

s/, and used/, and it MUST be used/

/js

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Aug 2010 14:32:21 -0700

After some discussion between the author, chairs, and Suresh who raised the issue, we think the following text will resolve the issue and can be done in AUTH48:

  The use of the symbol "::" MUST be used to its maximum capability. 
  For example, 2001:db8:0:0:0:0:2:1 must be shortened to
  2001:db8::2:1.  Likewise, 2001:db8::0:1 is not acceptable, because the symbol
  "::" could have been used to produce a shorter representation
  2001:db8::1. 

We think this is OK for an AUTH48 change as it is adding an example to clarify the issue and not changing the rule itself.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Aug 2010 09:42:51 +1200

> We think this is OK for an AUTH48 change

I agree, we can call this editorial.

Regards
   Brian Carpenter

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Aug 2010 15:25:54 +0300

The latest version from Bob works for me, and I also agree this can be 
done in AUTH48.

I also wanted to comment on the process. Sometimes we do hit issues in 
AUTH48. Small changes, even technical, may be doable in AUTH48, but they 
should always be confirmed with the working group, and sometimes with 
the IESG. I will let the IESG know about this change.

There are a couple of ground rules, however. Sometimes we see a desire 
from the over-eager authors to rewrite or reformat large parts of their 
drafts; there shall be no such activity because it would be impossible 
to verify the result.. I like Bob's text because the change is small and 
local. Combining and moving sections around would not be OK. Also, a 
technical change must have a justification, usually we are talking about 
clear errors. This is also the case with this document. Finally, the 
working group has to have consensus about the change. Bob's e-mail came 
out a few days ago; I think we should wait a few more days just to 
ensure that everyone has had time to process the change and complain.

Jari