Subject: [6tisch] removing the 'e'

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Mar 2015 15:23:59 +0000

Dear all:

Pat presented at the WG on Thursday his recommendation to remove the 'e' after IEEE802.15.4 in our current charter and WG Documents (slides at the end of http://www.ietf.org/proceedings/92/slides/slides-92-6tisch-2.pdf ).

The net effect would be that when a new version of the standard is published - 2015 should be available soon -, our normative references will implicitly pick that latest version and inherit the fixes that were made since then, as well as the additional PHYs on which 802.15.4 TSCH can operate.

Pat indicated that this procedure is the expected one when referring to IEEE documents. Subir noted that at the IETF we normally have reference on particular versions, and a change in an RFC is a new RFC thus a new reference, and the IEEE form of reference may create an issue with IETF practice. The chairs will need to validate this before proceeding.

On the question whether the change is desirable, Pat made the case that 15.4e is just an amendment, which is an incomplete reference, and that it yields some incorrectness that is now fixed in the upcoming 2015 version of 802.15.4. 
All in all the group agreed that the change is desirable. We are now coming to the list to confirm the consensus. If you have an issue with removing the 'e' please speak up now.

Cheers,

Pascal and Thomas

---

From: Kris Pister <[email-masked]>
Date: Mon, 30 Mar 2015 10:12:00 -0700

I like the IETF approach better, but I don't think that we have much choice.
If the roll-up from 15.4e to  15.4-2015 were just corrections of real 
problems
it would be a no-brainer.
Unfortunately, there are numerous cases where IEEE members with "good ideas"
have pushed for changes that have little or no practical value, but do 
require a
re-write of existing code, and mandate non-interoperability between the 
existing
15.4e and the forthcoming 15.4-2015.

ksjp

On 3/30/2015 8:23 AM, Pascal Thubert (pthubert) wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Rene Struik <[email-masked]>
Date: Mon, 30 Mar 2015 14:22:15 -0400

Hi Pascal:

I think the proper approach is that one investigates whether an updated 
version of a cross-referenced specification is suitable and, if so, one 
can adopt this.

To me, it is not a given that the revision effort of 802.15.4 that is 
currently on its way will automatically satisfy requirements 6TiSCH has. 
I am wondering how we would know, since so far technical changes have 
never been discussed/socialized within 6TiSCH itself (see also 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02853.html). 
Anecdotal evidence regarding extensive changes makes me somewhat 
pessimistic here.

We should use a "trust but verify" approach here. Anything else would be 
imprudent. I think this more or less reiterates Subir Das's point.

So, I am not in favor of implicit, blind trust; only in favor of 
explicit, verified trust. Unfortunately, this means I think the 
recommendation you put forward below is imprudent.

As a final note:
a) not sure why the 802.15.4e amendment would be incomplete. This seems 
to be in direct conflict with the note on page 1 of the 802.15.4e-2012 
standard (NOTE—The editing instructions contained in this amendment 
define how to merge the material contained therein into the existing 
base standard and its amendments to form the comprehensive standard).
b) Not sure how one can already predict now when the current revision 
work will be end and result in a revised standard. Assuming that this 
will be in 2015 (with sponsor ballot not having started yet) seems 
somewhat premature.

Rene

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

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 30 Mar 2015 18:26:35 +0000

If Kris is correct, and compliance with the 15.4 rollup would cause code changes to existing 4e code, then I don't think it's a good idea to remove the 'e' -- if existing 4e code would be interoperable with 15.4 rollup, then I guess referencing the rollup (for posterity) would be a good idea.

Randy

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: Monday, March 30, 2015 1:12 PM
To: [email-masked]
Subject: Re: [6tisch] removing the 'e'

I like the IETF approach better, but I don't think that we have much choice.
If the roll-up from 15.4e to  15.4-2015 were just corrections of real problems it would be a no-brainer.
Unfortunately, there are numerous cases where IEEE members with "good ideas"
have pushed for changes that have little or no practical value, but do require a re-write of existing code, and mandate non-interoperability between the existing 15.4e and the forthcoming 15.4-2015.

ksjp

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Pat Kinney <[email-masked]>
Date: Mon, 30 Mar 2015 14:06:36 -0500

I disagree with both Kris' and Rene's objections.

Addressing Kris' objections first:
- If the roll-up from 15.4e to  15.4-2015 were just corrections of real problems it would be a no-brainer.
<PK> the element here is "just corrections", indeed there are corrections, but many non-TSCH and security corrections have been made as well
- Unfortunately, there are numerous cases where IEEE members with "good ideas" have pushed for changes that have little or no practical value, but do require a re-write of existing code, and mandate non-interoperability between the existing 15.4e and the forthcoming 15.4-2015.
<PK> '"good ideas" with little or no practical value' is a personal opinion, to which I disagree whole heartedly.'Requiring a rewrite of existing code and mandating non-interoperability between existing 15.4e and forthcoming 15.4-2015' is unfounded, the changes we have implemented have been critiqued for backward compatibility, I am not aware of any change that would make the two versions of devices non-interoperable. I ask that Kris quantify his statement with evidence.

Addressing Rene's objections:
- To me, it is not a given that the revision effort of 802.15.4 that is currently on its way will automatically satisfy requirements 6TiSCH has. 
<PK> to what TSCH requirements does Rene refer? I ask that Rene to not critique without giving evidence
- I am wondering how we would know, since so far technical changes have never been discussed/socialized within 6TiSCH itself (see also http://www.ietf.org/mail-archive/web/6tisch/current/msg02853.html). Anecdotal evidence regarding extensive changes makes me somewhat pessimistic here.
<PK> the url provided by Rene merely restates his objections in the past, they absolutely have no evidence supporting them, e.g. "this does not necessarily mean they can speak for 6tisch's interests, at least not without consensus." I ask Rene again, what 6tisch interests with a consensus have been ignored or disregarded? Please stop referring to past innuendos but instead let's discuss specific technical questions
- So, I am not in favor of implicit, blind trust; only in favor of explicit, verified trust. Unfortunately, this means I think the recommendation you put forward below is imprudent.
<PK> I addressed the aspect of "the explicit verified trust" at the meeting in Dallas, the latest draft revision will be made publicly available at the start of the Sponsor Ballot which could start as early as 8 April 2015. Until then, I ask that anyone in the 6tisch group to address specific questions to this ML to which I can specifically reply.

Pat

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

On 30, Mar2015, at 13:22, Rene Struik <[email-masked]> wrote:

Hi Pascal:

I think the proper approach is that one investigates whether an updated version of a cross-referenced specification is suitable and, if so, one can adopt this.

To me, it is not a given that the revision effort of 802.15.4 that is currently on its way will automatically satisfy requirements 6TiSCH has. I am wondering how we would know, since so far technical changes have never been discussed/socialized within 6TiSCH itself (see also http://www.ietf.org/mail-archive/web/6tisch/current/msg02853.html). Anecdotal evidence regarding extensive changes makes me somewhat pessimistic here.

We should use a "trust but verify" approach here. Anything else would be imprudent. I think this more or less reiterates Subir Das's point.

So, I am not in favor of implicit, blind trust; only in favor of explicit, verified trust. Unfortunately, this means I think the recommendation you put forward below is imprudent.

As a final note:
a) not sure why the 802.15.4e amendment would be incomplete. This seems to be in direct conflict with the note on page 1 of the 802.15.4e-2012 standard (NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into the existing base standard and its amendments to form the comprehensive standard).
b) Not sure how one can already predict now when the current revision work will be end and result in a revised standard. Assuming that this will be in 2015 (with sponsor ballot not having started yet) seems somewhat premature.

Rene

---

From: Rene Struik <[email-masked]>
Date: Mon, 30 Mar 2015 15:53:30 -0400

Hi Pat:

I do not understand how one could possibly object against any suggestion 
that using blind, unverified trust (aka "blank cheque") as yardstick is 
imprudent: this should be self-evident.

In fact, my simple suggestion that 6TiSCH do its own due diligence as to 
whether a specific specification should be preferred as baseline is not 
unlike what is suggested in the reference sections of most IEEE 
documents (where one either cross-references dated or undated specs). I

Ironically, I was told that the latest 802.15.4 Revision draft (the one 
you had some slides on during IETF-92) does the same... (see below)

[802.15.4-2006, Section 2 - Normative References]
The following referenced documents are indispensable for the application 
of this document. For dated references, only the edition cited applies. 
For undated references, the latest edition of the referenced document 
(including any amendments or corrigenda) applies.

[draft 802.15.4 REVc - DF4]
The following referenced documents are indispensable for the application 
of this document (i.e., they must be understood and used, so each 
referenced document is cited in text and its relationship to this 
document is explained). For dated references, only the edition cited 
applies. For undated references, the latest edition of the referenced 
document (including any amendments or corrigenda) applies.

Best regards, Rene

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 30 Mar 2015 21:44:48 -0400

I will try to add me opinion here.

I am strongly in favor, that at this point to change the reference to 
IEEE 802.15.4-2015 for IEEE 802.15.4-2011 plus 802.15.4e.

I am ASSuMEing that you are referencing 802.15.4-2011 and not -2006?  
What is incomplete about 15.4e, is that you need to reference 15.4-2011.

But when we were plowing through the security portion of 15.4-2011 to 
work out what 802.15.9 would be 'controlling', we learned many vendors 
were still implementing the -2006 security, not the -2011, which was 
considered more broken that the -2006.  Most noteably the 15.4g vendors 
were making these statements.

So what went on at the 802.15.4 maintenance sessions?  'Oh, that is 
REALLY broken.  How did we miss that?'  A lot of attention was given to 
not breaking deployed code, but in a few places, broken things needed to 
be fixed.  Tero (and I to some extent) really worked over the security 
section.  Rekeying a PAN really did not work with the way the frame 
counter was described, for example.  We had to move some fields around 
in the security tables.

Review?  Well get on the sponsor ballot, if you still can.  Changes for 
the sake of changing or for a particular vendor's 'needs'?  I did not 
see that happening.  But I am NOT the expert on most of the features, 
and someone could easily slip that by me.

Restructuring, a little bit, the Information Elements to allow for SDO 
requests; most vocal being ETSI.

I strongly recommend moving forward with referencing 802.15.4-2015.

---

From: Kris Pister <[email-masked]>
Date: Mon, 30 Mar 2015 19:59:49 -0700

Pat - I'm going by what you presented at IETF91 a few months ago:
http://www.ietf.org/proceedings/91/slides/slides-91-6tisch-8.pdf
* IE regions are moving.  0x00-0x19 were unmanaged, now 0x01-0x18 are 
reserved
* macTsRxOffset change from 1120 to 1020us
* not allowed to use short addresses in nonce generation
Smart people are making arguments on both sides of these issues.  I 
would argue
that this means that these are not corrections, they are changes to an 
existing
standard without clear technical consensus.  The short address change is 
absolutely
a backward compatibility killer.

In addition, we had a long fight over changing IE format from {Length, 
Type, Value}
to {Type, Length, Value}.  The last I heard we lost that battle. That is 
absolutely a
backward compatibility killer.  Perhaps that one did finally get 
resolved in favor
of 4e, but 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.  That's a real concern.

ksjp

---

From: Pat Kinney <[email-masked]>
Date: Tue, 31 Mar 2015 01:19:43 -0500

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

On 30, Mar2015, at 21:59, Kris Pister <[email-masked]> wrote:

Pat - I'm going by what you presented at IETF91 a few months ago:
http://www.ietf.org/proceedings/91/slides/slides-91-6tisch-8.pdf
* IE regions are moving.  0x00-0x19 were unmanaged, now 0x01-0x18 are reserved
* macTsRxOffset change from 1120 to 1020us
* not allowed to use short addresses in nonce generation
Smart people are making arguments on both sides of these issues.  I would argue
that this means that these are not corrections, they are changes to an existing
standard without clear technical consensus.  The short address change is absolutely
a backward compatibility killer.

In addition, we had a long fight over changing IE format from {Length, Type, Value}
to {Type, Length, Value}.  The last I heard we lost that battle. That is absolutely a
backward compatibility killer.  Perhaps that one did finally get resolved in favor
of 4e, but 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.  That's a real concern.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Mar 2015 06:49:19 +0000

Hello Randy:

I do agree that Kris is right, but probably not on the same point as you do here.  6TiSCH does not have much choice. We do not own 802.15.4, we reference it.
And the question of backward compatibility does not really affect 6TiSCH since 6TiSCH never shipped before, and there certainly will be quite a development effort to build a 6TiSCH product anyway.

6TiSCH cannot be locked referencing an interim specification, so there is no question in my mind that 6TiSCH will ultimately refer to the new standard when it ships. What we're after is the minimum hassle on that path.

The question that was asked to the group is about the current charter, and the current WG docs that we are shipping to IESG, in particular minimal.
If we keep referencing 15.4e, we will be creating a backward compatibility issue with ourselves, and that's probably not a good idea. I'm looking for a consensus to avoid that.

Another aspect of that question is the plug test in Prague. Considering the time frame, it will be difficult for the implementations to migrate to 802.15.4-2015, and there may be interop problems at the MAC layer.
What should we be shooting for?

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of Turner, Randy
> Sent: lundi 30 mars 2015 20:27
> To: Kris Pister; [email-masked]
> If Kris is correct, and compliance with the 15.4 rollup would cause code changes
> to existing 4e code, then I don't think it's a good idea to remove the 'e' -- if
> existing 4e code would be interoperable with 15.4 rollup, then I guess
> referencing the rollup (for posterity) would be a good idea.
> 
> Randy
> 
> have pushed for changes that have little or no practical value, but do require a
> existing 15.4e and the forthcoming 15.4-2015.
> 
> ksjp
> 
> > Pat presented at the WG on Thursday his recommendation to remove the 'e'
> after IEEE802.15.4 in our current charter and WG Documents (slides at the end
> of http://www.ietf.org/proceedings/92/slides/slides-92-6tisch-2.pdf ).
> >
> > The net effect would be that when a new version of the standard is published -
> 2015 should be available soon -, our normative references will implicitly pick
> that latest version and inherit the fixes that were made since then, as well as the
> additional PHYs on which 802.15.4 TSCH can operate.
> >
> > Pat indicated that this procedure is the expected one when referring to IEEE
> documents. Subir noted that at the IETF we normally have reference on
> particular versions, and a change in an RFC is a new RFC thus a new reference,
> and the IEEE form of reference may create an issue with IETF practice. The
> chairs will need to validate this before proceeding.
> >
> > On the question whether the change is desirable, Pat made the case that 15.4e
> is just an amendment, which is an incomplete reference, and that it yields some
> incorrectness that is now fixed in the upcoming 2015 version of 802.15.4.
> > All in all the group agreed that the change is desirable. We are now coming to
> the list to confirm the consensus. If you have an issue with removing the 'e'
> please speak up now.
> >
> > Cheers,
> >
> > Pascal and Thomas
> >
> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized representative
> of an intended recipient, you are prohibited from using, copying or distributing
> the information in this e-mail or its attachments. If you have received this e-mail
> in error, please notify the sender immediately by return e-mail and delete all
> copies of this message and any attachments. Thank you.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Mar 2015 07:07:19 +0000

Hello René:

So far, 6TiSCH has not expressed requirements on TSCH. We have taken it as a base and built upon it. So I can hardly relate your words to something specific. 

- The base that we have considered for the architecture is very abstract since we had a goal to design beyond 802.15.4 whenever possible. From Pat's presentation, I have trouble believing that this text is affected at all, but then I'm interested in any specific point, and it is still time to fix Archie's text.

- For the more specific draft, a good suggestion could be to ask the Interest Group to review the minimal and 6top interface drafts and assert whether and how they are affected by the change to 802.15.4-2015, so as to promote an action either on the IEEE or on the IETF side. I gathered from Pat that they are not, but a formal review from the I-G could help close that discussion.

Pat, do you think that can be done?

Pascal

> From: Rene Struik [mailto:[email-masked]]
> Sent: lundi 30 mars 2015 20:22
> To: Pascal Thubert (pthubert); [email-masked]
> I think the proper approach is that one investigates whether an updated version
> of a cross-referenced specification is suitable and, if so, one can adopt this.
> 
> To me, it is not a given that the revision effort of 802.15.4 that is currently on its
> way will automatically satisfy requirements 6TiSCH has.
> I am wondering how we would know, since so far technical changes have never
> been discussed/socialized within 6TiSCH itself (see also
> So, I am not in favor of implicit, blind trust; only in favor of explicit, verified
> trust. Unfortunately, this means I think the recommendation you put forward
> below is imprudent.
> 
> As a final note:
> a) not sure why the 802.15.4e amendment would be incomplete. This seems to
> be in direct conflict with the note on page 1 of the 802.15.4e-2012 standard
> (NOTE-The editing instructions contained in this amendment define how to
> merge the material contained therein into the existing base standard and its
> amendments to form the comprehensive standard).
> b) Not sure how one can already predict now when the current revision work will
> be end and result in a revised standard. Assuming that this will be in 2015 (with
> sponsor ballot not having started yet) seems somewhat premature.
> 
> Rene
>

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 31 Mar 2015 07:30:06 +0000

Hi Pascal,

I agree with you in principal about the timing of 6tisch completion and
the availability of the final 802.15.4 rollup - I think they will be timed
pretty close so it would be nice to reference the rollup.

If by ³interim² you mean ³amendment², I believe there are quite a few stds
that refer to amendments with regards to requirements - 6tisch never
shipped before but there¹s quite a bit of code already written to 4e, not
only functional code, but diagnostic (sniffer) code as well, so if there
are changes required for the rollup, it would be unfortunate.

Ultimately I think we¹re bound by our charter, not any philosophical
thinking that we would ³like² to exist that says we do this or that -
philosophically I think it makes sense to refer to the rollup - it just
seems like the thing to do. However, we¹re bound by the charter that says
³The working group will focus on enabling IPv6 over the TSCH mode of
802.15.4e standard².

I would like to be able to refer to 2015 802.15.4 but frankly the news
about it being different than 4e (with regards to TSCH) surprised me.

Could someone elaborate on the deltas between 4e and 2015-802.15.4 for
TSCH ?

I guess our AD could ³green light² the reference either way, and like I
said, it would be nice to refer to the rollup ³for posterity²; meaning,
for future developers it would be nice if they could work with the more
current spec - I¹m in favor of the rollup if the differences I am hearing
about between 4e and the rollup are minimal.  If the changes are
significant, then from an IETF procedural standpoint, I think we would
need a ruling.

Randy

On 3/31/15, 2:49 AM, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

>Hello Randy:
>
>I do agree that Kris is right, but probably not on the same point as you
>do here.  6TiSCH does not have much choice. We do not own 802.15.4, we
>reference it.
>And the question of backward compatibility does not really affect 6TiSCH
>since 6TiSCH never shipped before, and there certainly will be quite a
>development effort to build a 6TiSCH product anyway.
>
>6TiSCH cannot be locked referencing an interim specification, so there is
>no question in my mind that 6TiSCH will ultimately refer to the new
>standard when it ships. What we're after is the minimum hassle on that
>path.
>
>The question that was asked to the group is about the current charter,
>and the current WG docs that we are shipping to IESG, in particular
>minimal.
>If we keep referencing 15.4e, we will be creating a backward
>compatibility issue with ourselves, and that's probably not a good idea.
>I'm looking for a consensus to avoid that.
>
>Another aspect of that question is the plug test in Prague. Considering
>the time frame, it will be difficult for the implementations to migrate
>to 802.15.4-2015, and there may be interop problems at the MAC layer.
>>problems it
>> would be a no-brainer.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 31 Mar 2015 10:57:17 +0100

Hi Pat,

I agree with Rene that there is anecdotal evidence of extensive changes 
made when they were really unnecessary. This occurred in 802.15.4-2011. 
I also share Kris' concerns that there will be "changes that have little 
or not but do require a re-write of existing code, and mandate 
non-interoperability between the existing 15.4e and the forthcoming 
15.4-2015".

I would hope the wrap-up is comprised solely of 802.15.4-2011 plus the 
amendments and that there is no wholesale "tweaking" of the text in the 
misguided view of a handful of individuals that there is something amiss 
with the current text that needs to be changed.

Robert

---

From: Rene Struik <[email-masked]>
Date: Tue, 31 Mar 2015 09:52:09 -0400

Hi Pascal:

The 802.15.4rev draft is, as the wording suggests, a *draft* 
specification. One should not give the impression as if this would be a 
stable draft, let alone a specification cast in stone. Thus, referencing 
to this as "802.15.4-2015" puts people on the wrong footing. Moreover, 
already anticipating that this draft reaches the end station in 2015, 
even prior to start of sponsor ballot, casts some doubt as to how 
receptive one would be to consider comments received during sponsor ballot.

My only comment right now is that, in its current form, removing the "e" 
is premature. This may change over time, but one should not let 802.15 
folks be the arbiter of this, but users of this specification, including 
6TiSCH.

BTW - ZigBee mostly uses the 802.15.4-2006 specification and most 
6lowpan documents also refer to that specification.

Best regards, Rene

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Tue, 31 Mar 2015 14:18:23 +0000

Is there any middle ground?
Could there be a  reference 802.15.4e, noting it is a draft which is to be finalized and included in the 802.15.4-2015 standard?

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Tuesday, March 31, 2015 9:52 AM
To: Pascal Thubert (pthubert); [email-masked]; Pat Kinney
Subject: Re: [6tisch] removing the 'e'

Hi Pascal:

The 802.15.4rev draft is, as the wording suggests, a *draft* specification. One should not give the impression as if this would be a stable draft, let alone a specification cast in stone. Thus, referencing to this as "802.15.4-2015" puts people on the wrong footing. Moreover, already anticipating that this draft reaches the end station in 2015, even prior to start of sponsor ballot, casts some doubt as to how receptive one would be to consider comments received during sponsor ballot.

My only comment right now is that, in its current form, removing the "e" 
is premature. This may change over time, but one should not let 802.15 folks be the arbiter of this, but users of this specification, including 6TiSCH.

BTW - ZigBee mostly uses the 802.15.4-2006 specification and most 6lowpan documents also refer to that specification.

Best regards, Rene

On 3/31/2015 3:07 AM, Pascal Thubert (pthubert) wrote:
>> I think the proper approach is that one investigates whether an 
>> updated version of a cross-referenced specification is suitable and, if so, one can adopt this.
>>
>> We should use a "trust but verify" approach here. Anything else would 
>> be imprudent. I think this more or less reiterates Subir Das's point.
>>
>> a) not sure why the 802.15.4e amendment would be incomplete. This 
>> seems to be in direct conflict with the note on page 1 of the 
>> 802.15.4e-2012 standard (NOTE-The editing instructions contained in 
>> this amendment define how to merge the material contained therein 
>> into the existing base standard and its amendments to form the comprehensive standard).
>> will be in 2015 (with sponsor ballot not having started yet) seems somewhat premature.
>>
>> Rene
>>
>> after IEEE802.15.4 in our current charter and WG Documents (slides at 
>> the end of http://www.ietf.org/proceedings/92/slides/slides-92-6tisch-2.pdf ).
>> 2015 should be available soon -, our normative references will 
>> implicitly pick that latest version and inherit the fixes that were 
>> made since then, as well as the additional PHYs on which 802.15.4 TSCH can operate.
>> particular versions, and a change in an RFC is a new RFC thus a new 
>> reference, and the IEEE form of reference may create an issue with 
>> IETF practice. The chairs will need to validate this before proceeding.
>> is just an amendment, which is an incomplete reference, and that it 
>> yields some incorrectness that is now fixed in the upcoming 2015 version of 802.15.4.

---

From: Rene Struik <[email-masked]>
Date: Tue, 31 Mar 2015 10:25:27 -0400

Hi Pat (Brett):

FYI - Let us be more precise when referring to specs: 802.15.4e is *not* 
a draft; it is a standard specification that has been available in the 
IEEE-SA "store" since 2012.

Best regards, Rene

==
Available from: 
https://standards.ieee.org/findstds/standard/802.15.4e-2012.html

---

From: Tom Phinney <[email-masked]>
Date: Tue, 31 Mar 2015 07:37:52 -0700

Let us be even more specific: 802.15.4e:2012 is a standard specification 
that has been available since 2012. On the other hand, an unqualified 
802.15.4e could be revision "e" to a future draft of 802.15.4 if the 
IEEE-SA policy changed to permit reuse of revision letters within IEEE 
802 standards. Each SDO has its own rules with regard to how revisions 
are identified. It is for this reason that a formal identification 
policy is wise.

IETF started out referencing just their own IETF standards, as 
separately did ISO and IEC and IEEE. But we now live in an 
interconnected world where each of these SDOs may need to reference 
existing standards of other SDOs. It is for that reason that explicit 
identification of the edition of a referenced standard (e.g., through 
appending the year of publication to the citation) is often a necessary 
choice.

-Tom
=====
On 2015.03.31 07:25, Rene Struik wrote:
> Hi Pat (Brett):
>
> FYI - Let us be more precise when referring to specs: 802.15.4e is 
> *not* a draft; it is a standard specification that has been available 
> in the IEEE-SA "store" since 2012.
>
> Best regards, Rene
>
> ==
> Available from: 
>> Could there be a  reference 802.15.4e, noting it is a draft which is 
>> to be finalized and included in the 802.15.4-2015 standard?
>>
>> specification. One should not give the impression as if this would be 
>> a stable draft, let alone a specification cast in stone. Thus, 
>> referencing to this as "802.15.4-2015" puts people on the wrong 
>> footing. Moreover, already anticipating that this draft reaches the 
>> end station in 2015, even prior to start of sponsor ballot, casts 
>> some doubt as to how receptive one would be to consider comments 
>> received during sponsor ballot.
>>
>> is premature. This may change over time, but one should not let 
>> 802.15 folks be the arbiter of this, but users of this specification, 
>> including 6TiSCH.
>>
>>> Hello Ren�:
>>> So far, 6TiSCH has not expressed requirements on TSCH. We have taken 
>>> it as a base and built upon it. So I can hardly relate your words to 
>>> something specific.
>>>
>>> - The base that we have considered for the architecture is very 
>>> abstract since we had a goal to design beyond 802.15.4 whenever 
>>> possible. From Pat's presentation, I have trouble believing that 
>>> this text is affected at all, but then I'm interested in any 
>>> specific point, and it is still time to fix Archie's text.
>>>
>>> - For the more specific draft, a good suggestion could be to ask the 
>>> Interest Group to review the minimal and 6top interface drafts and 
>>> assert whether and how they are affected by the change to 
>>> 802.15.4-2015, so as to promote an action either on the IEEE or on 
>>> the IETF side. I gathered from Pat that they are not, but a formal 
>>> review from the I-G could help close that discussion.
>>>
>>>> the end of 
>>>> http://www.ietf.org/proceedings/92/slides/slides-92-6tisch-2.pdf ).

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 31 Mar 2015 10:01:36 -0700

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

---

From: Pat Kinney <[email-masked]>
Date: Tue, 31 Mar 2015 12:13:37 -0500

And I can’t resist replying to Jonathan (the rock star of TSCH)
- "short address doesn’t leak info if only authenticating”
<PK> at the risk of irritating security folks again, the problem I have is that 4e’s text mandates that all frames using the 2-octet address shall use not use the 8-octet address in nonce generation.  If 4e had used a reserved bit in the security control field of the Security Auxiliary Header to indicate which type of address to use (i.e. short or extended) with the default set to extended, I really wouldn’t mind.
- "I also think that policing IE’s is naive - the IEEE doesn’t own the band”
<PK> are you accusing 802.15 of being a “nanny state”?

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 31, Mar2015, at 12:01, Jonathan Simon <[email-masked]> wrote:

Chiming in…

-- 
Jonathan 

> [email-masked] <mailto:[email-masked]>_______________________________________________
6tisch mailing list
[email-masked]