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

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

Brian Haberman wrote:
> 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 <rfc-editor@rfc-editor.org>
> To: gabriel.montenegro@microsoft.com,
> nandakishore.kushalnagar@intel.com, jhui@archrock.com,
> dculler@archrock.com, brian@innovationslab.net,
> terry.manderson@icann.org, geoff.ietf@mulligan.com, cabo@tzi.org
> CC: gabriel.montenegro@microsoft.com, 6lowpan@lists.ietf.org,
> rfc-editor@rfc-editor.org
> 
> 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 <gabriel.montenegro@microsoft.com>
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo