(Dropping ietf@xxxxxxxx; bcc'ed)
> On May 3, 2015, at 8:32 AM 5/3/15, Carsten Bormann <cabo@xxxxxxx> wrote:
>
>
>
> 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.
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