Subject: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Jul 2015 01:28:13 +0000

Hello 6lo WG:

6lo-office has published the draft (initial) in order to define the usage  of the ESC  extension Dispatch bytes and make a request to IANA for the initial registry of values of ESC extension  dispatch types.

Please take a look and let's discuss. We still have some open issues to close on this draft.

Thanks,
Gabriel, Ralph, James and Samita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 12:50 PM
To: Ralph Droms; Samita Chakrabarti; Ralph Droms; Gabriel Montenegro; james woodyatt; Gabriel Montenegro; Samita Chakrabarti; James Woodyatt
Subject: New Version Notification for draft-chairs-6lo-dispatch-iana-registry-00.txt

A new version of I-D, draft-chairs-6lo-dispatch-iana-registry-00.txt
has been successfully submitted by Samita Chakrabarti and posted to the IETF repository.

Name:		draft-chairs-6lo-dispatch-iana-registry
Revision:	00
Title:		IANA Registry for 6lowpan Additional Dispatch Bytes
Document date:	2015-07-06
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-chairs-6lo-dispatch-iana-registry-00.txt
Status:         https://datatracker.ietf.org/doc/draft-chairs-6lo-dispatch-iana-registry/
Htmlized:       https://tools.ietf.org/html/draft-chairs-6lo-dispatch-iana-registry-00

Abstract:
   RFC4944 defines ESC dispatch type for additional dispatch bytes in
   the 6lowpan header.  The value of ESC byte has been updated by
   RFC6282.  However, the usage of ESC extension bytes has not been
   defined in RFC6282 and RFC4944.  The purpose of this document is to
   define the usage of ESC extension bytes.  It also records the initial
   values for extended dispatch values and requests corresponding IANA
   actions.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Thierry LYS <[email-masked]>
Date: Wed, 8 Jul 2015 07:41:38 +0200

Hello Samita,

Thank you for your initiative. It is really time to freeze ESC dispatch 
header.
Don't you think we should make the same registration at IANA for the MESH 
dispatch header that G3-PLC is also using (and some other mesh-under 
protocols as well) ?

Regards,
Thierry

De :    [email-masked]
A :     [email-masked]
Cc :    [email-masked]
Date :  07/07/2015 03:28
Objet : draft-chairs-6lo-dispatch-iana-registry-00.txt

Hello 6lo WG:

6lo-office has published the draft (initial) in order to define the usage 
of the ESC  extension Dispatch bytes and make a request to IANA for the 
initial registry of values of ESC extension  dispatch types.

Please take a look and let's discuss. We still have some open issues to 
close on this draft.

Thanks,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 12:50 PM
To: Ralph Droms; Samita Chakrabarti; Ralph Droms; Gabriel Montenegro; 
james woodyatt; Gabriel Montenegro; Samita Chakrabarti; James Woodyatt
Subject: New Version Notification for 
draft-chairs-6lo-dispatch-iana-registry-00.txt

A new version of I-D, draft-chairs-6lo-dispatch-iana-registry-00.txt
has been successfully submitted by Samita Chakrabarti and posted to the 
IETF repository.

Name:                            draft-chairs-6lo-dispatch-iana-registry
Revision:                00
Title:                           IANA Registry for 6lowpan Additional 
Dispatch Bytes
Document date:           2015-07-06
Group:                           Individual Submission
Pages:                           7
URL:            
https://www.ietf.org/internet-drafts/draft-chairs-6lo-dispatch-iana-registry-00.txt

Status:         
https://datatracker.ietf.org/doc/draft-chairs-6lo-dispatch-iana-registry/
Htmlized:       
https://tools.ietf.org/html/draft-chairs-6lo-dispatch-iana-registry-00

Abstract:

Please note that it may take a couple of minutes from the time of 
submission until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Jul 2015 23:03:38 -0700

Thierry,

Is G3-PLC using a Mesh Dispatch type that is different from what's already
registered at IANA (
https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml)?
IIRC, G3-PLC just uses the Mesh Header as defined in RFC 4944.

It's really quite unfortunate that G3-PLC decided to define the usage of
ESC on its own.  That's really what NALP was intended for.  Now we are
forced to decide whether or not to reserve a whole swath of the ESC
namespace just for G3-PLC.  Will other protocols have the same luxury?

--
Jonathan Hui

On Tue, Jul 7, 2015 at 10:41 PM, Thierry LYS <[email-masked]> wrote:

> ------------------------------
>
>
>
>
> Hello 6lo WG:
>
> From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Jul 2015 23:15:30 -0700

Thanks for this draft.

Regarding the open issues, I'm not sure either of the two alternatives
behaviors for legacy devices make sense.

If a legacy implementation does not understand the ESC header, the device
cannot simply skip the ESC header and continue processing what follows.  So
I'm not sure how an existing implementation can just ignore the ESC header.

Said in another way, if an implementation reaches the ESC header in its
processing, then it has nothing to do but to discard the 6lowpan packet.
RFC 4944 and RFC 6282 does not define any behavior when encountering an ESC
header (or any 6lowpan header) it does not understand.

Note the conditional "if an implementation reaches the ESC header in its
processing", which I think is important.  For example, if an ESC header
follows the Mesh Header, then an existing implementation will probably
process the Mesh Header and forward the packet along without further
processing of the payload.  So I think we can't say that an existing
implementation will drop 6lowpan packets that have an ESC header somewhere
in the packet.  But I do think we can say that an existing implementation
will drop a 6lowpan packet if it attempts to process an ESC header that it
does not understand.

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 8 Jul 2015 17:51:56 +0000

Hi Thiery,

>Don't you think we should make the same registration at IANA for the MESH dispatch header that G3-PLC is also using  >(and some other mesh-under protocols as well) ?

[SC>]  The IANA section defines the G3-PLC code points for registration. Unfortunately ITU-T specification was already done without our knowledge and now we are accommodating the type values in the frame bytes. Any new mesh header or Route-over logic would have to go through specification and IANA process for registration - that is what the draft recommends.

Thanks,
-Samita

De :        [email-masked]<mailto:[email-masked]>
A :        [email-masked]<mailto:[email-masked]>
Cc :        [email-masked]<mailto:[email-masked]>
Date :        07/07/2015 03:28
Objet :        draft-chairs-6lo-dispatch-iana-registry-00.txt
________________________________

Hello 6lo WG:

Thanks,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:50 PM
To: Ralph Droms; Samita Chakrabarti; Ralph Droms; Gabriel Montenegro; james woodyatt; Gabriel Montenegro; Samita Chakrabarti; James Woodyatt
Subject: New Version Notification for draft-chairs-6lo-dispatch-iana-registry-00.txt

Abstract:

The IETF Secretariat

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 8 Jul 2015 18:17:00 +0000

Hi Jonathan,
Please see in-line.

From: Jonathan Hui [mailto:[email-masked]]
Sent: Tuesday, July 07, 2015 11:16 PM
To: Samita Chakrabarti
Cc: [email-masked]; Thierry LYS ([email-masked])
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Thanks for this draft.

[SC>] It is a combined effort from all the co-authors of the draft. Thanks so much for your comments.

Regarding the open issues, I'm not sure either of the two alternatives behaviors for legacy devices make sense.
[SC> We definitely need to discuss and come up with a way. The proposed solutions were based on some quick ideas.

If a legacy implementation does not understand the ESC header, the device cannot simply skip the ESC header and continue processing what follows.  So I'm not sure how an existing implementation can just ignore the ESC header.
[SC>] Yes, you’re right. It is limited to <dispatch><ESC> case.  I am still not sure how useful that is for the node that does not understand the ESC bytes. For sequence <dispatch><ESC><another-dispatch> will not work—Gabe and I discussed that.
The question we probably need to answer – what would be the use-cases in different scenarios?
What was the original intention of having ESC bytes?  Could ESC byte be considered as 6lowpan extension header? [ like IPv6 extension headers? ]
Could ESC bytes occur multiple times? [ in practice, we want to minimize the header bits- that’s the purpose of 6lowpan, so I assume, we don’t want to add a very long set of sequences]

Another question: It is possible that one implementation can only understand a set of ESC bytes but not other sets. Should it drop the packet? The problem is that without knowing ESC type, the receiver cannot know how many bytes to skip. It’s too late now to introduce TLV structure in ESC first byte. We can define TLV after first byte, but in either case we are stuck because of G.9903, I guess.

Said in another way, if an implementation reaches the ESC header in its processing, then it has nothing to do but to discard the 6lowpan packet.  RFC 4944 and RFC 6282 does not define any behavior when encountering an ESC header (or any 6lowpan header) it does not understand.
[SC>] Understood.

Note the conditional "if an implementation reaches the ESC header in its processing", which I think is important.  For example, if an ESC header follows the Mesh Header, then an existing implementation will probably process the Mesh Header and forward the packet along without further processing of the payload.  So I think we can't say that an existing implementation will drop 6lowpan packets that have an ESC header somewhere in the packet.  But I do think we can say that an existing implementation will drop a 6lowpan packet if it attempts to process an ESC header that it does not understand.
[SC>] This is a very good point.

Best regards,
-Samita

On Mon, Jul 6, 2015 at 6:28 PM, Samita Chakrabarti <[email-masked]<mailto:[email-masked]>> wrote:

Hello 6lo WG:

Thanks,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 06, 2015 12:50 PM
To: Ralph Droms; Samita Chakrabarti; Ralph Droms; Gabriel Montenegro; james woodyatt; Gabriel Montenegro; Samita Chakrabarti; James Woodyatt
Subject: New Version Notification for draft-chairs-6lo-dispatch-iana-registry-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 08 Jul 2015 20:36:37 +0200

> */What was the original intention of having ESC bytes?  

The intention was to reserve one out of the 256 dispatch bytes values so
we can continue to extend 6LoWPAN when the other 255 are gone.
(Think about them as opening dispatch value 256 to 511.)

There is nothing special or magical about ESC.  Like all the other
dispatch byte values, there needs to be a spec that defines what the
rest of the packet means.  You have now started to write a spec.
That should use the next byte in a way analogous to (but disjoint from)
the way the first byte is being used.

> Could ESC byte
> be considered as 6lowpan extension header? [ like IPv6 extension
> headers? ] /*

No.  We already have that, e.g. with the Mesh header.

> */Could ESC bytes occur multiple times? [ in practice, we want to
> minimize the header bits- that’s the purpose of 6lowpan, so I assume, we
> don’t want to add a very long set of sequences]/*

Yes.  Some headers are meant to be followed by another dispatch byte.
So if such a header is started by an ESC byte, and the next header
happens to be started by an ESC byte, we would have the situation you
describe.  Again, nothing special, except that maybe the use cases are
uncommon enough that we didn't allocate a dispatch byte value from the
efficient space.

> */Another question: It is possible that one implementation can only
> understand a set of ESC bytes but not other sets. 

Again, none of these considerations have anything whatsoever to do with
whether the encoding happened to use ESC or not.

Right now, we don't have an ignorable range of dispatch values.  When we
add one, it's secondary whether that is (or some of those values are)
encoded with or without ESC.

> Should it drop the
> packet? The problem is that without knowing ESC type, the receiver
> cannot know how many bytes to skip. 

Right.  Any ignorable range will need to be self-describing enough so
you can skip it.

> RFC 4944 and RFC 6282 does not define any behavior when
> encountering an ESC header (or any 6lowpan header) it does not understand.

Exactly -- there is no ignorable range yet.

Pascal's 6LoRHE has an elective (ignorable) and a critical range.
Whether those are encoded with an ESC or not is mostly dependent on how
we manage to manage the dispatch byte space.

Grüße, Carsten

(I have not tried to attribute the various snippets above to the
original author -- messages that do not use standard e-mail citing
conventions are in turn hard to cite.)

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Jul 2015 13:48:22 -0700

Hi Samita,

See below:

On Wed, Jul 8, 2015 at 11:17 AM, Samita Chakrabarti <
[email-masked]> wrote:

>
>
> *From:* Jonathan Hui [mailto:[email-masked]]
> *Sent:* Tuesday, July 07, 2015 11:16 PM
> *To:* Samita Chakrabarti
> *Cc:* [email-masked]; Thierry LYS ([email-masked])
> *Subject:* Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>
>
>
>   If a legacy implementation does not understand the ESC header, the
> device cannot simply skip the ESC header and continue processing what
> follows.  So I'm not sure how an existing implementation can just ignore
> the ESC header.
>
> *[SC>] Yes, you’re right. It is limited to <dispatch><ESC> case.  I am
> still not sure how useful that is for the node that does not understand the
> ESC bytes. For sequence <dispatch><ESC><another-dispatch> will not
> work—Gabe and I discussed that.*
>
> *The question we probably need to answer – what would be the use-cases in
> different scenarios?  *
>

I think we need to be clear about different "legacy" implementations.
There's legacy implementations that don't understand any ESC headers (those
that only used the 6lowpan headers defined in RFCs as of today).  There's
legacy implementations that makeup their own use of ESC headers (G3-PLC).
And then there's the "legacy" implementations that will understand the new
ESC header encoding, but may not understand some subset of the headers
defined within that ESC header encoding.

If history is any indication, we can't possibly foresee all important use
cases that may come up in the future.

 *What was the original intention of having ESC bytes?  Could ESC byte be
> considered as 6lowpan extension header? [ like IPv6 extension headers? ]*
>

As Carsten stated, the original intention was to give us an out in the case
that all of the existing dispatch values were used up.

>  *Could ESC bytes occur multiple times? [ in practice, we want to
> don’t want to add a very long set of sequences]*
>

That's really up to how we define ESC headers, but I think it would be a
mistake not to allow ESC headers to occur multiple times.

*Another question: It is possible that one implementation can only
> understand a set of ESC bytes but not other sets. Should it drop the
> packet? The problem is that without knowing ESC type, the receiver cannot
> know how many bytes to skip. It’s too late now to introduce TLV structure
> in ESC first byte. We can define TLV after first byte, but in either case
> we are stuck because of G.9903, I guess.*
>

Again, that's really depends on whether or not we define a class of headers
that can be ignored.  Personally, I do think 6lowpan could benefit from a
class of ignorable headers.

As I mentioned above, we can't possibly foresee all important use cases
that may come up in the future.  So having an ignorable range of 6lowpan
headers is something we should certainly consider.  IEEE 802.15.4
originally started down a path of optimizing every bit, only to realize
that it was too restrictive, and resulted in IEEE 802.15.4e-2012
Information Elements (IEs).  Those IEs are now used in a number of ways to
extend the base IEEE 802.15.4 header.  IEEE 802.15.4e-2012 even introduces
an IE that carries the MAC payload such that new footers can also be
defined.  Basically, most everything outside the base header can now be
encapsulated by IEs.

As Carsten mentioned, whether or not additional headers are encoded within
the ESC range is a separate consideration.  But if such additional headers
are encoded within the ESC range, then it is of interest to this draft.

Finally, I'll reiterate that I think we should think carefully about simply
giving a whole swath of the ESC namespace to G3-PLC.  One possibility is to
have an encoding that can carry something like an OUI, allowing third
parties to define whatever they want without any further coordination with
the IETF.  IEEE 802.15.4e-2012 IEs have a form that can carry OUIs.

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 9 Jul 2015 02:57:24 +0000

Thank you Carsten for the valuable suggestions and a bit of history behind ESC.

-Samita

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, July 08, 2015 11:37 AM
To: Samita Chakrabarti
Cc: Jonathan Hui; Thierry LYS ([email-masked]); [email-masked]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

> */What was the original intention of having ESC bytes?  

The intention was to reserve one out of the 256 dispatch bytes values so we can continue to extend 6LoWPAN when the other 255 are gone.
(Think about them as opening dispatch value 256 to 511.)

There is nothing special or magical about ESC.  Like all the other dispatch byte values, there needs to be a spec that defines what the rest of the packet means.  You have now started to write a spec.
That should use the next byte in a way analogous to (but disjoint from) the way the first byte is being used.

> minimize the header bits- that’s the purpose of 6lowpan, so I assume, 
> we don’t want to add a very long set of sequences]/*

Yes.  Some headers are meant to be followed by another dispatch byte.
So if such a header is started by an ESC byte, and the next header happens to be started by an ESC byte, we would have the situation you describe.  Again, nothing special, except that maybe the use cases are uncommon enough that we didn't allocate a dispatch byte value from the efficient space.

> understand a set of ESC bytes but not other sets.

Again, none of these considerations have anything whatsoever to do with whether the encoding happened to use ESC or not.

Right now, we don't have an ignorable range of dispatch values.  When we add one, it's secondary whether that is (or some of those values are) encoded with or without ESC.

> cannot know how many bytes to skip.

Right.  Any ignorable range will need to be self-describing enough so you can skip it.

> RFC 4944 and RFC 6282 does not define any behavior when encountering 
> an ESC header (or any 6lowpan header) it does not understand.

Pascal's 6LoRHE has an elective (ignorable) and a critical range.
Whether those are encoded with an ESC or not is mostly dependent on how we manage to manage the dispatch byte space.

Grüße, Carsten

(I have not tried to attribute the various snippets above to the original author -- messages that do not use standard e-mail citing conventions are in turn hard to cite.)

---

From: Paul Duffy <[email-masked]>
Date: Wed, 08 Jul 2015 23:24:00 -0400

On 7/8/2015 4:48 PM, Jonathan Hui wrote:
> Finally, I'll reiterate that I think we should think carefully about 
> simply giving a whole swath of the ESC namespace to G3-PLC.  One 
> possibility is to have an encoding that can carry something like an 
> OUI, allowing third parties to define whatever they want without any 
> further coordination with the IETF.  IEEE 802.15.4e-2012 IEs have a 
> form that can carry OUIs.

I agree with Jonathan's statements re: this draft.  The G3 assignments 
represents more that 10% of the available extension types, and I see 
little justification for that.

Alternatives include a dispatch value assigned for "organization 
extension" with the subsequent frame containing an OUI, PEN, etc. then 
the org defined payload.  Let the extending organization manage their 
own number space and frame definition.  Or the mentioned approach of 
4e's Information Element.

I'm also curious, given G3 is asking for 31 Extension Types ... what 
parts of RFC-ed 6LoWPAN are they actually using?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Jul 2015 11:59:40 +0000

100% agreement with Jonathan.

I think that granting 6LoWPAN formats after the fact without a chance to discuss what goes where in that grant is a mistake that create the wrong type of precedent.

What if another group also escaped its own stuff and used the same codes and comes tomorrow asking us the same range? Or any range? Why them and not us?

We are pretty much in the mirror situation as the desire to reuse the MH space for 6LoRH. This becomes a problem of relation between not just 2 but an unknown number of other standardization bodies. At the end of the day, this is the core reason why there are some rules, and the reason why we are reconsidering the 6LoRH not to overlap with MH.

A few remarks:

-        6LoRH has built-in a signal that a header can be ignored. That’s a lesson we learnt from IPv6 Option Type identifiers encoding. When the header can be ignored, the size to skip is provided in octets.

-        One option (option 2) for encoding 6LoRH is a form of escape. But we realized that the values being escaped (and thus reused modulo 256) are for dispatches that are at the head of the packet. So rather than having to escape every single occurrence of a 6LoRH, the proposal is to delineate the segment of the packet where 4944 is no more used and 6LoRH start applying. IOW we virtually escape all the rest of the packet, so we can reuse the space (modulo 256) the space used by NALP, MH and Fragments before the demarcation.

-        6LoRH has a TLV structure and has room to receive the namespace required by G3-PLC.

Cheers,

Pascal

Cheers,

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Jonathan Hui
Sent: mercredi 8 juillet 2015 22:48
To: Samita Chakrabarti
Cc: Thierry LYS ([email-masked]); [email-masked]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Hi Samita,

See below:

On Wed, Jul 8, 2015 at 11:17 AM, Samita Chakrabarti <[email-masked]<mailto:[email-masked]>> wrote:

From: Jonathan Hui [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 07, 2015 11:16 PM
To: Samita Chakrabarti
Cc: [email-masked]<mailto:[email-masked]>; Thierry LYS ([email-masked]<mailto:[email-masked]>)
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

I think we need to be clear about different "legacy" implementations.  There's legacy implementations that don't understand any ESC headers (those that only used the 6lowpan headers defined in RFCs as of today).  There's legacy implementations that makeup their own use of ESC headers (G3-PLC).  And then there's the "legacy" implementations that will understand the new ESC header encoding, but may not understand some subset of the headers defined within that ESC header encoding.

If history is any indication, we can't possibly foresee all important use cases that may come up in the future.

As Carsten stated, the original intention was to give us an out in the case that all of the existing dispatch values were used up.

That's really up to how we define ESC headers, but I think it would be a mistake not to allow ESC headers to occur multiple times.

Again, that's really depends on whether or not we define a class of headers that can be ignored.  Personally, I do think 6lowpan could benefit from a class of ignorable headers.

As I mentioned above, we can't possibly foresee all important use cases that may come up in the future.  So having an ignorable range of 6lowpan headers is something we should certainly consider.  IEEE 802.15.4 originally started down a path of optimizing every bit, only to realize that it was too restrictive, and resulted in IEEE 802.15.4e-2012 Information Elements (IEs).  Those IEs are now used in a number of ways to extend the base IEEE 802.15.4 header.  IEEE 802.15.4e-2012 even introduces an IE that carries the MAC payload such that new footers can also be defined.  Basically, most everything outside the base header can now be encapsulated by IEs.

As Carsten mentioned, whether or not additional headers are encoded within the ESC range is a separate consideration.  But if such additional headers are encoded within the ESC range, then it is of interest to this draft.

Finally, I'll reiterate that I think we should think carefully about simply giving a whole swath of the ESC namespace to G3-PLC.  One possibility is to have an encoding that can carry something like an OUI, allowing third parties to define whatever they want without any further coordination with the IETF.  IEEE 802.15.4e-2012 IEs have a form that can carry OUIs.

--
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Fri, 10 Jul 2015 12:36:28 +0100

Comments on the draft
=====================

"The ESC byte [01 000000] is modified in RFC 6282[RFC6282] and [RFC4944]
first introduces this dispatch header type for extension of dispatch bytes
for different usage of 6lowpan applications."

I am not sure what "for different usage of 6lowpan applications" means. I
would have thought "for future definition" would be more appropriate.
Whatever follows the ESC byte is not defined in RFC 4944 or RFC 6282, or
else there would be no need for it.

"For example, a dispatch header type (ex: LOWPAN_HC1, MESH etc.) might need
some special handling of each packet for classification."

I am not sure what this actually means and doesn't really add any value.
The rest of the document defines what the intention is regarding the byte
subsequent to ESC and there shouldn't be any assumptions about how that
will be used.

"Note that section 5.1 in RFC4944 indicates that the Extension Type field
may contain additional dispatch values (larger than 63)."

The value in RFC 4944 is 127, which IIRC was agreed on the mailing list to
be wrong (a hangover from earlier drafts) and should be 63. This should be
clarified here.

Minor nit: Put a space between term and abbreviation, e.g. "Extension
Type(ET)" -> "Extension Type (ET)"

Open issues: It is not possible for a legacy device to simply ignore the
ESC byte. To some extent, it depends where the ESC byte appears in the
stream. As Jonathan points out, if it occurs as payload of another header
it is just part of opaque data. However, if encountered during processing,
the packet should be discarded.

Figure 3: 32-254 Unassigned. I think this needs to be stronger and say
"reserved", which requires any use of these values to be sanctioned by
IETF/IANA. To be honest, the use of ESC is reserved in IANA and G3-PLC
should not have just gone and used those values without consulting
IETF/IANA.

Cherry-picking on some of the other comments
============================================

>> (JH) RFC 4944 and RFC 6282 does not define any behavior when
> (CB) Exactly -- there is no ignorable range yet.

<RCC>No, but it is defined as a reserved field. On that basis, there should
be some defined behaviour for reserved fields. I am not aware of a RFC
which generally states what to do in this case but the normal behaviour is
to discard the packet. The elective form can only work if the processing
has sufficient knowledge of the meta format, e.g. TLV, where it may not be
able to interpret the payload but can skip over. In this case, we are
simply specifying Extension Type so, on that basis, if a device sees
[ESC,<ET>], it cannot infer anything about subsequent bytes so really has
to discard the packet.</RCC>

> (JH) I think we need to be clear about different "legacy"
implementations. There's legacy implementations that don't understand any
ESC headers (those that only used the 6lowpan headers defined in RFCs as of
today).

<RCC>See previous comment (use of ESC is reserved).</RCC>

> (JH) There's legacy implementations that makeup their own use of ESC
headers (G3-PLC).

<RCC>The uncoordinated use by G3-PLC is indeed unfortunate and of course it
is possible that others have also used ESC in the same way. My main concern
is that the use of the reserved ESC field is counter to expected practice.
On this basis, one could even argue that the allocation should be ignored
and state that the ITU should have coordinated with IETF/IANA regarding the
use of this field.</RCC>

> (JH) And then there's the "legacy" implementations that will understand
the new ESC header encoding, but may not understand some subset of the
headers defined within that ESC header encoding.

<RCC>That's not "legacy" IMHO - "legacy" applies to all devices which exist
prior to the publication of this standard. If we tighten up the meaning of
"reserved" then it should be clear what the behaviour is. Going forward,
this will mean that updates to the specification (using currently reserved
values) will at least be able to unequivocally state what a "legacy" device
relative to the update will do.</RCC>

>> (SC) Could ESC bytes occur multiple times? [ in practice, we want to
minimize the header bits- that’s the purpose of 6lowpan, so I assume, we
don’t want to add a very long set of sequences]
> (JH) That's really up to how we define ESC headers, but I think it would
be a mistake not to allow ESC headers to occur multiple times.

<RCC>I think that is OK providing we still have the concept of a "switch"
type of dispatch, as described in Section 3.2 of
draft-thubert-6lo-routing-dispatch-04. This concept is different from ESC
in that it switches the dispatch code space on encountering the switch
byte.</RCC>

Robert

On 9 July 2015 at 12:59, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> I think that granting 6LoWPAN formats after the fact without a chance to
> discuss what goes where in that grant is a mistake that create the wrong
> type of precedent.
>
>
>
> What if another group also escaped its own stuff and used the same codes
> and comes tomorrow asking us the same range? Or any range? Why them and not
> us?
>
>
>
> We are pretty much in the mirror situation as the desire to reuse the MH
> space for 6LoRH. This becomes a problem of relation between not just 2 but
> an unknown number of other standardization bodies. At the end of the day,
> this is the core reason why there are some rules, and the reason why we are
> reconsidering the 6LoRH not to overlap with MH.
>
>
>
> A few remarks:
>
>
>
> -        6LoRH has built-in a signal that a header can be ignored. That’s
> a lesson we learnt from IPv6 Option Type identifiers encoding. When the
> header can be ignored, the size to skip is provided in octets.
>
> -        One option (option 2) for encoding 6LoRH is a form of escape.
> But we realized that the values being escaped (and thus reused modulo 256)
> are for dispatches that are at the head of the packet. So rather than
> having to escape every single occurrence of a 6LoRH, the proposal is to
> delineate the segment of the packet where 4944 is no more used and 6LoRH
> start applying. IOW we virtually escape all the rest of the packet, so we
> can reuse the space (modulo 256) the space used by NALP, MH and Fragments
> before the demarcation.
>
> *From:* 6lo [mailto:[email-masked]] *On Behalf Of *Jonathan Hui
> *Sent:* mercredi 8 juillet 2015 22:48
> *To:* Samita Chakrabarti
> *Cc:* Thierry LYS ([email-masked]); [email-masked]
>   *What was the original intention of having ESC bytes?  Could ESC byte
> be considered as 6lowpan extension header? [ like IPv6 extension headers? ]*
>
>
>
> As Carsten stated, the original intention was to give us an out in the
> case that all of the existing dispatch values were used up.
>
>
>
> Again, that's really depends on whether or not we define a class of
> headers that can be ignored.  Personally, I do think 6lowpan could benefit
> from a class of ignorable headers.
>
>
>
> possibility is to have an encoding that can carry something like an OUI,
> allowing third parties to define whatever they want without any further
> coordination with the IETF.  IEEE 802.15.4e-2012 IEs have a form that can
> carry OUIs.
>
>
>
> --
>
> Jonathan Hui
>
>
>

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Jul 2015 08:51:58 -0700

> <RCC>See previous comment (use of ESC is reserved).</RCC>

Given that neither RFC 4944 nor RFC 6282 explicitly specify what the
behavior is, I think this document could at least indicate the expected
behavior of existing implementations (i.e. discard the packet).

> <RCC>The uncoordinated use by G3-PLC is indeed unfortunate and of course
> it is possible that others have also used ESC in the same way.  My main
> concern is that the use of the reserved ESC field is counter to expected
> practice.  On this basis, one could even argue that the allocation should
> be ignored and state that the ITU should have coordinated with IETF/IANA
> regarding the use of this field.</RCC>
>

Completely agree.

> <RCC>That's not "legacy" IMHO - "legacy" applies to all devices which
> exist prior to the publication of this standard. If we tighten up the
> meaning of "reserved" then it should be clear what the behaviour is. Going
> forward, this will mean that updates to the specification (using currently
> reserved values) will at least be able to unequivocally state what a
> "legacy" device relative to the update will do.</RCC>
>

That's a completely reasonable definition.  The reason why I mention this
is that this draft has language like: "When a legacy 6lowpan node receives
packets with ESC bytes or nodes receiving ESC bytes it does not understand,
what should be its behavior?"  If "legacy" only applies to devices which
exist prior to publication of this draft, then this draft can do nothing to
dictate what those "legacy" implementations should do.

> in that it switches the dispatch code space on encountering the switch

I don't think we need a "switch" dispatch unless we want to reuse bit
patterns that are already defined in RFC 4944/6282 in the same 6LoWPAN
frame.  draft-thubert-6lo-routing-dispatch has a proposal to reuse some bit
patterns in the same frame, hence the proposal for a "switch" dispatch.

--
Jonathan Hui

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Jul 2015 11:10:08 -0700

On Jul 10, 2015, at 08:51, Jonathan Hui <[email-masked]> wrote:
> 
> > (JH) There's legacy implementations that makeup their own use of ESC headers (G3-PLC).
> 
> <RCC>The uncoordinated use by G3-PLC is indeed unfortunate and of course it is possible that others have also used ESC in the same way.  My main concern is that the use of the reserved ESC field is counter to expected practice.  On this basis, one could even argue that the allocation should be ignored and state that the ITU should have coordinated with IETF/IANA regarding the use of this field.</RCC>
> 
> Completely agree.

Another possible action would be to declare the region currently occupied by G3-PLC as a range for Private Use (with a note that G3-PLC uses the entire range).

—james

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Jul 2015 11:17:19 -0700

On Fri, Jul 10, 2015 at 11:10 AM, james woodyatt <[email-masked]> wrote:

> Another possible action would be to declare the region currently occupied
> by G3-PLC as a range for Private Use (with a note that G3-PLC uses the
> entire range).
>

If we wanted to be accommodating, then I think this is the best path
forward.  However, NALP was really the space we intended for Private Use,
even though we didn't call it that.  And we were quite generous with NALP
by only giving it a 2-bit identifier.

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 18 Jul 2015 22:31:20 +0000

Hi Robert,

Please see in-line. Thank you very much for your comments.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Friday, July 10, 2015 4:36 AM
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui; Samita Chakrabarti; Thierry LYS ([email-masked]); [email-masked]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Comments on the draft
=====================

"The ESC byte [01 000000] is modified in RFC 6282[RFC6282] and [RFC4944] first introduces this dispatch header type for extension of dispatch bytes for different usage of 6lowpan applications."

I am not sure what "for different usage of 6lowpan applications" means. I would have thought "for future definition" would be more appropriate. Whatever follows the ESC byte is not defined in RFC 4944 or RFC 6282, or else there would be no need for it.
[SC>] We can change to “future definition” is that is agreeable by most.

"For example, a dispatch header type (ex: LOWPAN_HC1, MESH etc.) might need some special handling of each packet for classification."

I am not sure what this actually means and doesn't really add any value. The rest of the document defines what the intention is regarding the byte subsequent to ESC and there shouldn't be any assumptions about how that will be used.
[SC>] At the time of writing, from the existing documents, the usage  of ESC bytes was not clear to me. The examples of special handling was an idea to see if it was a justified usecase. The purpose of the document is also to provide a guideline of usages of ESC bytes. I am wondering about a usecase, where a 6lo-device wants to send a 6lowpan packet + device information or network information that might be used for routing or end-node communication as we add more functionality using 6lowpan. Or it could be some security related information being present in the ESC bytes… If we don’t know the example usecases, how can we guide others to define new additional sequence bytes? Now that we have opportunities to define ESC bytes usage, perhaps we can add some new thoughts…  that was the thinking behind that sentence.

"Note that section 5.1 in RFC4944 indicates that the Extension Type field may contain additional dispatch values (larger than 63)."

The value in RFC 4944 is 127, which IIRC was agreed on the mailing list to be wrong (a hangover from earlier drafts) and should be 63. This should be clarified here.
[SC>] Possible. Though, I am not sure if this is the right document for clarification of that Errata in RFC4944. But we can take an opportunity to explain. I am open to it. Will need to discuss with co-authors.

Minor nit: Put a space between term and abbreviation, e.g. "Extension Type(ET)" -> "Extension Type (ET)"
[SC>] OK.

Open issues: It is not possible for a legacy device to simply ignore the ESC byte. To some extent, it depends where the ESC byte appears in the stream. As Jonathan points out, if it occurs as payload of another header it is just part of opaque data. However, if encountered during processing, the packet should be discarded.
[SC>] This is definitely a safe option.

Figure 3: 32-254 Unassigned. I think this needs to be stronger and say "reserved", which requires any use of these values to be sanctioned by IETF/IANA. To be honest, the use of ESC is reserved in IANA and G3-PLC should not have just gone and used those values without consulting IETF/IANA.
[SC>] We need to revisit the IANA bits/values based on the discussions on this list. I understand your concern and the point is taken.

Thanks,
-Samita

>> (JH) RFC 4944 and RFC 6282 does not define any behavior when encountering an ESC header (or any 6lowpan header) it does not understand.

<RCC>No, but it is defined as a reserved field. On that basis, there should be some defined behaviour for reserved fields. I am not aware of a RFC which generally states what to do in this case but the normal behaviour is to discard the packet. The elective form can only work if the processing has sufficient knowledge of the meta format, e.g. TLV, where it may not be able to interpret the payload but can skip over. In this case, we are simply specifying Extension Type so, on that basis, if a device sees [ESC,<ET>], it cannot infer anything about subsequent bytes so really has to discard the packet.</RCC>

> (JH) I think we need to be clear about different "legacy" implementations. There's legacy implementations that don't understand any ESC headers (those that only used the 6lowpan headers defined in RFCs as of today).

> (JH) And then there's the "legacy" implementations that will understand the new ESC header encoding, but may not understand some subset of the headers defined within that ESC header encoding.

<RCC>That's not "legacy" IMHO - "legacy" applies to all devices which exist prior to the publication of this standard. If we tighten up the meaning of "reserved" then it should be clear what the behaviour is. Going forward, this will mean that updates to the specification (using currently reserved values) will at least be able to unequivocally state what a "legacy" device relative to the update will do.</RCC>

>> (SC) Could ESC bytes occur multiple times? [ in practice, we want to minimize the header bits- that’s the purpose of 6lowpan, so I assume, we don’t want to add a very long set of sequences]
> (JH) That's really up to how we define ESC headers, but I think it would be a mistake not to allow ESC headers to occur multiple times.

<RCC>I think that is OK providing we still have the concept of a "switch" type of dispatch, as described in Section 3.2 of draft-thubert-6lo-routing-dispatch-04. This concept is different from ESC in that it switches the dispatch code space on encountering the switch byte.</RCC>

Robert

On 9 July 2015 at 12:59, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
100% agreement with Jonathan.

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

From: 6lo [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jonathan Hui
Sent: mercredi 8 juillet 2015 22:48
To: Samita Chakrabarti
Cc: Thierry LYS ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Hi Samita,

See below:

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 18 Jul 2015 22:31:50 +0000

Hi Paul,

Thanks for your suggestion. We will revisit the ESC bytes allocation proposal based on various suggestions.
As for G3-PLC usage of 6lowpan usage,  here is some explanation provided by Thierry on the list:

From: Thierry LYS [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2015 3:11 PM
To: Samita Chakrabarti
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [6lo] Possible 6LoWPAN dispatch type deprecation and re-use for route over purposes

Hello Samita, 

Please find my answer below: 

> ESC dispatch header is used in G3-PLC for 2 types of commands : the mesh-under routing and the bootstrapping. 
We do use 6LOWPAN_IPHC and ESC headers in the same frame during the bootstrapping phase. 

> ESC dispatch header is placed after 6LOWPAN_IPHC header. ESC is always located in last position. 

Best regards, 
Thierry 

-------------

-Samita
-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Paul Duffy
Sent: Wednesday, July 08, 2015 8:24 PM
To: [email-masked]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

> form that can carry OUIs.

I agree with Jonathan's statements re: this draft.  The G3 assignments represents more that 10% of the available extension types, and I see little justification for that.

Alternatives include a dispatch value assigned for "organization extension" with the subsequent frame containing an OUI, PEN, etc. then the org defined payload.  Let the extending organization manage their own number space and frame definition.  Or the mentioned approach of 4e's Information Element.

I'm also curious, given G3 is asking for 31 Extension Types ... what parts of RFC-ed 6LoWPAN are they actually using?

---

From: Robert Cragie <[email-masked]>
Date: Mon, 20 Jul 2015 23:36:04 +0100

Hi Samita,

Responses below, bracketed by <RCC></RCC>

Robert

On 18 July 2015 at 23:31, Samita Chakrabarti <
[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Robert Cragie
> *Sent:* Friday, July 10, 2015 4:36 AM
> *To:* Pascal Thubert (pthubert)
> *Cc:* Jonathan Hui; Samita Chakrabarti; Thierry LYS ([email-masked]);
> [email-masked]
> *[SC>] We can change to “future definition” is that is agreeable by most.*
>
>
>
> "For example, a dispatch header type (ex: LOWPAN_HC1, MESH etc.) might
> need some special handling of each packet for classification."
>
>
>
> *[SC>] At the time of writing, from the existing documents, the usage  of
> ESC bytes was not clear to me. The examples of special handling was an idea
> to see if it was a justified usecase. The purpose of the document is also
> to provide a guideline of usages of ESC bytes. I am wondering about a
> usecase, where a 6lo-device wants to send a 6lowpan packet + device
> information or network information that might be used for routing or
> end-node communication as we add more functionality using 6lowpan. Or it
> could be some security related information being present in the ESC bytes…
> If we don’t know the example usecases, how can we guide others to define
> new additional sequence bytes? Now that we have opportunities to define ESC
> bytes usage, perhaps we can add some new thoughts…  that was the thinking
> behind that sentence.*
>

<RCC>I understand. I think given some of the other conversation on this
topic that it might be worth highlighting when  ESC should be used and when
NALP should be used. In my opinion, NALP should really have been used for
the ITU-T frames as AFAICT they are not obviously 6LoWPAN-type packets.
However, this in itself does then lead to defining what we mean by "6LoWPAN
type packets" so I do see some value in doing in at least clarifying this
aspect.</RCC>

> *[SC>] Possible. Though, I am not sure if this is the right document for
> clarification of that Errata in RFC4944. But we can take an opportunity to
> explain. I am open to it. Will need to discuss with co-authors.*
>

<RCC>I think we probably need an erratum as well</RCC>

> *[SC>] OK.*
> *[SC>] This is definitely a safe option.*
>
>
>
> *[SC>] We need to revisit the IANA bits/values based on the discussions on
> this list. I understand your concern and the point is taken.*
>

<RCC>I don't mind what language is used as long as it is clear that it is
reserved for future use. This should prevent or at least hopefully
discourage use</RCC>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jul 2015 06:45:53 +0000

I agree with Robert here.

My suggestions are:

- rename ESC to something like "Guest protocols" and carve space that external entities can administer on their own, starting with ITU.

- provide guidance on NALP before anyone uses it like ITU did with ESC. My recommendation there would be the NALP is defined only when used in the first octet of the payload to distinguish an alien protocol. This will allow to reuse the dispatch space inside a 6lo packet when we run out of space.

What do others think?

Pascal

Le 21 juil. 2015 à 00:36, Robert Cragie <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Samita,

Robert

On 18 July 2015 at 23:31, Samita Chakrabarti <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Cragie
Sent: Friday, July 10, 2015 4:36 AM
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui; Samita Chakrabarti; Thierry LYS ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Comments on the draft
=====================

<RCC>I understand. I think given some of the other conversation on this topic that it might be worth highlighting when  ESC should be used and when NALP should be used. In my opinion, NALP should really have been used for the ITU-T frames as AFAICT they are not obviously 6LoWPAN-type packets. However, this in itself does then lead to defining what we mean by "6LoWPAN type packets" so I do see some value in doing in at least clarifying this aspect.</RCC>

<RCC>I don't mind what language is used as long as it is clear that it is reserved for future use. This should prevent or at least hopefully discourage use</RCC>

---

From: Thierry LYS <[email-masked]>
Date: Wed, 22 Jul 2015 12:03:02 +0200

Pascal,

That would work for me.

I also propose to modify the table of section 4 (for more clarity and 
precision) of the internet draft 
"draft-chairs-6lo-dispatch-iana-registry-00.txt"

from

   +-------+---------------------------------+---------------+
   | Value | Description                     | Reference     |
   +-------+---------------------------------+---------------+
   |  0    | Reserved for future use         | This document |
   |       |                                 |               |
   | 1-31  | Used by ITU-T G.9903 command ID | ITU-T G.9903  |
   |       |                                 | [G3-PLC]      |
   | 32-254| Unassigned                      | This document |
   | 255   | Reserved for future use         | This document |
   +-------+---------------------------------+---------------+

 to 
   +-------+---------------------------------+---------------+
   | Value | Description                     | Reference     |
   +-------+---------------------------------+---------------+
   |  0    | Reserved for future use         | This document |
   |       |                                 |               |
   | 1-2   | Used by ITU-T G.9903 commands   | ITU-T G.9903  |
   |       |                                 | [G3-PLC]      |
   |       |                                 |               |
   | 3-15  | ITU-T Reserved                  | ITU-T G.9903  |
   |       |                                 |               |
   | 16    | Used by ITU-T G.9905 command    | ITU-T G.9905  |
   |       |                                 |               |
   | 17-31 | Reserved by ITU-T G.9905        | ITU-T G.9905  |
   |       |                                 |               |
   | 32-254| Unassigned                      | This document |
   |       |                                 |               |
   | 255   | Reserved for future use         | This document |
   +-------+---------------------------------+---------------+

Best regards,

Thierry

De :    [email-masked]
A :     [email-masked]
Cc :    [email-masked], [email-masked], 
[email-masked], [email-masked]
Date :  21/07/2015 08:46
Objet : Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

My suggestions are:

- rename ESC to something like "Guest protocols" and carve space that 
external entities can administer on their own, starting with ITU.

- provide guidance on NALP before anyone uses it like ITU did with ESC. My 
recommendation there would be the NALP is defined only when used in the 
first octet of the payload to distinguish an alien protocol. This will 
allow to reuse the dispatch space inside a 6lo packet when we run out of 
space.

What do others think?

Pascal

Le 21 juil. 2015 à 00:36, Robert Cragie <[email-masked]> a 
écrit :

Hi Samita, 

Robert

 
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Robert Cragie
Sent: Friday, July 10, 2015 4:36 AM
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui; Samita Chakrabarti; Thierry LYS ([email-masked]); 
[email-masked]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
 
Comments on the draft
=====================

 
 
I am not sure what this actually means and doesn't really add any value. 
The rest of the document defines what the intention is regarding the byte 
subsequent to ESC and there shouldn't be any assumptions about how that 
will be used.
[SC>] At the time of writing, from the existing documents, the usage  of 
ESC bytes was not clear to me. The examples of special handling was an 
idea to see if it was a justified usecase. The purpose of the document is 
also to provide a guideline of usages of ESC bytes. I am wondering about a 
usecase, where a 6lo-device wants to send a 6lowpan packet + device 
information or network information that might be used for routing or 
end-node communication as we add more functionality using 6lowpan. Or it 
could be some security related information being present in the ESC bytes… 
If we don’t know the example usecases, how can we guide others to define 
new additional sequence bytes? Now that we have opportunities to define 
ESC bytes usage, perhaps we can add some new thoughts…  that was the 
thinking behind that sentence.

<RCC>I understand. I think given some of the other conversation on this 
topic that it might be worth highlighting when  ESC should be used and 
when NALP should be used. In my opinion, NALP should really have been used 
for the ITU-T frames as AFAICT they are not obviously 6LoWPAN-type 
packets. However, this in itself does then lead to defining what we mean 
by "6LoWPAN type packets" so I do see some value in doing in at least 
clarifying this aspect.</RCC> 

The value in RFC 4944 is 127, which IIRC was agreed on the mailing list to 
be wrong (a hangover from earlier drafts) and should be 63. This should be 
clarified here.
[SC>] Possible. Though, I am not sure if this is the right document for 
clarification of that Errata in RFC4944. But we can take an opportunity to 
explain. I am open to it. Will need to discuss with co-authors.

 
 
Figure 3: 32-254 Unassigned. I think this needs to be stronger and say 
"reserved", which requires any use of these values to be sanctioned by 
IETF/IANA. To be honest, the use of ESC is reserved in IANA and G3-PLC 
should not have just gone and used those values without consulting 
IETF/IANA.
[SC>] We need to revisit the IANA bits/values based on the discussions on 
this list. I understand your concern and the point is taken.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jul 2015 10:51:35 +0000

Hello Thierry

I don't know how ITU manages its registries (eg our IANA or IEEE ANA) but we should delegate to such registry not to a group or a standard.

My suggestion is not to be too specific on how ITU manages space that we open here, in particular giving 32 entries to standards that need one or 2 and did not indicate need for growth...

Cheers

Cheers

Pascal

Le 22 juil. 2015 à 12:03, Thierry LYS <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal,

That would work for me.

I also propose to modify the table of section 4 (for more clarity and precision) of the internet draft "draft-chairs-6lo-dispatch-iana-registry-00.txt"

from

   |       |                                 | [G3-PLC<https://tools.ietf.org/html/draft-chairs-6lo-dispatch-iana-registry-00>]      |

 to
   |       |                                 | [G3-PLC<https://tools.ietf.org/html/draft-chairs-6lo-dispatch-iana-registry-00>]      |

Best regards,

Thierry

De :        [email-masked]<mailto:[email-masked]>
A :        [email-masked]<mailto:[email-masked]>
Cc :        [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Date :        21/07/2015 08:46
Objet :        Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
________________________________

My suggestions are:

What do others think?

Pascal

Hi Samita,

Robert

Hi Robert,

Comments on the draft

=====================

[SC>] OK.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jul 2015 13:16:32 +0200

Thierry - thanks for this suggested change to the registry population.

Can you say more about how code points 0x03-0x15 and 0x17-0x31 are specified in the G.9903 and G.9905 (respectively)?  I ask because it would be somewhat unusual to reserve those code points ahead of their actual inclusion in a protocol specification.  Usually, the code points are assigned as they are defined in a protocol specification to ensure efficient use of the code point space and up-to-date documentation of the code points.

- Ralph

> On Jul 22, 2015, at 12:03 PM 7/22/15, Thierry LYS <[email-masked]> wrote:
> 
> Pascal, 
> 
> That would work for me. 
> 
> 
> Cc :        [email-masked], [email-masked], [email-masked], [email-masked] 
> Date :        21/07/2015 08:46 
> Le 21 juil. 2015 à 00:36, Robert Cragie <[email-masked]> a écrit :
> 
> Hi Samita, 
> 
> On 18 July 2015 at 23:31, Samita Chakrabarti <[email-masked]> wrote:
> Hi Robert,
> 
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 22 Jul 2015 11:52:03 +0000

Hi Ralph,

G.9903 document  9.4.2.3.1 define the command header and table 9-35 shows;

CMSR protocol messages      0x10-0x1F   
[ Used when the default-routing
LOADng is disabled and CMSR
(non-default routing) as
specified in [ITU-T G.9905] is
used in its place.]

And the reference to the assigned bits 0x10-0x1F  is pointing to ITU-T G.9905.

Thierry pointed out these bits toward G.9905 while draft-chairs-6lo-iana-registry-00.txt points to whole 0x1 -01F to  G.9903 (slight mistake).

As we see that some of the values in 1-32  range are reserved  by their respective use in G.9903 and G.9905 respectively.

So here is the corrected proposal for the  draft-chairs-6lo-dispatch-iana-registry update (IANA request):

   | 1-31  | Used by ITU-T G.9903 and G.9905 command ID | ITU-T G.9903, ITU-T G9905 |

I agree that IANA registry does not need to match the details of each value specified in different ITU-T documents.

-Samita

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2015 4:17 AM
To: Thierry LYS
Cc: Pascal Thubert (pthubert); Robert Cragie; Samita Chakrabarti; Jonathan Hui; [email-masked] WG
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

- Ralph

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 22 Jul 2015 05:28:32 -0700

If we designate the relevant ESC region as for Private Use (possibly with a
note that ITU-T makes use of that range), then there is no need to provide
further description of their use.

--
Jonathan Hui

On Wed, Jul 22, 2015 at 4:16 AM, Ralph Droms <[email-masked]> wrote:

> Can you say more about how code points 0x03-0x15 and 0x17-0x31 are
> specified in the G.9903 and G.9905 (respectively)?  I ask because it would
> be somewhat unusual to reserve those code points ahead of their actual
> inclusion in a protocol specification.  Usually, the code points are
> assigned as they are defined in a protocol specification to ensure
> efficient use of the code point space and up-to-date documentation of the
> code points.
>
> - Ralph
>
>
> > - provide guidance on NALP before anyone uses it like ITU did with ESC.
> My recommendation there would be the NALP is defined only when used in the
> > I am not sure what "for different usage of 6lowpan applications" means.
> I would have thought "for future definition" would be more appropriate.
> behind that sentence.
> > "Note that section 5.1 in RFC4944 indicates that the Extension Type
> field may contain additional dispatch values (larger than 63)."
> >
> >
> > The value in RFC 4944 is 127, which IIRC was agreed on the mailing list
> to be wrong (a hangover from earlier drafts) and should be 63. This should
> be clarified here.
> >
> > [SC>] We need to revisit the IANA bits/values based on the discussions
> on this list. I understand your concern and the point is taken.
> >
> >
> > <RCC>I don't mind what language is used as long as it is clear that it
> is reserved for future use. This should prevent or at least hopefully
> discourage use</RCC>
> >

---

From: Paul Duffy <[email-masked]>
Date: Wed, 22 Jul 2015 08:37:59 -0400

My read of 9903 table 35 is that ITU is reserving values 0x03-0x0F as 
reserved for ITU future use.

I do not agree that this assignment should be granted by IETF. It 
represents 5% of the limited ESC-ed dispatch values for possible future 
ITU  usage. I would prefer instead, if ITU desires to use additional 
ESC-ed dispatch values, that they use the vendor extension mechanism 
under discussion.

---

From: Don Sturek <[email-masked]>
Date: Wed, 22 Jul 2015 13:08:34 -0700

Agree completely.  We need a single ESC value for guest protocols.  Together with an OUI that the vendor/organization is assigned, this provides a complete namespace.

Please don't assign/reserve the large space of dispatch values until this is thought through or it will become the next generation "mesh under header" problem.

Don

Sent from my iPad

> On Jul 20, 2015, at 11:45 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 22 Jul 2015 21:43:07 +0000

Hi Pascal,

We discussed it in person. But for clarification purpose, I am responding to this email.

See in-line.

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Thursday, July 09, 2015 5:00 AM
To: Jonathan Hui; Samita Chakrabarti
Cc: Thierry LYS ([email-masked]); [email-masked]
Subject: RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

I think that granting 6LoWPAN formats after the fact without a chance to discuss what goes where in that grant is a mistake that create the wrong type of precedent.
[SC>]  At the meeting(July 20th), we have discussed ITU-T code-space assignment and possible solutions at length and WG response was taken with hum and email of the quorum and liaison statement text was shared.

We have proposed to use the current ESC sequence (01 000000) for ITU-T and for other possible organization specific usage(TBD). But only allocate code-space for which we have specs (G.9903 and G.9905).

We are going to define a new ESC byte or will call that ‘Dispatch Extention Tag” or something similar to allow the WG to define a TLV structure and use it for different purpose – one of that could be link-specific. Though we need to be careful and see we don’t waste codespace in anticipation.

We can definitely start looking into 6loRH draft as a starting point for the new ‘Dispatch Extension Tag(DET)”…

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jul 2015 12:22:38 +0000

Dear all:

It seems that we are finding a way which is workable and acceptable to all parties to extend 6LoWPAN with a TLV format. Not my favorite, I really think that Jonathan has the best proposal on the table. But if this is the one thing that can make a consensus, I’ll gladly go for it.

The method is described in more details as option 2 In section 3.2 of the 6LoRH draft https://www.ietf.org/id/draft-thubert-6lo-routing-dispatch-05.txt

If the group agrees with the chairs on this approach, I can rapidly republish the draft cleaning up the leftovers of the other options so we can move forward with 6lo compression work that RPL is expecting from us. That would be really welcome for the next ETSI plugtest.

Let us confirm at the WG today and on this list.

If/when that is behind us, my question to the WG will be whether folks want:
1) to split the doc in 2 to separate the TLV proper in a short document, or
2) if it is OK to keep the draft in one piece as it is today, using the first values of the type for RPL packet artifacts

The former 1) leads to a quicker delivery of the TLV alone, so other work can safely start using it.

The latter 2) is a quicker path for RPL compression since we do not need to advance 2 documents; it also has the advantage to illustrate why we suggest to have the type and the length structured the way they are. Rather to advance a format with no example usage.

What do people think?

Pascal

From: Samita Chakrabarti [mailto:[email-masked]]
Sent: mercredi 22 juillet 2015 23:43
To: Pascal Thubert (pthubert); Jonathan Hui
Cc: Thierry LYS ([email-masked]); [email-masked]
Subject: RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Hi Pascal,

See in-line.

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 23 Jul 2015 14:32:24 +0200

Hi,

I'm also in favor of option 2), but only keep headers that are already
published as RFCs. Otherwise it could delay 6loRH standardisation process.

Laurent

On Thu, Jul 23, 2015 at 2:22 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Dear all:
>
>
>
> It seems that we are finding a way which is workable and acceptable to all
> parties to extend 6LoWPAN with a TLV format. Not my favorite, I really
> think that Jonathan has the best proposal on the table. But if this is the
> one thing that can make a consensus, I’ll gladly go for it.
>
>
>
> The method is described in more details as option 2 In section 3.2 of the
> 6LoRH draft
> https://www.ietf.org/id/draft-thubert-6lo-routing-dispatch-05.txt
>
>
>
> If the group agrees with the chairs on this approach, I can rapidly
> republish the draft cleaning up the leftovers of the other options so we
> can move forward with 6lo compression work that RPL is expecting from us.
> That would be really welcome for the next ETSI plugtest.
>
>
>
> 2) if it is OK to keep the draft in one piece as it is today, using the
> first values of the type for RPL packet artifacts
>
>
>
> The latter 2) is a quicker path for RPL compression since we do not need
> to advance 2 documents; it also has the advantage to illustrate why we
> suggest to have the type and the length structured the way they are. Rather
> to advance a format with no example usage.
>
>
>
> What do people think?
>
>
>
> Pascal
>
>
>
> *From:* Samita Chakrabarti [mailto:[email-masked]]
> *Sent:* mercredi 22 juillet 2015 23:43
> *To:* Pascal Thubert (pthubert); Jonathan Hui
> *Subject:* RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>
>
>
> Hi Pascal,
>
>
>
> *From:* Pascal Thubert (pthubert) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, July 09, 2015 5:00 AM
> *To:* Jonathan Hui; Samita Chakrabarti
> *Subject:* RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>
>
>
> *[SC>]  At the meeting(July 20th), we have discussed ITU-T code-space
> assignment and possible solutions at length and WG response was taken with
> hum and email of the quorum and liaison statement text was shared.*
>
>
>
>
>
> *We have proposed to use the current ESC sequence (01 000000) for ITU-T
> and for other possible organization specific usage(TBD). But only allocate
> code-space for which we have specs (G.9903 and G.9905).*
>
>
>
> *We are going to define a new ESC byte or will call that ‘Dispatch
> Extention Tag” or something similar to allow the WG to define a TLV
> structure and use it for different purpose – one of that could be
> link-specific. Though we need to be careful and see we don’t waste
> codespace in anticipation.*
>
>
>
> *We can definitely start looking into 6loRH draft as a starting point for
> the new ‘Dispatch Extension Tag(DET)”…*
>
>
>
> *Cheers,*
>
> *-Samita*
>
>
>
>
>
> *From:* 6lo [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Jonathan Hui

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 30 96 6312    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 23 Jul 2015 12:46:31 +0000

Hi Pascal:

For RPL compression context, option-2 is  the best choice.

Can you clarify a bit on the following text in section  3.2?

“Finally, the specification indicates that Fragments Headers must
   always preceed Routing header.

   As a result, the 11111111 pattern could be considered a delimiminator
   between a portion of the frame that is formatted per [RFC4944] on the
   left, and a portion from which the space for Mesh Header, Fragment
   Header and NALP can be reused, on the right.  This specification
   would reuse the Mesh Header or the NALP as discuused above, so the
   text in this specification is not impacted.”

Q1 – Why do you want to put Routing header behind Fragment header?  Should not the routing header be looked at next hop ?

NALP means not-a-lowpan header --  are you trying to say it’s RPL Routing header instead of lowpan header(IPV6+payload)?

It will be a good idea if your draft draws an example of  sequence of headers.

For example in RFC4944:
      +-----------+-------------+--------------+------------+---------+
      | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
      +-----------+-------------+--------------+------------+---------+

Finally,  we are going to discuss in the WG about the design of next set of ESC-style bytes; Johnathan’s ideas were good and Johnathan will be also involved in the discussion for the definition of common ‘Dispatch Extension Tag’.

Are you going to use Mesh header to route the compressed RPL packet ?

Thanks,
-Samita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 5:23 AM
To: Samita Chakrabarti; Jonathan Hui
Cc: [email-masked]
Subject: RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Dear all:

What do people think?

Pascal

Hi Pascal,

See in-line.

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 23 Jul 2015 08:23:16 -0700

Pascal,

Section 3.2 uses a particular Dispatch value to delineate that everything
before should utilize header identifiers as allocated in the Dispatch value
registry and everything after utilize header identifiers proposed in this
draft.

My concern is that it becomes very difficult to truly mix the use of 6lo
headers.  This draft defines how to map RFC 4944 Mesh Header into the the
new header identifier space.  The MH-6LoRH definition is not just a simple
change in the header identification, but it also changes the header
encoding itself (HopsLft comes before the V and F flags).  This draft also
chooses not to map the RFC 4944 Fragment Header into the new space, so does
not define a mapping.

In any case, my main concern is that any new definition of 6lo headers will
need to show multiple definitions, one for the old (RFC 4944) and one for
the new (draft-thubert-6lo-routing-dispatch).

I would much prefer an approach that makes it possible to have a single
header definition, regardless of how the headers are ordered within the 6lo
packet.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jul 2015 19:04:53 +0000

Hello Jonathan:

Multiple things here.

One is that I agree with your view and will support it. 6LoRH will work the same either way but we'd save one octet if your ether type is implicit vs. the new explicit dispatch in 3.2

But if your view is too hard to swallow for the group or the world at large then I'll opt for the compromise. This page marker (I like Robert's view here) allows to reuse most of the space and the cost is just one octet, same as making ether type explicit.

Now if the group takes the page marker approach, the mesh header will disappear from 6LoRH. That's because MH-6LoRH was an artifact only needed in the approach in section 3.1

With 3.2, if you need fragments or mesh or NALP from RFC 4944 then you place them first in the compressed packet. When you're all done with 4944 you place the marker (you pick another  coding page) and the space is available again. But since mesh and fragments were already done, the capability to encode them again is not required.

Summary is that your opposition WRT MH and frags is not valid; but I still agree with your bottom line.

Pascal

Le 23 juil. 2015 à 17:23, Jonathan Hui <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal,

Section 3.2 uses a particular Dispatch value to delineate that everything before should utilize header identifiers as allocated in the Dispatch value registry and everything after utilize header identifiers proposed in this draft.

My concern is that it becomes very difficult to truly mix the use of 6lo headers.  This draft defines how to map RFC 4944 Mesh Header into the the new header identifier space.  The MH-6LoRH definition is not just a simple change in the header identification, but it also changes the header encoding itself (HopsLft comes before the V and F flags).  This draft also chooses not to map the RFC 4944 Fragment Header into the new space, so does not define a mapping.

In any case, my main concern is that any new definition of 6lo headers will need to show multiple definitions, one for the old (RFC 4944) and one for the new (draft-thubert-6lo-routing-dispatch).

I would much prefer an approach that makes it possible to have a single header definition, regardless of how the headers are ordered within the 6lo packet.

--
Jonathan Hui

On Thu, Jul 23, 2015 at 5:22 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

What do people think?

Pascal

From: Samita Chakrabarti [mailto:[email-masked]<mailto:[email-masked]>]

Hi Pascal,

See in-line.

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 23 Jul 2015 12:25:49 -0700

Hi Pascal,

The compromise may be more significant than at first glance.

The "page marker" effectively creates two namespaces.  Headers within a
namespace must be contiguous.  RFC 4944 namespace must come before 6LoRH
namespace.  That limits the flexility of 6lo headers.

What if someone actually wanted to define a new 6lo header that may be used
before or after the page marker?  The definition of that new 6lo header
must be defined for both the RFC 4944 namespace and the 6LoRH namespace.

For example, what if I wanted to use source routing to deliver a 6lo header
to a particular destination?  It would be nice to use the existing 6LoRH
header format.  But currently not possible since we've already left the RFC
4944 namespace after processing the source route header.

In another example, what if someone came up with a much better way to do
IPv6 datagram compression?  That person would need to define encodings for
both RFC 4944 and 6LoRH to support both.  And because RFC 4944 and 6LoRH
have different ways of identifying headers, there will be wasted bits
somewhere.

--
Jonathan Hui

On Thu, Jul 23, 2015 at 12:04 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Jonathan:
>
>  Multiple things here.
>
>  One is that I agree with your view and will support it. 6LoRH will work
> the same either way but we'd save one octet if your ether type is implicit
> vs. the new explicit dispatch in 3.2
>
>  But if your view is too hard to swallow for the group or the world at
> large then I'll opt for the compromise. This page marker (I like Robert's
> view here) allows to reuse most of the space and the cost is just one
> octet, same as making ether type explicit.
>
>  Now if the group takes the page marker approach, the mesh header will
> disappear from 6LoRH. That's because MH-6LoRH was an artifact only needed
> in the approach in section 3.1
>
>  With 3.2, if you need fragments or mesh or NALP from RFC 4944 then you
> place them first in the compressed packet. When you're all done with 4944
> you place the marker (you pick another  coding page) and the space is
> available again. But since mesh and fragments were already done, the
> capability to encode them again is not required.
>
> Le 23 juil. 2015 à 17:23, Jonathan Hui <[email-masked]> a écrit :
>
>   Pascal,
>
>  Section 3.2 uses a particular Dispatch value to delineate that
> everything before should utilize header identifiers as allocated in the
> Dispatch value registry and everything after utilize header identifiers
> proposed in this draft.
>
>  In any case, my main concern is that any new definition of 6lo headers
> will need to show multiple definitions, one for the old (RFC 4944) and one
> for the new (draft-thubert-6lo-routing-dispatch).
>
>> It seems that we are finding a way which is workable and acceptable to
>> all parties to extend 6LoWPAN with a TLV format. Not my favorite, I really
>> -        6LoRH has built-in a signal that a header can be ignored.
>> That’s a lesson we learnt from IPv6 Option Type identifiers encoding. When
>> the header can be ignored, the size to skip is provided in octets.
>>
>> As Carsten mentioned, whether or not additional headers are encoded
>> within the ESC range is a separate consideration.  But if such additional
>> headers are encoded within the ESC range, then it is of interest to this
>> draft.
>>
>>
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jul 2015 19:34:55 +0000

True, Jonathan.

In fact that’s already the case with RFC 6282… That space is booked on both pages.

Cheers,

Pascal

From: Jonathan Hui [mailto:[email-masked]]
Sent: jeudi 23 juillet 2015 21:26
To: Pascal Thubert (pthubert)
Cc: Samita Chakrabarti; [email-masked]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Hi Pascal,

The "page marker" effectively creates two namespaces.  Headers within a namespace must be contiguous.  RFC 4944 namespace must come before 6LoRH namespace.  That limits the flexility of 6lo headers.

What if someone actually wanted to define a new 6lo header that may be used before or after the page marker?  The definition of that new 6lo header must be defined for both the RFC 4944 namespace and the 6LoRH namespace.

For example, what if I wanted to use source routing to deliver a 6lo header to a particular destination?  It would be nice to use the existing 6LoRH header format.  But currently not possible since we've already left the RFC 4944 namespace after processing the source route header.

In another example, what if someone came up with a much better way to do IPv6 datagram compression?  That person would need to define encodings for both RFC 4944 and 6LoRH to support both.  And because RFC 4944 and 6LoRH have different ways of identifying headers, there will be wasted bits somewhere.

--
Jonathan Hui

On Thu, Jul 23, 2015 at 12:04 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Jonathan:

Multiple things here.

Pascal

--
Jonathan Hui

What do people think?

Pascal

Hi Pascal,

See in-line.

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jul 2015 19:39:12 +0000

Hello Samita: please see below

Ø  The 6LoRH encoding does not change the precedence of 6LoWPAn frags vs. IPv6 routing headers. 6LoWPAN Frag is lower layer.
You have to reassemble the packet at every hop. Then you have an IPv6 packet and you can operate the Routing header.

Ø  I mean that we’ll specify more clearly that 00xxxxxx means NALP only when placed in the RFC 4944 page. After the new page break, the packet is determined to be a 6LoWPAN packet so it is not a NALP so the 00xxxxxx space can be used for encoding new stuff;

For example in RFC4944:

Ø  Yes, will do.

Ø    Fantastic. The 6LoRH work does not depend on whether we do the page break or follow Jonathan’s proposal since these are 2 candidate ways to indicate that 6LoRH is present in the packet.

Ø    No, Samita. This was an artifact of option 3.1 where we reused the same encoding space. That option is no more on the table.

Have a safe trip back!

Pascal

Thanks,
-Samita

Cc: [email-masked]<mailto:[email-masked]>

Dear all:

What do people think?

Pascal

Hi Pascal,

See in-line.

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 23 Jul 2015 13:15:13 -0700

Pascal,

If defining a new 6lo namespace is a path forward, then I'd rather be very
explicit about it and take full advantage of that opportunity.  I know that
the existing draft was somewhat constrained in making some attempt to
respect the existing Dispatch values, but now we are free.

For example, only define two types of headers (elective and critical) and
only use a single bit to distinguish between them.  Then cast everything
(including RFC 4944 and RFC 6282) within those headers.  For example, don't
bother to reserve 00xxxxxx for something else.

With my experience in using IEEE 802.15.4e-2012 Information Elements, I
have felt for a long time that 6lo headers can benefit from a TLV
structure.  It's good to see that here.

At the same time, I still think it's useful to be able to assign blocks of
type values to specific headers so that headers that need an extra bit or
two of control can do that without consume a whole number byte.  But that
would mean we run into the same issue we do today in deciding how best to
assign type values.  As a result, I still find it useful to be able to have
come context that identifies 6lo headers are in use - much in the same way
contexts are needed to understand compressed IPv6 addresses.  In the
latter, we are effectively configuring how 4-bit identifiers map to
particular IPv6 prefixes.  But this idea can apply to both 6LoRH and RFC
4944 and should be treated as such.

--
Jonathan Hui

On Thu, Jul 23, 2015 at 12:34 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> *Sent:* jeudi 23 juillet 2015 21:26
> *Cc:* Samita Chakrabarti; [email-masked]
> What if someone actually wanted to define a new 6lo header that may be
> used before or after the page marker?  The definition of that new 6lo
> header must be defined for both the RFC 4944 namespace and the 6LoRH
> namespace.
>
>
>
> For example, what if I wanted to use source routing to deliver a 6lo
> header to a particular destination?  It would be nice to use the existing
> 6LoRH header format.  But currently not possible since we've already left
> the RFC 4944 namespace after processing the source route header.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jul 2015 20:34:05 +0000

Hello Jonathan

If defining a new 6lo namespace is a path forward, then I'd rather be very explicit about it and take full advantage of that opportunity.  I know that the existing draft was somewhat constrained in making some attempt to respect the existing Dispatch values, but now we are free.

Ø    Indeed.

For example, only define two types of headers (elective and critical) and only use a single bit to distinguish between them.  Then cast everything (including RFC 4944 and RFC 6282) within those headers.  For example, don't bother to reserve 00xxxxxx for something else.

Ø    Why bother casting 4944 stuff? It is already on page one. Could you clarify?

With my experience in using IEEE 802.15.4e-2012 Information Elements, I have felt for a long time that 6lo headers can benefit from a TLV structure.  It's good to see that here.

Ø    yup

At the same time, I still think it's useful to be able to assign blocks of type values to specific headers so that headers that need an extra bit or two of control can do that without consume a whole number byte.  But that would mean we run into the same issue we do today in deciding how best to assign type values.  As a result, I still find it useful to be able to have come context that identifies 6lo headers are in use - much in the same way contexts are needed to understand compressed IPv6 addresses.  In the latter, we are effectively configuring how 4-bit identifiers map to particular IPv6 prefixes.  But this idea can apply to both 6LoRH and RFC 4944 and should be treated as such.

Ø    Could be useful, yes. We could also use context to compress things deeper into CoAP.

Have a safe trip back,

Pascal

--
Jonathan Hui

On Thu, Jul 23, 2015 at 12:34 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
True, Jonathan.

Cheers,

Pascal

Cc: Samita Chakrabarti; [email-masked]<mailto:[email-masked]>

Hi Pascal,

--
Jonathan Hui

Multiple things here.

Pascal

--
Jonathan Hui

What do people think?

Pascal

Hi Pascal,

See in-line.

Cheers,
-Samita

A few remarks:

Cheers,

Pascal

Cheers,

Pascal

Hi Samita,

See below:

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 23 Jul 2015 13:53:56 -0700

> Ø    Why bother casting 4944 stuff? It is already on page one. Could you
What if I want to use the same 6loRH header to source route individual 6lo
fragments?  Yes, doing so incurs the overhead of source routing on each
fragment, but then there is no need to reassemble at every hop and allows
sending fragments along different paths.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 25 Jul 2015 15:08:23 +0000

Hello Jonathan:

We discussed that an it confused folks. So it was removed from the last draft.
Clearly the proposal 3.2 eliminates a capability to use RFC 4944 stuff after the page is passed.
If we wanted to restore that, we’d define a page for RFC 4944 that is implicit today.
I’m not saying that this is better than your proposition since IMHO it is not.
But I want to clarify what’s on the table…

Cheers,

Pascal

Sent: jeudi 23 juillet 2015 22:54

On Thu, Jul 23, 2015 at 1:34 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

>    Why bother casting 4944 stuff? It is already on page one. Could you clarify?
What if I want to use the same 6loRH header to source route individual 6lo fragments?  Yes, doing so incurs the overhead of source routing on each fragment, but then there is no need to reassemble at every hop and allows sending fragments along different paths.

--
Jonathan Hui

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Jul 2015 17:31:44 -0400

> external entities can administer on their own, starting with ITU.

My understanding is that IANA will take care of the space, so I don't think
we should call it "guest" protocols; they are just (layer-2) "protocols"

    > - provide guidance on NALP before anyone uses it like ITU did with
    > ESC. My recommendation there would be the NALP is defined only when
    > used in the first octet of the payload to distinguish an alien
    > protocol. This will allow to reuse the dispatch space inside a 6lo
    > packet when we run out of space.

I am in favour of specifying rules before we need them, but not too far in
advance.  As such, I suggest that we establish IANA guidance for the space.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Jul 2015 17:34:30 -0400

Jonathan Hui <[email-masked]> wrote:
    > If we designate the relevant ESC region as for Private Use (possibly
    > with a note that ITU-T makes use of that range), then there is no need
    > to provide further description of their use.

I don't think that "Private Use" in an appropriate description of how ITU-T
uses this space.   Private Use means that I use it for my own network,
and I never tell anyone else about how/when I use it.
In particular, I don't write specifications for others to follow.

---

From: Robert Cragie <[email-masked]>
Date: Mon, 27 Jul 2015 10:36:28 +0100

Hi Jonathan,

For most efficient use, i.e. just one extra octet per packet, you basically
have to redefine the whole page as you would use that code (e.g. 01 000011)
to switch to page 1 at the beginning of the packet. Some of that may be
new, some could be carried over from "page 0" (i.e. the existing dispatch
code space). This gives the most flexibility, however the main downside as
I see it is that it is no longer 6LoWPAN as originally defined. It might
also be useful to have a "switch to page 0" code in page 1 to potentially
allow the insertion of an extra byte to switch back to the original
dispatch codes. We could even allocate all codes from 01 000011 to 01
001111 as page switching codes, although that might be a step too far for
some people.

There are no repurposing issues as the new page is a completely new code
space and would be managed by IANA.

Also, just to be clear (as it seems to be getting mixed up in this thread),
this should be completely distinct from the ESC discussion, which should go
ahead as planned. In that discussion, I believe only the code points
currently used by ITU-T should be allocated but this should include
anything they have reserved. Looking at the union of codes, that does mean
0x01-0x1F as far as I can see. I think that is what we agreed in the
liaison statement.

Robert

---

From: Robert Cragie <[email-masked]>
Date: Mon, 27 Jul 2015 10:48:30 +0100

Hi Michael,

I think Jonathan's recommendation is the right one. Most importantly, the
uses as defined in G.9903 or G.9905 are not related to 6LoWPAN in any way
as broadly speaking they are command frames for a mesh-under protocol. For
that reason, I would say that "private use" is actually quite appropriate
and highlights the fact that NALP frames should probably have been used
here.

Robert

---

From: Paul Duffy <[email-masked]>
Date: Mon, 27 Jul 2015 08:06:40 -0400

+1

On 7/27/2015 5:48 AM, Robert Cragie wrote:
> Hi Michael,
>
> I think Jonathan's recommendation is the right one. Most importantly, 
> the uses as defined in G.9903 or G.9905 are not related to 6LoWPAN in 
> any way as broadly speaking they are command frames for a mesh-under 
> protocol. For that reason, I would say that "private use" is actually 
> quite appropriate and highlights the fact that NALP frames should 
> probably have been used here.
>
> Robert
>
> On 26 July 2015 at 22:34, Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Jonathan Hui <[email-masked] <mailto:[email-masked]>> wrote:
>     Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works
>     [email-masked] <mailto:[email-masked]>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 28 Jul 2015 10:08:39 -0700

Having the "page switch" markers effectively increases the Dispatch space
to 2 octets or more, with a compression mechanism that allows consecutive
headers from the same page to elide the the first octet.  In the limit, if
I wanted to keep switching between the two spaces, then I incur one byte
overhead for each header.  Though, I agree that is a fairly contrived case.

Currently, we are going down a path where every 6LoWPAN network in
existence needs to respect the same header identifiers (i.e. Dispatch
values) at all times.  It's not obvious to me that this is a good idea.

For example, two devices in the field could easily determine what headers
are actually in use and the corresponding header identifiers.  In one view,
this is not much different than establishing 6LoWPAN contexts.  A 6LoWPAN
network already determines what prefixes are in use and binds short forms
(4-bit Context IDs) to those.  If there is ever any confusion on how those
4-bit Context IDs are assigned, then things will fail.  Typically, we
expect to use IEEE 802.15.4 security mechanisms to isolate networks.  After
devices establish a secure link, there is no need to worry about processing
packets that not a part of that secure link.  We could apply the same logic
to Dispatch values and forgo the overhead of "page switch" markers.

As a side note, strictly speaking, RFC 4944 was defined for IEEE
802.15.4-2003 and RFC 6282 defined for IEEE 802.15.4-2006.  In theory, we
could easily define a new Dispatch mechanism for TSCH (IEEE
802.15.4e-2012).  The frames are distinguishable using the IEEE 802.15.4
Frame Version field.

--
Jonathan Hui

On Mon, Jul 27, 2015 at 2:36 AM, Robert Cragie <[email-masked]>
wrote:

> Hi Jonathan,
>
> For most efficient use, i.e. just one extra octet per packet, you
> basically have to redefine the whole page as you would use that code (e.g.
> 01 000011) to switch to page 1 at the beginning of the packet. Some of that
> may be new, some could be carried over from "page 0" (i.e. the existing
> dispatch code space). This gives the most flexibility, however the main
> downside as I see it is that it is no longer 6LoWPAN as originally defined.
> It might also be useful to have a "switch to page 0" code in page 1 to
> potentially allow the insertion of an extra byte to switch back to the
> original dispatch codes. We could even allocate all codes from 01 000011 to
> 01 001111 as page switching codes, although that might be a step too far
> for some people.
>
> Also, just to be clear (as it seems to be getting mixed up in this
> thread), this should be completely distinct from the ESC discussion, which
> should go ahead as planned. In that discussion, I believe only the code
> points currently used by ITU-T should be allocated but this should include
>> If defining a new 6lo namespace is a path forward, then I'd rather be
>> very explicit about it and take full advantage of that opportunity.  I know
>> that the existing draft was somewhat constrained in making some attempt to
>> At the same time, I still think it's useful to be able to assign blocks
>> of type values to specific headers so that headers that need an extra bit
>> or two of control can do that without consume a whole number byte.  But
>> that would mean we run into the same issue we do today in deciding how best
>> to assign type values.  As a result, I still find it useful to be able to
>> have come context that identifies 6lo headers are in use - much in the same
>> way contexts are needed to understand compressed IPv6 addresses.  In the
>>> The method is described in more details as option 2 In section 3.2 of
>>> the 6LoRH draft
>>> *We can definitely start looking into 6loRH draft as a starting point
>>> for the new ‘Dispatch Extension Tag(DET)”…*
>>>
>>>
>>>
>>> *Cheers,*
>>>
>>> *-Samita*
>>>
>>>
>>>
>>>
>>>
>>> *The question we probably need to answer – what would be the use-cases
>>> in different scenarios?  *
>>>
>>>
>>>
>>> If history is any indication, we can't possibly foresee all important
>>> use cases that may come up in the future.
>>>
>>>
>>>
>>>    *What was the original intention of having ESC bytes?  Could ESC
>>> byte be considered as 6lowpan extension header? [ like IPv6 extension
>>> headers? ]*
>>>
>>>
>>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 28 Jul 2015 21:39:53 +0200

Hi

JH>> "Currently, we are going down a path where every 6LoWPAN network in
existence needs to respect the same header identifiers (i.e. Dispatch
values) at all times. JH>> It's not obvious to me that this is a good idea."

+1

I like the idea of having a clear dispatch mechanism per technology, in
that way technologies that will never coexist will not add complexity and
constraints to the size of the packets. At the end a 6LBR now is bridging
coexisting technologies and applying the specific considerations as
described in the respective RFCs (e.g IPv6 over NFC vs IPv6 over BTLE vs
IPv6 over 15.4). What is the difference of that and having different
documents explaining how to manage the complete dispatch space according to
the underlying technology? IMHO the second case seems cleaner.

regards,
Xavi

2015-07-28 19:08 GMT+02:00 Jonathan Hui <[email-masked]>:

> On Mon, Jul 27, 2015 at 2:36 AM, Robert Cragie <
> [email-masked]> wrote:
>
>> Hi Jonathan,
>>
>>> For example, only define two types of headers (elective and critical)
>>> and only use a single bit to distinguish between them.  Then cast
>>> everything (including RFC 4944 and RFC 6282) within those headers.  For
>>> example, don't bother to reserve 00xxxxxx for something else.
>>>
>>>> In another example, what if someone came up with a much better way to
>>>> do IPv6 datagram compression?  That person would need to define encodings
>>>> for both RFC 4944 and 6LoRH to support both.  And because RFC 4944 and
>>>> 6LoRH have different ways of identifying headers, there will be wasted bits
>>>> somewhere.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Jonathan Hui
>>>>
>>>>
>>>>
>>>> My concern is that it becomes very difficult to truly mix the use of
>>>> 6lo headers.  This draft defines how to map RFC 4944 Mesh Header into the
>>>> the new header identifier space.  The MH-6LoRH definition is not just a
>>>> simple change in the header identification, but it also changes the header
>>>> The latter 2) is a quicker path for RPL compression since we do not
>>>> need to advance 2 documents; it also has the advantage to illustrate why we
>>>> I think that granting 6LoWPAN formats after the fact without a chance
>>>> to discuss what goes where in that grant is a mistake that create the wrong
>>>> type of precedent.
>>>>
>>>> What if another group also escaped its own stuff and used the same
>>>> codes and comes tomorrow asking us the same range? Or any range? Why them
>>>> and not us?
>>>>
>>>>
>>>>
>>>> We are pretty much in the mirror situation as the desire to reuse the
>>>> MH space for 6LoRH. This becomes a problem of relation between not just 2
>>>> but an unknown number of other standardization bodies. At the end of the
>>>> day, this is the core reason why there are some rules, and the reason why
>>>> we are reconsidering the 6LoRH not to overlap with MH.
>>>>
>>>>
>>>>
>>>> A few remarks:
>>>>
>>>>
>>>>
>>>> That's really up to how we define ESC headers, but I think it would be
>>>> a mistake not to allow ESC headers to occur multiple times.
>>>>
>>>>
>>>>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Jul 2015 21:06:43 +0100

Hi Jonathan,

Comments inline.

Robert

> overhead for each header.  Though, I agree that is a fairly contrived case.

<RCC>There is also the uncompressed/stateless case where you have to
qualify every dispatch code with an associated page code, which becomes
more like an escape code (ESC). The idea of a switch and subsequently
remembering the page code is perfectly logical from a parsing perspective
as state is implied in parsing anyway, so the stateless case (whereby you
lose state at the end of processing every dispatch code) seems somewhat
wasteful.</RCC>

> to Dispatch values and forgo the overhead of "page switch" markers.

<RCC>That is true, but we already discussed this and tried this to some
extent with the repurposing of the mesh header. That isn't defining a whole
new set of codes for a new technology but is tantamount to it. It didn't
seem to go down well, hence the idea of page codes/markers.</RCC>

> 802.15.4e-2012).  The frames are distinguishable using the IEEE 802.15.4

<RCC>Indeed we could. Perhaps a wholesale change might actually be more
palatable than just repurposing some of the dispatch code space?</RCC>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 28 Jul 2015 13:38:54 -0700

Robert,

> seem to go down well, hence the idea of page codes/markers.</RCC>

I understand why the particular design choices were made in the current
draft.

FWIW, I don't think flat out repurposing the Mesh Header was the right
approach.  It basically meant that the RFC 4944 Mesh Header is never to be
used at the same time as a 6LoRH.  Some have argued that it becomes
confusing when 6lo implementations are just following RFCs (rather than
some external alliance) as to what Dispatch values to use, and I can
understand that viewpoint as well.

Instead, I think a better approach is to be explicit and say that devices
can configure what 6lo headers are in use and how those headers are
identified in a packet.  Still maintain a single "default" namespace that
devices use if no such configuration is used or available.  But the
configuration allows devices to use more efficient header identifiers if
they choose to do so.  As mentioned previously, this is not much different
from assigning 4-bit Context IDs to IPv6 prefixes.  The difference is that
the 6lo header configuration will typically be static, so distributing the
configuration is much simpler than what's required for Context IDs.

The result is that no new 6lo header definition "supersedes" an existing
one.  Instead, new 6lo header definitions can be defined within the
existing RFC 4944 Dispatch space and implementations could agree on more
efficient identifiers if they choose to do so.  The implementation cost is
simply a jump table with dynamic value, rather than static ones.

> palatable than just repurposing some of the dispatch code space?</RCC>

Certainly something to consider.

--
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Wed, 29 Jul 2015 09:34:46 +0100

Hi Jonathan,

More comments inline, bracketed by <RCC2></RCC2>

Robert

On 28 July 2015 at 21:38, Jonathan Hui <[email-masked]> wrote:

> Robert,
>
> On Tue, Jul 28, 2015 at 1:06 PM, Robert Cragie <
>>> For example, two devices in the field could easily determine what
>>> headers are actually in use and the corresponding header identifiers.  In
>>> one view, this is not much different than establishing 6LoWPAN contexts.  A
>>> 6LoWPAN network already determines what prefixes are in use and binds short
>>> forms (4-bit Context IDs) to those.  If there is ever any confusion on how
>>> those 4-bit Context IDs are assigned, then things will fail.  Typically, we
> used at the same time as a 6LoRH.
>

<RCC2>That was the point, as 6LoRH redefines the mesh header. Therefore you
would never use RFC 4944 mesh header and 6LoRH together as you would never
need to.</RCC2>

>   Some have argued that it becomes confusing when 6lo implementations are
> just following RFCs (rather than some external alliance) as to what
> Dispatch values to use, and I can understand that viewpoint as well.
>

<RCC2>
I can understand the viewpoint but cast on its own, it is somewhat
meaningless. If put into context then it makes more sense.

In an abstract sense, there is what I call a "hierarchy of constraints". By
this I mean at lower ranks, more things are optional and superior ranks
reclassify options into mandatory or excluded. At the top of the hierarchy,
an interoperable implementation can be built where devices can autonomously
figure out based on a configuration how they operate. In this case, the
superior rank to the RFC rank simply states which dispatch codes are being
used and which aren't.

For example, the mesh dispatch code is never used in ZigBee IP so we said
it was excluded, i.e. if a device receives a packet with a mesh header, it
is silently discarded and devices should never generate them under normal
operation. I don't see what is particularly confusing about this.

TL;DR: I guess what I am trying to say is that it probably is confusing
just following the RFCs as you inevitably need some hierarchy of
constraints above. If you don't have that, interoperability will be
difficult to achieve.
</RCC2>

> they choose to do so.

<RCC2>The only obvious issue I can see here is variable length dispatch
codes. For example, NALP and MESH are both 2 bits, thus giving 6 bits of
the remaining octet to the subsequent data. In this way, it could be
difficult to define generic 6lo headers which would fit into an arbitrarily
allocated dispatch space</RCC2>

>   As mentioned previously, this is not much different from assigning 4-bit
> Context IDs to IPv6 prefixes.  The difference is that the 6lo header
> configuration will typically be static, so distributing the configuration
> is much simpler than what's required for Context IDs.
>

<RCC2>It's not much different in that it is stateful but I think that's
where the similarities end. The page configuration(s) would really have to
be innate in a device. If there is only one innate page configuration, then
no page identifiers are needed as you say. I am not sure how a device could
dynamically learn pages unless there is some sort of "dispatch code schema"
and I don't think we are proposing that?</RCC2>

> simply a jump table with dynamic value, rather than static ones.

<RCC2>The concept of pages is key to this though. The question comes down
to whether these pages are defined in an IANA registry with (a) possible
page code(s) in the current "page 0" (effectively proposal 2 in
draft-thubert-6lo-routing-dispatch-04) or, as you suggest, defined outside
of IETF. There are certainly some who think that 6lo framing is really
nothing to do with IETF as it is below layer 3 and I think they have a
point. The "wet finger in the air" attempt at MESH and BC0 in RFC 4944 also
bears this out to some extent.</RCC2>

> Certainly something to consider.

<RCC2>Over to the list and WG...</RCC2>

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2015 11:17:46 -0700

On Jul 29, 2015, at 01:34, Robert Cragie <[email-masked]> wrote:
> 
> In an abstract sense, there is what I call a "hierarchy of constraints". By this I mean at lower ranks, more things are optional and superior ranks reclassify options into mandatory or excluded. At the top of the hierarchy, an interoperable implementation can be built where devices can autonomously figure out based on a configuration how they operate. In this case, the superior rank to the RFC rank simply states which dispatch codes are being used and which aren't.

I generally agree that a hierarchy of constraints is a good idea, but where I grow concerned is with protecting the integrity of the least constrained, most general specification. This is where the idea of a switch mechanism makes me uneasy. With a switch, which would permit the alteration of the syntax of 6LO encodings beneath it, we pretty much destroy the idea of a “most general” or “least constrained” syntax. Given any particular 6LO encoded packet it could mean anything depending on the context in which it is inserted, because any particular context might have a switch applied that alters the syntax of the encodings within it. Indeed, in the least constrained language, there is no limit on what switches defined in the future might do to alter the syntax.

I hope we can agree that it’s a bad idea to do that.

—james	[As an individual contributor]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jul 2015 13:20:33 +0000

Hello Michael

On item #2, NALP, I have seen people expecting to find NALP inside a 6LoWPAN.
We need to clarify that it is only define as the very first octet of the data

Cheers,

Pascal

> From: 6lo [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: dimanche 26 juillet 2015 23:32
> To: [email-masked]
> Michael Richardson <[email-masked]>, Sandelman Software
> Works  -= IPv6 IoT consulting =-
> 
>