Subject: Re: [6tisch] removing the 'e'

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 09:22:21 +0000

Hi Jonathan, René and all:

But the point is, we are not working in silos like industrial protocols, defining the whole stack from PHY to APP. We are defining an IETF stack, which happens to be designed to apply above the TSCH mode of in 802.15.4 that was introduced by 802.15.4e.

Because we work on layers as opposed to silos, the 6TiSCH logo guarantees interop at the IP layer, not at the MAC or PHY layers.
E.g. IP (as defined over Ethernet) works on all Wi-Fi versions. But I can hardly connect my old 802.11a card to any network these days. Sad it is, but that is not an IETF problem.
In the hypothetical case that IEEE802.15.4:2015 is not compatible with  "802.15.4-2011 as amended by 802.15.4e-2012", and that 6TiSCH, as specified, works on both without a change, then we should still refer to IEEE802.15.4.

MAC compatibility problems are an IEEE problem, not an IETF problem; there has also been a concern in this thread that the changes on MAC/PHY require too much new work. All this is certainly unfortunate, but it has to be resolved at the IEEE, not on this list.  We have an Interest Group and may leverage it, but still this list is not the right forum and the discussion is taking us way beyond the question I asked to the group.

And because silos are still needed to guarantee interoperability, products that support 6TiSCH will have to bear some logo that indicate what MAC/PHY they use, as well as which security models they support; there will be multiple such logos that bind all that together and guarantee some interoperability and functionality. IOW, it is up to an adopting standard (a ZigbeeIP, an ISA, an IEC, a Thread or an HCF of this world) to be more specific of the whole stack they build upon, and the IETF does not need to have a say in that.

René's suggestion, "802.15.4-2011 as amended by 802.15.4e-2012", would for instance fail to include 802.15.4g. There are shipping products that do TSCH over the sub-Gig in AMI/AMR and SmartGrid use cases, and barring them from moving to 6TiSCH makes no sense. 6TiSCH is probably a great solution for WiNAN. So I am strongly opposed to that limiting wording. From the IEEE perspective, "IEEE802.15.4" *today* means "802.15.4-2011 as amended by 802.15.4e-2012, 802.15.4f-2012,  802.15.4g, 802.15.4j, 802.15.4k, 802.15.4m, and 802.15.4p". For all I know that is *exactly* what we want.

There has also been concerns that 6TiSCH RFCs may fail to work as expected over some future version of 802.15.4. This may become true, and this may be plain FUD. But yes, that is our problem. I'll be asking around if there is a best practice between IEEE and IETF for such thing, above and beyond our particular case. My current research indicates that we have been widely inconsistent so far. One suggestion could be to place a note in the reference, as discussed in RFC4897 though for other purposes. This note could indicate that "this RFC applies to the version of 802.15.4 that is current at the time of publication of this RFC, and that it is expected but not guaranteed that this RFC applies to 802.15.4 versions published after the publication of this RFC".

So the updated action plan that I'm proposing to the group is as follows:
- still, remove the 'e' in the charter; additionally:
- work on a note for the reference to address the questions raised about compatibility with future versions.
- lookup for a best practice in that area (I'm taking that action item but help is welcome)
- task the IEEE 6TiSCH interest group to check whether the current text impacts the 6TiSCH works as it stands (including drafts discussed for re-chartering such as 6top and OTF)

Does this make sense?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: mardi 31 mars 2015 19:02
To: Rene Struik; Kris Pister
Cc: [email-masked]
Subject: Re: [6tisch] removing the 'e'

Chiming in...

I agree with Rene, "802.15.4-2011 as amended by 802.15.4e-2012" is a perfectly valid specification, and one that has formed the basis of a number of products, including my company's.

I believe that Pat is trying to faithfully represent upcoming changes, and that the primary goal of 802.15.4-2015 effort is to correct mistakes and remove ambiguities that might result in different implementations.  Yet there have been a few incompatible changes introduced, perhaps for valid reasons - I would argue the short address doesn't leak info if only authenticating, and doesn't prevent the combination of EUI + ASN + Key from being replayed, so that more moderate informative language could be used to solve this particular problem.  I also think that policing IE's is naive - the IEEE doesn't own the band, and a robust design uses security to ensure that frame content is correct.

So I guess it comes down to two things:

1) are the incompatible changes adding something that is needed for 6TiSCH - if not, we are free in 6TiSCH to override behavior we don't like, e.g. "x is as described in spec y, except for the limitation of clause z, which is taken from spec p, clause q"
2) do we need to see 802.15.4-2015 before adopting it as a normative reference?  Paranoid me says yes, but if people agree to 1) then its not really a problem.

--
Jonathan

Thanks Kris;

Let's review your points:

- IE IDs:  When 15.4e was introduced, we allowed vendors to freely use 25 non-standardized IDs with the explicit warning that another vendor could be using that ID creating a conflict, destroying coexistence. Since that time we have seen a significant number of requests for IE IDs, so given the limited number of IDs and the fact that there really is no vendor coexistence with the original scheme, we changed to one specific vendor ID where the vendor's OUI is required to make the IE unique.

- macTsRxOffset: the basic intent of macTsRxOffset is to center the transmission start within the range of 2200 µs (macTSRxWait). So the transmitter's macTsTxOffset (2120µs) should be 1100µs (macTsRxWait/2) greater than macTxRxOffset(1020µs).  However, 15.4e mistakenly used the term "frame" when it actually meant "PPDU". The start of the frame occurs 192 µs after the start of the PPDU or packet. 15.4e's value of 1120µs was an extra 100µs to compensate for the PHY components (which are really 192 µs). In summary, we could either continue to use the term frame with macTxRxOffset=1020µs, or use PPDU and add 192 µs.

- use of short addresses in nonce generation: 15.4e changed the nonce requirement of 15.4-2011, from requiring the use of the 8-octet extended address to allowing the usage of the short address (btw - all operations modes not just TSCH). It is generally understood that using the short address in the nonce generation is very problematic. Even if the short address is unique inside the PAN, there could be multiple PANs sharing the same keying material and using same short address for multiple devices. Using only the short address and not a combination of PANId and macShortAddress since it also puts another requirement, that short address needs to be unique over all PANs which use same key, not only unique inside the current PAN.

- TLV vs. LTV: The revision retains the IE formatting from 15.4e, it remains backward compatible.  The statement "the fact that such a change, with little to no practical value, would require continuous debate over many meetings is a sign that backward compatibility is not top of mind for a good part of the WG" is totally incorrect.  All standards organizations require that all individuals and organizations be heard, and they were in a thoughtful manner.

In summary, the changes done in the revision were to correct issues and problems.  The standardized TSCH IE IDs were not changed, rather a method was added to eliminate vendor conflicts in non-standardized IDs and the extra IDs were put back into reserve.  The macTxRxOffset was changed to be consistent with the correct terminology. While using the short address for nonce generation is not compliant to the revision, the group consensus was that it's not appropriate to knowingly degrade security, hence reverting back to the 802.15.4-2011 method.

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]<mailto:[email-masked]>

---

From: Rene Struik <[email-masked]>
Date: Wed, 01 Apr 2015 10:34:36 -0400

Hi Pascal:

My assessment was (and is) that it is imprudent to remove the "e" at 
this point in time. I never suggested that, *after* doing proper due 
diligence we could still move along that route.

Your message below seems more a branding exercise, which should be 
completely tangential to the question you asked to the 6TiSCH community 
on the mailing list.

All the goodies and rosy things on the horizon you sketched below may 
still materialize. The only point right now is that the "scrapping the e 
act" is premature.

BTW - MAC compatibility problems may very well impact IETF, in protocols 
whose design may make assumptions on MAC properties and on, e.g., 6top 
interfaces. If 6TiSCH would be indeed be completely independent of the 
underlying MAC ("MAC compatibility problems are an IEEE problem, not an 
IETF problem"), then why have all the 6TiSCH documents that have MAC 
language in them?

Best regards, Rene

On 4/1/2015 5:22 AM, Pascal Thubert (pthubert) wrote:
> But the point is, we are not working in silos like industrial 
> protocols, defining the whole stack from PHY to APP. We are defining 
> an IETF stack, which happens to be designed to apply above the TSCH 
> mode of in 802.15.4 that was introduced by 802.15.4e.
>
> Because we work on layers as opposed to silos, the 6TiSCH logo 
> guarantees interop at the IP layer, not at the MAC or PHY layers.
>
> E.g. IP (as defined over Ethernet) works on all Wi-Fi versions. But I 
> can hardly connect my old 802.11a card to any network these days. Sad 
> it is, but that is not an IETF problem.
>
> In the hypothetical case that IEEE802.15.4:2015 is not compatible with 
>  “802.15.4-2011 as amended by 802.15.4e-2012”, and that 6TiSCH, as 
> specified, works on both without a change, then we should still refer 
> to IEEE802.15.4.
>
> MAC compatibility problems are an IEEE problem, not an IETF problem; 
> there has also been a concern in this thread that the changes on 
> MAC/PHY require too much new work. All this is certainly unfortunate, 
> but it has to be resolved at the IEEE, not on this list.  We have an 
> Interest Group and may leverage it, but still this list is not the 
> right forum and the discussion is taking us way beyond the question I 
> asked to the group.
>
> And because silos are still needed to guarantee interoperability, 
> products that support 6TiSCH will have to bear some logo that indicate 
> what MAC/PHY they use, as well as which security models they support; 
> there will be multiple such logos that bind all that together and 
> guarantee some interoperability and functionality. IOW, it is up to an 
> adopting standard (a ZigbeeIP, an ISA, an IEC, a Thread or an HCF of 
> this world) to be more specific of the whole stack they build upon, 
> and the IETF does not need to have a say in that.
>
> René’s suggestion, “802.15.4-2011 as amended by 802.15.4e-2012”, would 
> for instance fail to include 802.15.4g. There are shipping products 
> that do TSCH over the sub-Gig in AMI/AMR and SmartGrid use cases, and 
> barring them from moving to 6TiSCH makes no sense. 6TiSCH is probably 
> a great solution for WiNAN. So I am strongly opposed to that limiting 
> wording. From the IEEE perspective, “IEEE802.15.4” **today** means 
> “802.15.4-2011 as amended by 802.15.4e-2012, 802.15.4f-2012, 
>  802.15.4g, 802.15.4j, 802.15.4k, 802.15.4m, and 802.15.4p". For all I 
> know that is **exactly** what we want.
>
> There has also been concerns that 6TiSCH RFCs may fail to work as 
> expected over some future version of 802.15.4. This may become true, 
> and this may be plain FUD. But yes, that is our problem. I’ll be 
> asking around if there is a best practice between IEEE and IETF for 
> such thing, above and beyond our particular case. My current research 
> indicates that we have been widely inconsistent so far. One suggestion 
> could be to place a note in the reference, as discussed in RFC4897 
> though for other purposes. This note could indicate that “this RFC 
> applies to the version of 802.15.4 that is current at the time of 
> publication of this RFC, and that it is expected but not guaranteed 
> that this RFC applies to 802.15.4 versions published after the 
> publication of this RFC”.
>
> So the updated action plan that I’m proposing to the group is as follows:
>
> - still, remove the ‘e’ in the charter; additionally:
>
> - work on a note for the reference to address the questions raised 
> about compatibility with future versions.
>
> - lookup for a best practice in that area (I’m taking that action item 
> but help is welcome)
>
> - task the IEEE 6TiSCH interest group to check whether the current 
> text impacts the 6TiSCH works as it stands (including drafts discussed 
> for re-chartering such as 6top and OTF)
>
> Does this make sense?
>
> Pascal
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Jonathan 
> Simon
> *Sent:* mardi 31 mars 2015 19:02
> *To:* Rene Struik; Kris Pister
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] removing the 'e'
>
> Chiming in…
>
> I agree with Rene, “802.15.4-2011 as amended by 802.15.4e-2012” is a 
> perfectly valid specification, and one that has formed the basis of a 
> number of products, including my company’s.
>
> I believe that Pat is trying to faithfully represent upcoming changes, 
> and that the primary goal of 802.15.4-2015 effort is to correct 
> mistakes and remove ambiguities that might result in different 
> implementations.  Yet there have been a few incompatible changes 
> introduced, perhaps for valid reasons - I would argue the short 
> address doesn’t leak info if only authenticating, and doesn’t prevent 
> the combination of EUI + ASN + Key from being replayed, so that more 
> moderate informative language could be used to solve this particular 
> problem.  I also think that policing IE’s is naive - the IEEE doesn’t 
> own the band, and a robust design uses security to ensure that frame 
> content is correct.
>
> 1) are the incompatible changes adding something that is needed for 
> 6TiSCH - if not, we are free in 6TiSCH to override behavior we don’t 
> like, e.g. “x is as described in spec y, except for the limitation of 
> clause z, which is taken from spec p, clause q”
>
> 2) do we need to see 802.15.4-2015 before adopting it as a normative 
> reference?  Paranoid me says yes, but if people agree to 1) then its 
> not really a problem.
>
> -- 
> Jonathan
>
>     Thanks Kris;
>
>     - IE IDs:  When 15.4e was introduced, we allowed vendors to freely
>     use 25 non-standardized IDs with the explicit warning that another
>     vendor could be using that ID creating a conflict, destroying
>     coexistence. Since that time we have seen a significant number of
>     requests for IE IDs, so given the limited number of IDs and the
>     fact that there really is no vendor coexistence with the original
>     scheme, we changed to one specific vendor ID where the vendor's
>     OUI is required to make the IE unique.
>
>     - macTsRxOffset: the basic intent of macTsRxOffset is to center
>     the transmission start within the range of 2200 µs (macTSRxWait).
>     So the transmitter's macTsTxOffset (2120µs) should be 1100µs
>     (macTsRxWait/2) greater than macTxRxOffset(1020µs).  However,
>     15.4e mistakenly used the term "frame" when it actually meant
>     "PPDU". The start of the frame occurs 192 µs after the start of
>     the PPDU or packet. 15.4e's value of 1120µs was an extra 100µs to
>     compensate for the PHY components (which are really 192 µs). In
>     summary, we could either continue to use the term frame with
>     macTxRxOffset=1020µs, or use PPDU and add 192 µs.
>
>     - use of short addresses in nonce generation: 15.4e changed the
>     nonce requirement of 15.4-2011, from requiring the use of the
>     8-octet extended address to allowing the usage of the short
>     address (btw - all operations modes not just TSCH). It is
>     generally understood that using the short address in the nonce
>     generation is very problematic. Even if the short address is
>     unique inside the PAN, there could be multiple PANs sharing the
>     same keying material and using same short address for multiple
>     devices. Using only the short address and not a combination of
>     PANId and macShortAddress since it also puts another requirement,
>     that short address needs to be unique over all PANs which use same
>     key, not only unique inside the current PAN.
>
>     - TLV vs. LTV: The revision retains the IE formatting from 15.4e,
>     it remains backward compatible.  The statement "the fact that such
>     a change, with little to no practical value, would require
>     continuous debate over many meetings is a sign that backward
>     compatibility is not top of mind for a good part of the WG" is
>     totally incorrect.  All standards organizations require that all
>     individuals and organizations be heard, and they were in a
>     thoughtful manner.
>
>     In summary, the changes done in the revision were to correct
>     issues and problems.  The standardized TSCH IE IDs were not
>     changed, rather a method was added to eliminate vendor conflicts
>     in non-standardized IDs and the extra IDs were put back into
>     reserve.  The macTxRxOffset was changed to be consistent with the
>     correct terminology. While using the short address for nonce
>     generation is not compliant to the revision, the group consensus
>     was that it's not appropriate to knowingly degrade security, hence
>     reverting back to the 802.15.4-2011 method.
>
>     Pat Kinney
>     Kinney Consulting LLC
>     [email-masked]
>     <mailto:[email-masked]>
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 16:53:15 +0000

Hello René

Removing the 'e' *today* is effectively transparent with regards 802.15.4e and 802.15.4-2011 because today that's what a reference to 802.15.4 means. How is that imprudent?

And no I do not see that what I'm saying in not precisely tangential. Can you explain yourself?

>From my standpoint, I have re-centered the discussion to my original question, and added clarifying questions/suggestions.

Original question:
- can we remove the 'e' in the charter
clarifying questions:
- suggestion to place in a note for the reference to address the questions raised about compatibility with future versions, asking wording.
- on best practice in IEEE references (this is being resolved at this very moment with the IEEE coordination and the RFC editor)
- and to the IEEE 6TiSCH interest group and whoever has access to the IEEE draft version: whether and how the current text impacts the 6TiSCH work as it stands.

What is tangential and digressive is references to MAC layer changes that do not affect L3 (or 6top). What goal is that serving?

And certainly, we will be interested in changes that would impact the 6top interface so we can add the required stuff to the data model.
If issues are identified, we can probably hold 6top interface till the IEEE document is ratified and published.

Cheers,

Pascal

From: Rene Struik [mailto:[email-masked]]
Sent: mercredi 1 avril 2015 16:35
To: Pascal Thubert (pthubert); Jonathan Simon
Cc: [email-masked]
Subject: Re: [6tisch] removing the 'e'

Hi Pascal:

My assessment was (and is) that it is imprudent to remove the "e" at this point in time. I never suggested that, *after* doing proper due diligence we could still move along that route.

Your message below seems more a branding exercise, which should be completely tangential to the question you asked to the 6TiSCH community on the mailing list.

All the goodies and rosy things on the horizon you sketched below may still materialize. The only point right now is that the "scrapping the e act" is premature.

BTW - MAC compatibility problems may very well impact IETF, in protocols whose design may make assumptions on MAC properties and on, e.g., 6top interfaces. If 6TiSCH would be indeed be completely independent of the underlying MAC ("MAC compatibility problems are an IEEE problem, not an IETF problem"), then why have all the 6TiSCH documents that have MAC language in them?

Best regards, Rene

Does this make sense?

Pascal

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

Chiming in...

--
Jonathan

Thanks Kris;

Pat Kinney
Kinney Consulting LLC

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Pat Kinney <[email-masked]>
Date: Wed, 1 Apr 2015 12:44:37 -0500

Pascal is correct in his opening statement, at the present the term "802.15.4" actually means: 

"802.15.4-2011 as amended by 802.15.4e-2012, 802.15.4f-2012, 802.15.4g, 802.15.4j, 802.15.4k, 802.15.4m, and 802.15.4p"

So dropping the use of 802.15.4e and using 802.15.4 does not change the charter of 6tisch (the other amendments add additional PHYs to the standard).  When the revision is approved, the term “802.15.4” will refer to “802.15.4-2015” assuming the approval is done this year.

As Tero has been pointing out to the 6tisch WG (and others to the 802.15 WG), the security in 802.15.4-2011 is broken, i.e. compliance to 802.15.4-2011 as amended by 802.15.4e-2012 ensures that the security will not properly function. For example, there was the issue with the short address alignment ambiguity for the TSCH, 802.15.4-2011 had problem with unsecured frames, as it did keydescriptor lookup and that failed for those unsecured keys (i.e. compliance with the procedure  in 7.2.3 results in rejecting unsecured frames).  The implementations to which I am aware work around these ambiguities in proprietary manners.

For the above issues and many others, I do not believe that “compliance" to 802.15.4-2011 as amended by 802.15.4e-2012 is critical.  

As I read these emails, I am lead to believe that most are concerned with the “compatibility” of code as per the revision with today’s code (K Pister described his concern that the revison will require a re-write of existing code).  To this point I must reply that existing code with vendor specific IEs could require code change since the revision requires vendor specific IEs to start off with the vendor’s OUI.  However, I note that the 6tisch effort to date does not describe the use of vendor specific IEs. To the point of the unsecured frame issue, if existing code repairs the problem in a similar fashion to the revision, no change should be required.  As to the issue of using the short address to construct the nonce, I am open to hearing arguments for and against this practice.

Once again, I must restate my request that all technical issues and concerns be specific and made to this ML.  This will allow us to address technical issues not fear, uncertainty, and doubt (FUD).

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

On 1, Apr2015, at 11:53, Pascal Thubert (pthubert) <[email-masked]> wrote:

Hello René
 
Removing the ‘e’ *today* is effectively transparent with regards 802.15.4e and 802.15.4-2011 because today that’s what a reference to 802.15.4 means. How is that imprudent?
 
And no I do not see that what I’m saying in not precisely tangential. Can you explain yourself?

Original question:
- can we remove the ‘e’ in the charter  
clarifying questions:
- suggestion to place in a note for the reference to address the questions raised about compatibility with future versions, asking wording.
- on best practice in IEEE references (this is being resolved at this very moment with the IEEE coordination and the RFC editor)
- and to the IEEE 6TiSCH interest group and whoever has access to the IEEE draft version: whether and how the current text impacts the 6TiSCH work as it stands.

 
Cheers,
 
Pascal

Hi Pascal:

Best regards, Rene  

 
Because we work on layers as opposed to silos, the 6TiSCH logo guarantees interop at the IP layer, not at the MAC or PHY layers.
E.g. IP (as defined over Ethernet) works on all Wi-Fi versions. But I can hardly connect my old 802.11a card to any network these days. Sad it is, but that is not an IETF problem.
In the hypothetical case that IEEE802.15.4:2015 is not compatible with  “802.15.4-2011 as amended by 802.15.4e-2012”, and that 6TiSCH, as specified, works on both without a change, then we should still refer to IEEE802.15.4.

 
René’s suggestion, “802.15.4-2011 as amended by 802.15.4e-2012”, would for instance fail to include 802.15.4g. There are shipping products that do TSCH over the sub-Gig in AMI/AMR and SmartGrid use cases, and barring them from moving to 6TiSCH makes no sense. 6TiSCH is probably a great solution for WiNAN. So I am strongly opposed to that limiting wording. From the IEEE perspective, “IEEE802.15.4” *today* means “802.15.4-2011 as amended by 802.15.4e-2012, 802.15.4f-2012,  802.15.4g, 802.15.4j, 802.15.4k, 802.15.4m, and 802.15.4p". For all I know that is *exactly* what we want.
 
There has also been concerns that 6TiSCH RFCs may fail to work as expected over some future version of 802.15.4. This may become true, and this may be plain FUD. But yes, that is our problem. I’ll be asking around if there is a best practice between IEEE and IETF for such thing, above and beyond our particular case. My current research indicates that we have been widely inconsistent so far. One suggestion could be to place a note in the reference, as discussed in RFC4897 though for other purposes. This note could indicate that “this RFC applies to the version of 802.15.4 that is current at the time of publication of this RFC, and that it is expected but not guaranteed that this RFC applies to 802.15.4 versions published after the publication of this RFC”.
 
- lookup for a best practice in that area (I’m taking that action item but help is welcome)
 
Does this make sense?
 
Pascal
 
From: 6tisch [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Jonathan Simon
Sent: mardi 31 mars 2015 19:02
To: Rene Struik; Kris Pister
Cc: [email-masked] <mailto:[email-masked]>
Subject: Re: [6tisch] removing the 'e'
 
Chiming in…
 
I agree with Rene, “802.15.4-2011 as amended by 802.15.4e-2012” is a perfectly valid specification, and one that has formed the basis of a number of products, including my company’s.
 
I believe that Pat is trying to faithfully represent upcoming changes, and that the primary goal of 802.15.4-2015 effort is to correct mistakes and remove ambiguities that might result in different implementations.  Yet there have been a few incompatible changes introduced, perhaps for valid reasons - I would argue the short address doesn’t leak info if only authenticating, and doesn’t prevent the combination of EUI + ASN + Key from being replayed, so that more moderate informative language could be used to solve this particular problem.  I also think that policing IE’s is naive - the IEEE doesn’t own the band, and a robust design uses security to ensure that frame content is correct. 

1) are the incompatible changes adding something that is needed for 6TiSCH - if not, we are free in 6TiSCH to override behavior we don’t like, e.g. “x is as described in spec y, except for the limitation of clause z, which is taken from spec p, clause q”
2) do we need to see 802.15.4-2015 before adopting it as a normative reference?  Paranoid me says yes, but if people agree to 1) then its not really a problem.
 
-- 
Jonathan 
 
Thanks Kris;

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

-- 
email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Rene Struik <[email-masked]>
Date: Wed, 01 Apr 2015 14:06:53 -0400

Hi Pat:

The "discussion" so far on this list regarding this topic make me wonder 
whether the conclusion is warranted that the 6TiSCH liaison may have not 
worked as well as, perhaps, it should have.

Best regards, Rene

On 4/1/2015 1:44 PM, Pat Kinney wrote:
> "802.15.4-2011 as amended by 802.15.4e-2012, 802.15.4f-2012, 
> 802.15.4g, 802.15.4j, 802.15.4k, 802.15.4m, and 802.15.4p"
>
> So dropping the use of 802.15.4e and using 802.15.4 does not change 
> the charter of 6tisch (the other amendments add additional PHYs to the 
> standard).  When the revision is approved, the term “802.15.4” will 
> refer to “802.15.4-2015” assuming the approval is done this year.
>
> As Tero has been pointing out to the 6tisch WG (and others to the 
> 802.15 WG), the security in 802.15.4-2011 is broken, i.e. compliance 
> to 802.15.4-2011 as amended by 802.15.4e-2012 ensures that the 
> security will not properly function. For example, there was the issue 
> with the short address alignment ambiguity for the TSCH, 802.15.4-2011 
> had problem with unsecured frames, as it did keydescriptor lookup and 
> that failed for those unsecured keys (i.e. compliance with the 
> procedure  in 7.2.3 results in rejecting unsecured frames). The 
> implementations to which I am aware work around these ambiguities in 
> proprietary manners.
>
> For the above issues and many others, I do not believe 
> that “compliance" to 802.15.4-2011 as amended by 802.15.4e-2012 is 
> critical.
>
> As I read these emails, I am lead to believe that most are concerned 
> with the “compatibility” of code as per the revision with today’s code 
> (K Pister described his concern that the revison will require a 
> re-write of existing code).  To this point I must reply that existing 
> code with vendor specific IEs could require code change since the 
> revision requires vendor specific IEs to start off with the vendor’s 
> OUI.  However, I note that the 6tisch effort to date does not describe 
> the use of vendor specific IEs. To the point of the unsecured frame 
> issue, if existing code repairs the problem in a similar fashion to 
> the revision, no change should be required.  As to the issue of using 
> the short address to construct the nonce, I am open to hearing 
> arguments for and against this practice.
>
> Once again, I must restate my request that all technical issues and 
> concerns be specific and made to this ML.  This will allow us to 
> address technical issues not fear, uncertainty, and doubt (FUD).
>
> Pat Kinney
> */Kinney Consulting LLC/*
> On 1, Apr2015, at 11:53, Pascal Thubert (pthubert) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hello René
>
> Removing the ‘e’ **today** is effectively transparent with regards 
> 802.15.4e and 802.15.4-2011 because today that’s what a reference to 
> 802.15.4 means. How is that imprudent?
>
> From my standpoint, I have re-centered the discussion to my original 
> question, and added clarifying questions/suggestions.
>
> Original question:
>
> - suggestion to place in a note for the reference to address the 
> questions raised about compatibility with future versions, asking wording.
>
> - on best practice in IEEE references (this is being resolved at this 
> very moment with the IEEE coordination and the RFC editor)
>
> - and to the IEEE 6TiSCH interest group and whoever has access to the 
> IEEE draft version: whether and how the current text impacts the 
> 6TiSCH work as it stands.
>
> What is tangential and digressive is references to MAC layer changes 
> that do not affect L3 (or 6top). What goal is that serving?
>
> And certainly, we will be interested in changes that would impact the 
> 6top interface so we can add the required stuff to the data model.
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* mercredi 1 avril 2015 16:35
> *To:* Pascal Thubert (pthubert); Jonathan Simon
> *Cc:* [email-masked] <mailto:[email-masked]>
> completely tangential to the question you asked to the 6TiSCH 
> community on the mailing list.
>
> still materialize. The only point right now is that the "scrapping the 
> e act" is premature.
>
> BTW - MAC compatibility problems may very well impact IETF, in 
> protocols whose design may make assumptions on MAC properties and on, 
> e.g., 6top interfaces. If 6TiSCH would be indeed be completely 
> independent of the underlying MAC ("MAC compatibility problems are an 
> IEEE problem, not an IETF problem"), then why have all the 6TiSCH 
> documents that have MAC language in them?
>
> Best regards, Rene
>
>     protocols, defining the whole stack from PHY to APP. We are
>     defining an IETF stack, which happens to be designed to apply
>     above the TSCH mode of in 802.15.4 that was introduced by 802.15.4e.
>
>     E.g. IP (as defined over Ethernet) works on all Wi-Fi versions.
>     But I can hardly connect my old 802.11a card to any network these
>     days. Sad it is, but that is not an IETF problem.
>
>     In the hypothetical case that IEEE802.15.4:2015 is not compatible
>     with  “802.15.4-2011 as amended by 802.15.4e-2012”, and that
>     6TiSCH, as specified, works on both without a change, then we
>     should still refer to IEEE802.15.4.
>
>     MAC compatibility problems are an IEEE problem, not an IETF
>     problem; there has also been a concern in this thread that the
>     changes on MAC/PHY require too much new work. All this is
>     certainly unfortunate, but it has to be resolved at the IEEE, not
>     on this list.  We have an Interest Group and may leverage it, but
>     still this list is not the right forum and the discussion is
>     taking us way beyond the question I asked to the group.
>
>     products that support 6TiSCH will have to bear some logo that
>     indicate what MAC/PHY they use, as well as which security models
>     they support; there will be multiple such logos that bind all that
>     together and guarantee some interoperability and functionality.
>     IOW, it is up to an adopting standard (a ZigbeeIP, an ISA, an IEC,
>     a Thread or an HCF of this world) to be more specific of the whole
>     stack they build upon, and the IETF does not need to have a say in
>     that.
>
>     René’s suggestion, “802.15.4-2011 as amended by 802.15.4e-2012”,
>     would for instance fail to include 802.15.4g. There are shipping
>     products that do TSCH over the sub-Gig in AMI/AMR and SmartGrid
>     use cases, and barring them from moving to 6TiSCH makes no sense.
>     6TiSCH is probably a great solution for WiNAN. So I am strongly
>     opposed to that limiting wording. From the IEEE perspective,
>     “IEEE802.15.4” **today** means “802.15.4-2011 as amended by
>     802.15.4e-2012, 802.15.4f-2012,  802.15.4g, 802.15.4j, 802.15.4k,
>     802.15.4m, and 802.15.4p". For all I know that is **exactly** what
>     we want.
>
>     expected over some future version of 802.15.4. This may become
>     true, and this may be plain FUD. But yes, that is our problem.
>     I’ll be asking around if there is a best practice between IEEE and
>     IETF for such thing, above and beyond our particular case. My
>     current research indicates that we have been widely inconsistent
>     so far. One suggestion could be to place a note in the reference,
>     as discussed in RFC4897 though for other purposes. This note could
>     indicate that “this RFC applies to the version of 802.15.4 that is
>     current at the time of publication of this RFC, and that it is
>     expected but not guaranteed that this RFC applies to 802.15.4
>     versions published after the publication of this RFC”.
>
>     text impacts the 6TiSCH works as it stands (including drafts
>     discussed for re-chartering such as 6top and OTF)
>
>     Does this make sense?
>
>     Pascal
>
>     *From:*6tisch [mailto:[email-masked]] *On Behalf Of
>     *Jonathan Simon
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     I agree with Rene, “802.15.4-2011 as amended by 802.15.4e-2012” is
>     a perfectly valid specification, and one that has formed the basis
>     of a number of products, including my company’s.
>
>     I believe that Pat is trying to faithfully represent upcoming
>     changes, and that the primary goal of 802.15.4-2015 effort is to
>     correct mistakes and remove ambiguities that might result in
>     different implementations.  Yet there have been a few incompatible
>     changes introduced, perhaps for valid reasons - I would argue the
>     short address doesn’t leak info if only authenticating, and
>     doesn’t prevent the combination of EUI + ASN + Key from being
>     replayed, so that more moderate informative language could be used
>     to solve this particular problem.  I also think that policing IE’s
>     is naive - the IEEE doesn’t own the band, and a robust design uses
>     security to ensure that frame content is correct.
>
>     1) are the incompatible changes adding something that is needed
>     for 6TiSCH - if not, we are free in 6TiSCH to override behavior we
>     don’t like, e.g. “x is as described in spec y, except for the
>     limitation of clause z, which is taken from spec p, clause q”
>
>     2) do we need to see 802.15.4-2015 before adopting it as a
>     normative reference?  Paranoid me says yes, but if people agree to
>     1) then its not really a problem.
>
>     -- 
>     Jonathan
>
>         Thanks Kris;
>
>         - IE IDs:  When 15.4e was introduced, we allowed vendors to
>         freely use 25 non-standardized IDs with the explicit warning
>         that another vendor could be using that ID creating a
>         conflict, destroying coexistence. Since that time we have seen
>         a significant number of requests for IE IDs, so given the
>         limited number of IDs and the fact that there really is no
>         vendor coexistence with the original scheme, we changed to one
>         specific vendor ID where the vendor's OUI is required to make
>         the IE unique.
>
>         - macTsRxOffset: the basic intent of macTsRxOffset is to
>         center the transmission start within the range of 2200 µs
>         (macTSRxWait). So the transmitter's macTsTxOffset (2120µs)
>         should be 1100µs (macTsRxWait/2) greater than
>         macTxRxOffset(1020µs).  However, 15.4e mistakenly used the
>         term "frame" when it actually meant "PPDU". The start of the
>         frame occurs 192 µs after the start of the PPDU or packet.
>         15.4e's value of 1120µs was an extra 100µs to compensate for
>         the PHY components (which are really 192 µs). In summary, we
>         could either continue to use the term frame with
>         - use of short addresses in nonce generation: 15.4e changed
>         the nonce requirement of 15.4-2011, from requiring the use of
>         the 8-octet extended address to allowing the usage of the
>         short address (btw - all operations modes not just TSCH). It
>         is generally understood that using the short address in the
>         nonce generation is very problematic. Even if the short
>         address is unique inside the PAN, there could be multiple PANs
>         sharing the same keying material and using same short address
>         for multiple devices. Using only the short address and not a
>         combination of PANId and macShortAddress since it also puts
>         another requirement, that short address needs to be unique
>         over all PANs which use same key, not only unique inside the
>         current PAN.
>
>         - TLV vs. LTV: The revision retains the IE formatting from
>         15.4e, it remains backward compatible.  The statement "the
>         fact that such a change, with little to no practical value,
>         would require continuous debate over many meetings is a sign
>         that backward compatibility is not top of mind for a good part
>         of the WG" is totally incorrect.  All standards organizations
>         require that all individuals and organizations be heard, and
>         they were in a thoughtful manner.
>
>         changed, rather a method was added to eliminate vendor
>         conflicts in non-standardized IDs and the extra IDs were put
>         back into reserve.  The macTxRxOffset was changed to be
>         consistent with the correct terminology. While using the short
>         address for nonce generation is not compliant to the revision,
>         the group consensus was that it's not appropriate to knowingly
>         degrade security, hence reverting back to the 802.15.4-2011
>         method.
>
>         Pat Kinney
>         Kinney Consulting LLC
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
> [email-masked] <mailto:[email-masked]>

---

From: Pat Kinney <[email-masked]>
Date: Wed, 1 Apr 2015 13:30:23 -0500

Rene;

A liaison is a multi-party effort, it will not work as well if there isn’t full participation from all involved parties.  While I have tried to keep the 6tisch WG informed as to the revision status and changes to the standard, I am restrained by the IEEE-SA from releasing the draft to the public (IEC has similar rules).  Time and time again, I have advised all interested parties that they can join the 802.15 SCm reflector, that they can participate in the conference calls, and that they are welcome to come to any of the meetings per year.  Beyond this effort, I cannot understand what else I can do as chair of the IEEE 6tisch IG.

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>
On 1, Apr2015, at 13:06, Rene Struik <[email-masked]> wrote:

Hi Pat:

The "discussion" so far on this list regarding this topic make me wonder whether the conclusion is warranted that the 6TiSCH liaison may have not worked as well as, perhaps, it should have.

Best regards, Rene

On 4/1/2015 1:44 PM, Pat Kinney wrote:
> On 1, Apr2015, at 11:53, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello René
>  
> From: Rene Struik [mailto:[email-masked] <mailto:[email-masked]>] 
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>