Subject: [6lo] Fwd: [Technical Errata Reported] RFC4944 (4359)

From: Brian Haberman <[email-masked]>
Date: Thu, 28 May 2015 08:04:26 -0400

All,
     I would like feedback on this erratum.  It appears to be correct,
in my view.  Any objections to me marking it Verified?

Regards,
Brian

-------- Forwarded Message --------
Subject: [Technical Errata Reported] RFC4944 (4359)
Date: Thu,  7 May 2015 12:07:39 -0700 (PDT)
From: RFC Errata System <[email-masked]>
To: [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked], [email-masked]
CC: [email-masked], [email-masked],
[email-masked]

The following errata report has been submitted for RFC4944,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4944&eid=4359

--------------------------------------
Type: Technical
Reported by: Gabriel Montenegro <[email-masked]>

Section: 5.1

Original Text
-------------
   ESC:  Specifies that the following header is a single 8-bit field for
      the Dispatch value.  It allows support for Dispatch values larger
      than 127.

Corrected Text
--------------
   ESC:  Specifies that the following header is a single 8-bit field for
      the Dispatch value.  It allows support for Dispatch values larger
      than 63.

Notes
-----
The (non-ESCaped) Dispatch value is a 6-bit selector. However, it used
to be a 7-bit selector, which has a value at most 127. When the field
became a 6-bit selector, this maximum became 63, but the referring text
was never updated.

For historical reference, see an early version from IETF 67 proposing
the Dispatch value within the Dispatch header as a 7-bit field:

http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=view&target=tentative-draft2-ietf-6lowpan-format-07.txt

   The dispatch type is defined by a zero-bit as the first bit.  The
   dispatch type and header is shown here:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  Dispatch   |  type-specific header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dispatch               7-bit selector.  Identifies the type of header
                          immediately following the Dispatch type.

The relevant slides also show this (slide 8):
http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=view&target=6lowpan-header-proposal-2.ppt

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4944 (draft-ietf-6lowpan-format-13)
--------------------------------------
Title               : Transmission of IPv6 Packets over IEEE 802.15.4
Networks
Publication Date    : September 2007
Author(s)           : G. Montenegro, N. Kushalnagar, J. Hui, D. Culler
Category            : PROPOSED STANDARD
Source              : IPv6 over Low power WPAN
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

-- 
This message has been scanned for viruses and dangerous content by
E.F.A. Project, and is believed to be clean.

Click here to report this message as spam.
http://efa.daedelus.com/cgi-bin/learn-msg.cgi?id=97F1D60054.A616F&token=a00583b5361cce8776745f1ea05415c9

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 May 2015 08:31:24 -0400

Looks OK to me.  I have no objection to marking it Verified.

> On May 28, 2015, at 8:04 AM 5/28/15, Brian Haberman <[email-masked]> wrote:
> 
> All,
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 May 2015 14:55:55 +0200

Actually, the dispatch field is the first byte of the IEEE 802.15.4 payload.
There are various allocations for this first byte, see Figure 2 of RFC 4944:

           Pattern    Header Type
         +------------+-----------------------------------------------+
         | 00  xxxxxx | NALP       - Not a LoWPAN frame               |
         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
         | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
         | 01  000011 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 01  001111 | reserved   - Reserved for future use          |
         | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |
         | 01  010001 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 01  111110 | reserved   - Reserved for future use          |
         | 01  111111 | ESC        - Additional Dispatch byte follows |
         | 10  xxxxxx | MESH       - Mesh Header                      |
         | 11  000xxx | FRAG1      - Fragmentation Header (first)     |
         | 11  001000 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 11  011111 | reserved   - Reserved for future use          |
         | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|
         | 11  101000 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 11  111111 | reserved   - Reserved for future use          |
         +------------+-----------------------------------------------+

                   Figure 2: Dispatch Value Bit Pattern

There are a number of slightly strange phrasings in RFC 4944 where
allocations of the dispatch field are described and the term "dispatch"
is then used for the variable part of the range (as that part is the
"dispatch" value within that range).

So, for me the errata is that the text talks about extending the range
of (8-bit) dispatch values (which ESC is not about), instead of saying
that ESC together with the next byte opens up a completely new dispatch
space.

Grüße, Carsten

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 28 May 2015 19:43:30 +0000

Hi Carsten,

 >       the Dispatch value.  It allows support for Dispatch values larger

I interpret the current text as already implying that (as you say) "ESC together with the next byte opens up a completely new dispatch space".

It does so when it says: "ESC:  Specifies that the following header is a single 8-bit field for the Dispatch value. "

The word *following* (current wording) ties both *together* (your wording).

At any rate, feel free to file an errata for that sentence. The errata under discussion in this thread is on the 2nd sentence, in particular, the change of 127 to 63. Regardless of what happens on the first sentence (if you go ahead with your errata on it), the change in the second sentence would hold, so I view both as independent errata. 

Thanks,

Gabriel

---

From: James Woodyatt <[email-masked]>
Date: Thu, 28 May 2015 12:48:38 -0700

On Thu, May 28, 2015 at 5:55 AM, Carsten Bormann <[email-masked]> wrote:

> [...]

This Erratum is about clarifying that the specific mistake in section 5.1
where the number 127 appears when the original intent seems clearly to have
been 63 as shown by the revision history during the development of the
draft, i.e. that it is meant to be talking about the 6-bit type selector
field in the Dispatch value.

I agree that RFC 4944 and RFC 6282 have a lot of confusing language
regarding the semantics of the ESC Dispatch code, but I don't see how to
address those problems in an Erratum. Presumably, those things will be
cleared up when we have an RFC that actually defines how the code reserved
in RFC 6282 for the purpose will actually be used.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 28 May 2015 15:51:31 -0400

I agree with Carsten; this section can be puzzling so I think more
discussion is
warranted before marking as Verified.

First, we should note that the assignment of 01 111111 for ESC has been
deprecated
(but is still referenced) by RFC 6282 and should not be used for that
purpose in new
implementations.

Second, it is not clear whether the replacement text should say "larger
than 63" or
"larger than 255".  RFC 4944, section 5.1 seems to alternately describe
Dispatch
Value as a six bit or eight bit field (cf Figure 2).

Lastly, the sentence under consideration may have propagated to other 6lo
proposals.
I know it's in 6LoBAC.

Kerry

On Thu, May 28, 2015 at 3:43 PM, Gabriel Montenegro <
[email-masked]> wrote:

> I interpret the current text as already implying that (as you say) "ESC
> together with the next byte opens up a completely new dispatch space".
>
> It does so when it says: "ESC:  Specifies that the following header is a
> single 8-bit field for the Dispatch value. "
>
> At any rate, feel free to file an errata for that sentence. The errata
> under discussion in this thread is on the 2nd sentence, in particular, the
> change of 127 to 63. Regardless of what happens on the first sentence (if
> you go ahead with your errata on it), the change in the second sentence
> would hold, so I view both as independent errata.
>
> Thanks,
>
> Gabriel

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 29 May 2015 00:31:55 +0000

I think you guys are confusing a revision with an errata. No question that further clarification is a very good idea, and we are already thinking about that, but that is out of scope for an errata. It’s addressed by publishing a new RFC.

But this thread is not about a revision and larger clarification but about an error made at the time of the writing: 127 should have been 63.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 May 2015 07:46:23 +0200

> 127 should have been 63.

There are 256 dispatch byte values.
Not 127, 63, 128, or 64.

(Adding the ESC construct, there are 511.)

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Fri, 29 May 2015 18:00:35 +0100

+1 to 256 (further) dispatch byte values. Carsten has it right.

Robert

---

From: James Woodyatt <[email-masked]>
Date: Fri, 29 May 2015 11:37:35 -0700

On Thu, May 28, 2015 at 10:46 PM, Carsten Bormann <[email-masked]> wrote:

> [Gabriel Montenegro wrote:]

....127 should have been 63.
> There are 256 dispatch byte values.

I agree with Gabriel. The original intent of the authors of RFC 4944 at the
time was for this to read 63 not 127, and it is an error worth noting with
an erratum.

I also agree with others who say that the term "dispatch value" is
confusing in RFC 4944 and it isn't clarified satisfactorily in any of the
updates. I would support the working group choosing to develop an update
that clarifies this terminology.

> (Adding the ESC construct, there are 511.)

That's a possibility. It's the case that RFC 6282 takes away the ESC
construct and replaces it with a reserved code for us to define how many
additional codes are available. Yes, 511 is an option. There are others
available.

I hope we can have that discussion apart from the question of whether this
very specific and particular error in RFC 4944 can be officially
recognized. I hope we don't block the publication of an erratum because we
can't agree on what the correct text should be now, apart from what we
meant at the time.

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 May 2015 17:59:39 -0400

On Fri, May 29, 2015 at 2:37 PM, James Woodyatt <[email-masked]> wrote:

> I agree with Gabriel. The original intent of the authors of RFC 4944 at
> the time was for this to read 63 not 127, and it is an error worth noting
> with an erratum.
>
> I agree with Carsten on this one.  If the original intent of the authors
was for this to read
63, they wouldn't have included a table of "Dispatch Value Bit Patterns"
with 256 entries.
(Or is a "Dispatch Value Bit Pattern" different from a "Dispatch type field
value"?)

> that clarifies this terminology.
If the errata was clarifying, I could support it.  My position is that we
should either fix the
whole section or leave it alone.

> My take is that RFC 6252 re-assigns the ESC codepoint, but maybe that's
what you meant.

> I think the current discussion is about whether the proposed text is
correct.  It serves no purpose
to replace an error with another error.  If folks are determined to fix
this section one sentence at
a time, then a more neutral alternative might be:

   ESC:  Specifies that the following header is a single 8-bit field for
      the Dispatch value.  It allows support for extended Dispatch value
      bit patterns.

Kerry

---

From: James Woodyatt <[email-masked]>
Date: Fri, 29 May 2015 16:09:06 -0700

Kerry—

I appreciate that your position is we should either A) provide a complete
fix for the confusing text in RFC 4944 by issuing an update, or B) not make
any corrections whatsoever.

I certainly believe we should do option A in addition to verifying the
proposed erratum. I don't see why both cannot be done. Perhaps you could
explain why you take such an inflexible position. It's not clear to me what
damage would be done by us quickly issuing an erratum, intended to correct
the error noted in the current report that the number 127 should have been
changed to 63 when the width of the corresponding dispatch type selector
field was reduced in size from seven bits to six, followed by a more
extended discussion about how to provide the complete fix for clarifying
the terminology around the Dispatch value and its type selector field, as
well as defining how the ESC code is to be used.

On Fri, May 29, 2015 at 2:59 PM, Kerry Lynn <[email-masked]> wrote:

> (Or is a "Dispatch Value Bit Pattern" different from a "Dispatch type
> field value"?)
>
>
>> I hope we can have that discussion apart from the question of whether
>> this very specific and particular error in RFC 4944 can be officially