(Dropping ietf(_at_)ietf(_dot_)org; bcc'ed)
On May 3, 2015, at 8:32 AM 5/3/15, Carsten Bormann <cabo(_at_)tzi(_dot_)org>
wrote:
Ralph Droms wrote:
On May 1, 2015, at 6:53 PM 5/1/15, Carsten Bormann
<cabo(_at_)tzi(_dot_)org> 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.
I'll work with Scott Mansfield (ITU-T Liaison Manager), Samita, Gabriel, James
and the 6lo WG to collaborate with ITU-T SG-15 on establishing an appropriate
IANA registry.
(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.)
I've moved the discussion to 6lo to continue this thread.
Can you say more, as I don't understand what you've written and I don't have a
clue about where "self-describing syntax" fits into the discussion.
- Ralph
Grüße, Carsten