> 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.
> We
> probably should add a comment to the IANA registry [1] that this code is
> not available in G.9903-based networks. (I can't seem to find the
> liaison statement that alerted IETF to this allocation; however, another
> part of that document mentions that "IANA consideration" is "for further
> study", so that might still come.)
I suggest we actively engage ITU-T SG-15 to publish a very short RFC establishing a new IANA registry for the codepoints in the byte following the ESC Dispatch Type. This registry would define 0x01-0x1f as "G.9903 Command ID values" and mark the other codepoints as "available for assignment".
BTW, I'm now the IAB Liaison Oversight manager. I've alerted Scott Mansfield to the issue. The 6lo chairs/secretary, Scott and I will get in touch with ITU-T SG-15 regarding the registry.
>
> The other interesting observation is that G.9903 always seems to use the
> mesh header with V=1 and F=1 (i.e., the dispatch region used is
> 10_11XXXX). This might coincide with the purported plan by the Thread
> Group to use the Mesh Header (of which I unfortunately know no details).
As far as I can tell, G.9903 uses the MESH Dispatch Type according to the definition in RFC 6282. I don't think any speculation about the use of the Dispatch Type codepoints by the Thread Group is relevant to this discussion of G.9903.
>
> I'm not an expert on G.9903 (in particular, I don't understand the
> interaction between its Annex E and RFC 6775; the latter only seems to
> be reference for the HC area context distribution), but it seems to me
> this is exactly a case where pre-configured knowledge of the way the
> mesh header is intended to be used, is a prerequisite to being able to
> use it ("a 6LoWPAN device requires a set of pre-deployed information,
> called a LoWPAN information base(LIB), ..."; similarly, there is an
> "Adaptation sublayer IB", IB = information base).
Here, I think we disagree. I don't see how any internal configuration can be used to select how bits in a protocol header can be used. The IETF, in fact, fought long and hard *against* a similar definition of an extension to the TCP segment header (Q.flowstatesig). There is no way, within the protocol itself, to guarantee that all the nodes that might exchange frames with mesh headers will use the same interpretation.
- Ralph
>
> Grüße, Carsten
>
> [1]:
> https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml