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

Carsten Bormann <cabo@tzi.org> Sat, 30 May 2015 06:46 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6860E1A92AD for <6lo@ietfa.amsl.com>; Fri, 29 May 2015 23:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.058
X-Spam-Level: ****
X-Spam-Status: No, score=4.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_TOOL=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mei2ICKpIXzh for <6lo@ietfa.amsl.com>; Fri, 29 May 2015 23:46:21 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A0F1A92AB for <6lo@ietf.org>; Fri, 29 May 2015 23:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4U6kISv004263; Sat, 30 May 2015 08:46:18 +0200 (CEST)
Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lzCw966fYz2clg; Sat, 30 May 2015 08:46:17 +0200 (CEST)
Message-ID: <55695CB7.3060703@tzi.org>
Date: Sat, 30 May 2015 08:46:15 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Jonathan Hui <jonhui@nestlabs.com>
References: <CAO6tK45jVMp=fC_RL6jZoQ=F4fL3GKuXOcG9u036Xsc0smVMDA@mail.gmail.com>
In-Reply-To: <CAO6tK45jVMp=fC_RL6jZoQ=F4fL3GKuXOcG9u036Xsc0smVMDA@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/6lo/_Lb-bu9aVm5kLXyClxJILaCQSck>
Cc: "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6lo] Fwd: [Technical Errata Reported] RFC4944 (4359)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2015 06:46:23 -0000

It is true that the RFC is not internally consistent here -- some
counterexamples to the ones you give here are Figure 2 and the text
   NALP:  Specifies that the following bits are not a part of the LoWPAN
      encapsulation, and any LoWPAN node that encounters a dispatch
      value of 00xxxxxx shall discard the packet

Nor is it consistent with the actual usage of the term "dispatch value"
in the literature, as can be seen e.g. in
http://solomon.ipv6.club.tw/Course/ProtocolEngineering/archrock-6lowpan-tutorial.pdf
or the 6LoWPAN book.

Also, there is no mandate that ESC-based dispatch values can only be
used for things other than mesh addressing and fragmentation.  There is
also no intention that the values 0 to 63 following ESC have the same
meaning as the dispatch values 01 000000 to 01 111111.

Expanding the confusing use of the term "dispatch value" just for the
six-bit field in 01 xxxxxx would be wrong.

Grüße, Carsten


Jonathan Hui wrote:
> I believe the Erratum under discussion is correct and should be marked
> as Verified.
> 
> The original intent of "Dispatch value" was:
> 1) To refer to the Dispatch field in the Dispatch Header - note the
> capitalization in "Allows support for Dispatch values larger than 127."
> 2) To identify a namespace that *excludes* the Mesh Addressing and
> Fragmentation headers.
> 
> The original draft text (draft-ietf-6lowpan-format-07) was less
> ambiguous about the original intent.  Referring to that draft:
> 
> 1) The draft separated the concept of "Header Type" from "Dispatch
> Value".  The draft defined Header Types: Dispatch, Mesh Delivery, and
> Fragmentation, and Dispatch Values: NALP, IPv6, LOWPAN_HC1, LOWPAN_BC0,
> and ESC.  The draft also includes the following text that indicates the
> Mesh Addressing and Fragmentation headers are not included in the
> dispatch value namespace:
> 
>    The definition of headers, other than mesh addressing and
>    fragmentation, in LoWPAN consists of the dispatch value, the
>    definition of the header fields that follow
> 
> Note that the text above still lives in RFC 4944.
> 
> 2) The bit pattern figure was titled "Dispatch Type Bit Pattern", not
> "Dispatch Value Bit Pattern", with the intent that the table only
> included the initial allocations within the Dispatch Header and did
> *not* include any mention of Mesh Delivery and Fragmentation headers.
> 
> --
> Jonathan Hui
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo