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

[Dale R. Worley]

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

[sajjad akbar]

Hi

Can anyone recommend me a draft where routing issues are discussed in 6lo?
I am working on link metrics for routing in low-power networks and it will
help me to align my research according to some standard.

Looking forward for the reply

Regards
Sajjad

The IESG has received a request from the IPv6 over Networks of
- '6lowpan ESC Dispatch Code Points and Guidelines'
<draft-ietf-6lo-dispatch-iana-registry-06.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
beginning of the Subject line to allow automated sorting.
Abstract
RFC4944 defines the ESC dispatch type to allow for additional
dispatch bytes in the 6lowpan header. The value of the ESC byte was
updated by RFC6282, however, its usage was not defined either in
RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by
defining the ESC extension byte code points including registration of
entries for known use cases at the time of writing of this document.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-dispatch-iana-registry/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-dispatch-
iana-registry/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
6lo mailing list
https://www.ietf.org/mailman/listinfo/6lo

[james woodyatt]

Post by Dale R. Worley
Comments on draft-ietf-6lo-dispatch-iana-registry-06.

Thank you for reviewing this draft! I’m composing this response as a collation of the discussion between the other authors and me. A new revision that we believe addresses many of your comments is forthcoming, and we look forward to any additional comments you can provide us.

Post by Dale R. Worley
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)?

It’s complicated, and there is a historical legacy here. The history is that “byte” and “octet” have been used interchangeably in RFC 4944 and RFC 6282 when the word “octet” is more precise. The complication is that the phrases “dispatch byte” and “dispatch value” have slightly different technical meanings implied by the text in RFC 4944. After some discussion we decided not to expand on the explanation of the issue in the errata for RFC 4944, and simply global search and replace “octet” for “byte” throughout this draft. This continues the convention established in RFC 6282 of using the special phrase “dispatch octet” as a synonym for “dispatch byte” and we expect this meaning to be inferred by readers and for it therefore not to require any further expansion. Of course, we expect the RFC Editor to have the last word on this topic.

On a related note, we will also change all instances of the special phrase “ESC byte” accordingly to the phrase “ESC dispatch type” which was introduced in RFC 6282 when the ESC mechanism was redefined from RFC 4944. It’s perhaps not as clear as we’d all like, but it has the merit of having already been used consistently for this purpose in RFC 6282.

Post by Dale R. Worley
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.
[
]

We think leaving this question for the RFC Editor to decide is appropriate.

Post by Dale R. Worley
--
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”.

We think leaving this question for the RFC Editor to decide is appropriate.

Post by Dale R. Worley
--
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”.

Done.

Post by Dale R. Worley
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”.

We agree. Changing to this:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Figure 1: Frame Format with ESC dispatch type

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

Post by Dale R. Worley
--
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)”.

Done.

Post by Dale R. Worley
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. [
]

After some discussion, we decided to leave this "MUST NOT" the way it is written (as a requirement on specifications of future EET semantics), and not attempt to reverse this into a MUST requirement (on implementations of 6LoWPAN processors). The purpose of this statement is to encourage the use of I-D.ietf-6lo-paging-dispatch to introduce new dispatch types rather than to define ESC Extension Type (EET) values to modify the semantics of existing dispatch types. I’m not sure what would improve the clarity of this statement.

Post by Dale R. Worley
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”.

Done.

Post by Dale R. Worley
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.

Done.

Post by Dale R. Worley
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.

We think leaving this question for the RFC Editor to decide is appropriate.

Post by Dale R. Worley
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 [
]

We agree this is awkward. It will be improved.

Post by Dale R. Worley
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.

Corrected.

--james woodyatt <***@google.com <mailto:***@google.com>>