Re: [6lo] Last Call: <draft-ietf-6lo-dispatch-iana-registry-06.txt> (6lowpan ESC Dispatch Code Points and Guidelines) to Proposed Standard

worley@ariadne.com (Dale R. Worley) Fri, 18 November 2016 01:48 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48321129429 for <ietf@ietfa.amsl.com>; Thu, 17 Nov 2016 17:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 E8epv8PLeGvc for <ietf@ietfa.amsl.com>; Thu, 17 Nov 2016 17:48:53 -0800 (PST)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 DCFCA129622 for <ietf@ietf.org>; Thu, 17 Nov 2016 17:48:52 -0800 (PST)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-09v.sys.comcast.net with SMTP id 7YI4cJhap1XXB7YIOc7YRV; Fri, 18 Nov 2016 01:48:52 +0000
Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-04v.sys.comcast.net with SMTP id 7YIMcIRrCexjq7YINcZ1vN; Fri, 18 Nov 2016 01:48:52 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uAI1moXw025943; Thu, 17 Nov 2016 20:48:50 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uAI1moUk025940; Thu, 17 Nov 2016 20:48:50 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: ietf@ietf.org
Subject: Re: [6lo] Last Call: <draft-ietf-6lo-dispatch-iana-registry-06.txt> (6lowpan ESC Dispatch Code Points and Guidelines) to Proposed Standard
In-Reply-To: <147935783336.23923.6753600465148661016.idtracker@ietfa.amsl.com> (iesg-secretary@ietf.org)
Sender: worley@ariadne.com
Date: Thu, 17 Nov 2016 20:48:50 -0500
Message-ID: <87oa1dv9q5.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfEJpsQjAfK3gtgY9SAPKPh4osZhIJh43WKR+FvcGKKgEAc+uu7g7JLnqUC1tR9vw4sqlr1rJYMGKlQ7lSVAGRna7H9yOzWrb6/2bt3pXNkthnVr+aErM exd6TbWQsF8+imBrM6/ucCWKapFa5r/89RJmS+cBGJb33S2RjiOciZ+fEFdSfPAmiR5swNv/nFV9cXXChegn5ZOsAi/os3KzpzHOQ84kL9N5b2vsFIYNhIEc cBlW4mx06Z/+iyvfUg2CnQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZZrqFNF_pQKcPO3OCt30M-4yO1s>
Cc: draft-ietf-6lo-dispatch-iana-registry@ietf.org, 6lo@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2016 01:48:54 -0000

Comments on draft-ietf-6lo-dispatch-iana-registry-06.

All of these comments are editorial, though in one or two cases, the
editorial change should make the technical content considerably clearer.

This document uses "byte" where the general practice seems to be to
use "octet".  Which term should we use (and why)?

In several places, the dispatch values and the extension types are
said to be "orthogonal code spaces".  It seems to me that this is not
quite correct, as generally two things are said to be "orthogonal"
only if all possible values of one can be combined with all possible
values of the other, and that concept makes no sense in this context.
A better term would be "are in separate number spaces".  That change
results in:

3.  Usage of ESC dispatch bytes

   Thus, ESC extension types and dispatch values are in different
   number spaces.

3.4.  NALP and ESC bytes

   Since ESC bytes are part of 6lowpan dispatch types (extended), they
   are in a different number space from NALP bytes.

--

The general practice seems to be to capitalize "all important words"
in section titles (vs. capitalizing only the first word).  In that
case, the title of section 3 should be "Usage of ESC Dispatch Bytes",
and the title of section 3.1 should be "Interaction with Other RFC4944
Implementations".

--

1.  Introduction

   RFC 6282 modifies the value of the ESC dispatch type and it
   is recorded in IANA registry [6LOWPAN-IANA].

This would be clearer if "it is recorded" was "that value is
recorded".

3.  Usage of ESC dispatch bytes

   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 1| ESC       | ESC EXT Type  | Extended Dispatch Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Frame Format with ESC Byte

   ESC: The left-most byte is the ESC dispatch type containing
   '01000000'

This diagram is awkward, as the text suggests that "ESC" is
"01000000", whereas the figure shows "ESC" to be bits 2-7, which are
"000000".  I think this would be clearer and more correct if the
figure was

   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 1 0 0 0 0 0 0| ESC EXT Type  | Extended Dispatch Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and the text was

   The left-most byte is the ESC dispatch type containing '01000000'.

An alternative would be

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ESC           | ESC EXT Type  | Extended Dispatch Payload
   |0 1 0 0 0 0 0 0|               |                           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--

   Extended Dispatch Payload(EDP): This part of the frame format must be
   defined by the corresponding extension type.

There should be a space before "(EDP)".

   Section 5.1 in RFC4944 indicates that the Extension Type field may
   contain additional dispatch values larger than 63, as corrected by
   [4944-ERRATA].  For the sake of interoperability, the new dispatch
   type (EET) MUST NOT modify the behavior of existing dispatch types
   [RFC4944].

This doesn't seem to truly capture what has happened.  This seems
better:

   Section 5.1 in RFC4944 envisions the Extension Type field as
   providing a following 8-bit byte to contain a dispatch type, as
   opposed to the normal 6-bit field in the dispatch byte.  In that
   model, extension types are in the same number space as the dispatch
   values.  This document defines the Extension Type field as an 8-bit
   field whose values are in a different number space from dispatch
   values.  Thus, an implementation MUST process dispatch values and
   Extension Types according to the distinct definitions of those
   number spaces, and the definition of an Extension Type does not
   change the definition of the numerically equal dispatch value.

3.1.  Interaction with other RFC4944 implementations

   It is expected that RFC4944 existing implementations are not capable

Probably change "RFC4944 existing implementations" to "existing
implementations of RFC4944".

   Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension
   bytes may appear in a packet.

I think the words "Sequence Of dispatch bytes and ESC bytes:" don't
add much and can be deleted.

3.2.  ESC Extension Bytes Typical Sequence

It's not clear to me what the purpose of this section is.  To some
degree, it seems to list some examples of ESC usage ("Typical
Sequence") but it also seems to want to define when ESC can be used
("sequence and order ... are described below").  Really, where a
particular EET can appear is defined by the specification of that
particular EET, and what can appear after a particular EET is also
defined in that specification.  So there really can't be any *generic*
specification of how ESC can be used.

However, if this section is kept, Figure 2 should be regularized,
e.g., as:

   A LoWPAN encapsulated IPv6 Header compressed packet:

   +-------+------+--------+----------+-----------------+--------+
   | ESC   | EET  | EDP    | Dispatch | LOWPAN_IPHC hdr | Payld  |
   +-------+------+--------+----------+-----------------+--------+

   A LoWPAN_IPHC Header, Mesh header and an ESC extension byte:

   +-------+-------+-----+-----+-----+----------+-
   | M Typ | M Hdr | ESC | EET | EDP | Dispatch | 
   +-------+-------+-----+-----+-----+----------+-

	   -+-----------------+-------+
	    | LOWPAN_IPHC hdr | Payld |
	   -+-----------------+-------+

   A Mesh header with ESC bytes
   +-------+-------+-----+-----+-------+
   | M Typ | M Hdr | ESC | EET | EDP   |
   +-------+-------+-----+-----+-------+

   With Fragment header

   +-------+-------+--------+-------+------+-----+-------+
   | M Typ | M Hdr | F Typ  | F hdr | ESC  | EET |  EDP  |
   +-------+-------+--------+-------+------+-----+-------+

   ESC byte as a LowPAN encapsulation

   +--------+--------+--------+
   | ESC    | EET    | EDP    |
   +--------+--------+--------+

3.3.  ITU-T G.9903  ESC type usage

   The ITU-T recommendation
   defines command IDs in the [G3-PLC] section 9.4.2.3 which operates
   like ESC Extension type field.  The command ID values are 0x01 to
   0x1F.

Less awkward is:

   The ITU-T recommendation [G3-PLC] section 9.4.2.3 defines commands
   which are formatted like like ESC Extension type fields.  The
   command ID values are 0x01 to 0x1F.

4.  IANA Considerations

   The allocation of code points should follow the guidelines on "Usage
   Of ESC Dispatch Bytes" and the typical example sections.

This version of the title of section 3 doesn't match the section itself.

Dale