Ralph Droms wrote:
>> On May 1, 2015, at 6:53 PM 5/1/15, Carsten Bormann <cabo@xxxxxxx> wrote:
>>
>> Ralph Droms wrote:
>>> ITU-T G.9903
>> Thanks for bringing this discussion to a technical level. So this
>> document has allocated the dispatch code ESC (RFC 6282's value of
>> 01_000000) for the specific purposes of G.9903 ("command frames").
>
> In my opinion, G.9903 defines the values 0x01-0x1f in the byte following the ESC Dispatch Type. The other values are still available for use in other protocols.
That's one way to read it, but not quite the way that I get from a
literal read.
It says (9.4.2.3.1):
»As shown in Figure 9-12, the ADP sublayer command frames are identified
using the ESC header type (see clause 5.1 of [IETF RFC 4944]), followed
by an 8-bit dispatch field indicating the type of ADP command.«
So all 256 values are meant to indicate a specific type of ADP command
frame. Table 9-35 then goes ahead and allocates 31 values of those;
with a gap, so it identifies some as "Reserved by ITU-T".
(I'm not sure I understand the way G.9905 uses this command frame
concept for source routing; it says the command frame carrying the
source route header is "attached to the packet", but it doesn't quite
tell how both the command frame and the packet are transported, given
that "This header" (the command frame header) "shall be in the last
position if more than one header is present in the 6LowPAN frame."
according to 9.4.2.3.1 of G.9903. I also don't understand how mesh
headers and those source routes mix, or how a forwarding node knows
where in that source route it is. Oh well, there is probably nothing
there that 6lo would want to steal, anyway.)
However we read this, I agree that it does make a lot of sense to get
the protocol codes used by ITU-T into the IANA registries, and that we
should work with SG-15 to get this done.
(We do indeed disagree about the usefulness of being able to interpret
protocol syntax when there is no way to act on the semantics required
for handling the packet at all. Self-describing syntax is certainly
good for wireshark etc., and it helps with hardware implementations. It
is not a categorical imperative, however.)
Grüße, Carsten