Re: [6tisch] removing the 'e'

[Rene Struik <[e-mail]>]

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:
>
> 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:[e-mail]] *On Behalf Of *Jonathan 
> Simon
> *Sent:* mardi 31 mars 2015 19:02
> *To:* Rene Struik; Kris Pister
> *Cc:* [e-mail]
> *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
>     [e-mail]
>     <mailto:[e-mail]>
>


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]