Subject: [6tisch] Removing the 'e' in the charter

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Apr 2015 00:15:16 +0000

Dear all :

At the interim last Friday we found that we should not mix the question on the references in the draft and that of the 'e' in the charter.
For the specific case of the 'e', we discussed that the group will not stop brutally at the end of 2015 and that we really work on TSCH, so we could remove the 'e'.
This is a call for consensus. The proposal on the table is effectively to remove the 'e'; if you disagree please let us know now.
We'll conclude this call at the interim next Friday.

Cheers,

Pascal

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 30 Apr 2015 05:52:06 +0200

Hi,

I think we said that 'e' will only be specifically referenced on those
documents that specifically deal with 15.4e-2012. If so, I support the
proposal.

regards,
Xavi

2015-04-30 2:15 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

>  Dear all :
>
>
>
> At the interim last Friday we found that we should not mix the question on
> the references in the draft and that of the ‘e’ in the charter.
>
> For the specific case of the ‘e’, we discussed that the group will not
> stop brutally at the end of 2015 and that we really work on TSCH, so we
> could remove the ‘e’.
>
> This is a call for consensus. The proposal on the table is effectively to
> remove the ‘e’; if you disagree please let us know now.
>
> We’ll conclude this call at the interim next Friday.
>
>
>
> Cheers,
>
>
>
> Pascal
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Apr 2015 09:24:05 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > At the interim last Friday we found that we should not mix the
    > question on the references in the draft and that of the ‘e’ in the
    > charter.

    > stop brutally at the end of 2015 and that we really work on TSCH, so
    > we could remove the ‘e’.

    > This is a call for consensus. The proposal on the table is effectively
    > to remove the ‘e’; if you disagree please let us know now.

I still do not understand IEEE referencing rules.

I found one of Pascal's comments interesting. If I understood, he said:
     * If we reference IEEE document without a year (or I guess, letter), and IEEE
       breaks something in a future that we depend upon, then we would have a
       basis for complaint.
     * If we reference IEEE document with a year, then we have no basis for a
       complaint, as they aren't changing/breaking the old spec.

But, I'm unclear what it means to reference "802.15.4" today, when
802.15.4-2015 is not yet published (Auguest 2015, said Pat).
I therefore think it appropriate to drop the "e" only when the -2015 is out,
so let's do that in November.  At which point, my question about -year vs
not year might have a different answer.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Apr 2015 14:15:43 +0000

Hello Michael:

Today, undated and without the 'e', IEEE802.15.4 means 2011 plus all the amendments. 
Robert has summarized it all in the attached mails for us.

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: jeudi 30 avril 2015 06:24
> To: [email-masked]
> Subject: Re: [6tisch] Removing the 'e' in the charter
> 
> 
> I therefore think it appropriate to drop the "e" only when the -2015 is out, so
> let's do that in November.  At which point, my question about -year vs not year
> might have a different answer.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
> 

Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
From: ROBERT GROW <[email-masked]>
To: Ralph Droms <[email-masked]>
Cc: "Pascal Thubert (pthubert)" <[email-masked]>, Tom Phinney <[email-masked]>, "Heather Flanagan (RFC Series Editor)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 1 Apr 2015 20:53:29 +0000

When a new revision is approved, in IEEE terminology, the old standard is superseded, including any approved amendments and corrigenda.  It is also possible to withdraw an IEEE standard (less common.  Superseded and withdrawn standards remain available.

In IEEE, there is a rule, that once approved an amendment or corrigenda to a standard becomes part of that standard.  So, today, a reference to IEEE Std 802.3-2012 technically also includes IEEE Std 802.3bk-2013, IEEE Std 802.3bj-2014 and IEEE Std 802.3bm-2015 (as indicated by Ralph’s description of 802.15.4 being a collection) .  So, a reference to IEEE Std 802.3 (without year) today is identical to the 2012 dated reference, but when the current revision is approved (expected this year), a reference to the 2012 revision would not include the maintenance changes included in the current revision, nor any of the amendments likely to be approved soon after the revision is approved.

The current revision of IEEE Std 802.11-2012 includes five amendments.  The cover page of revision drafts and the published revision both include a list of the included documents (previous revision, amendments and corrigenda).

IEEE Std 802.15.3-2003 only has two approved amendments but because of IEEE rules, it will have to be revised so that two current amendment projects can be approved.  (After three years, an IEEE standard must be revised if there are three or more approved amendments before an additional amendment can be approved, unless an extension to the rule is granted.)  This results in frequent revisions to active 802 standards, and consequently a motivation to use undated references when possible.

As Pat noted, when referencing a specific section of a document, the dated version indicates where to find the actual text considered when writing the RFC.  In that case, it would be appropriate to directly reference an amendment even though the amendment is technically part of the base standard (a kindness to readers of the RFC).

Pascal, because of the inclusion of amendments and corrigenda in the base, the note might have to be more detailed and include listing the approved amendments also considered by the RFC.  Such a note might be simply, "At the time of publication of this RFC, IEEE Std 802.15.4 consisted of IEEE Std 802.15.4-2011, IEEE ,,,” (there are currently seven approved amendments).  This though creates a possible accuracy problem as there could be a race between doing the technical work on the RFC and approval of an amendment.  An alternative would be, In development of this RFC, IEEE Std 802.99 documents considered included IEEE Std 802.99-2016 and P802.99/D8. (The later allowing consideration of a draft that is not expected to change in a substantive way.)

—Bob

On Apr 1, 2015, at 10:40 AM, Ralph Droms <[email-masked]> wrote:

>
>> On Apr 1, 2015, at 1:32 PM 4/1/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
>>
>> Hello Heather:
>>
>> We can expect that the text has some dependencies on the target SDO. Because we do not do things the same way.
>>
>> We, at the IETF, deprecate and RFC by a new one; it is unclear to me what becomes of RFCb that references RFCa after RFCa is deprecated and until RFC is deprecated.
>>
>> The IEEE does things differently. E.g. IEEE802.15.4 is a collection of the LATEST version of the standard and the sum of all amendments till now. This implies a different handling of the reference.
>> If another SDO does things in yet another fashion, we will have to adapt as well. Tom (added to the discussion) and the IEC did a great job at dealing with that problem, and we c(sh)ould take inspiration from them.
>
> Don't the various versions of an IEEE standards document have appended versioning information; e.g.:
>
> IEEE STANDARD 802.15.4-2011 - IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
>
> - Ralph
>
>>
>> We could for instance request to add a note of applicability to the standard reference for all normative references outside the IETF, as suggested in RFC 4897 for some IETF references.
>>
>> For IEEE, the note could be, like, "this RFC is design to apply on the version of <IEEE standard blah without  a date, e.g. IEEE802.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 <IEEE standard blah without  a date> versions published after the publication of this RFC. The earliest version of <IEEE standard blah without  a date> that is supported is from <date, amendment>.".
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of
>>> Heather Flanagan (RFC Series Editor)
>>> Sent: mercredi 1 avril 2015 16:26
>>> To: [email-masked]
>>> Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
>>>
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 4/1/15 7:10 AM, Barry Leiba wrote:
>>>> Hi, Pascal.  Thanks for digging into this.
>>>>
>>>>> All in all, do we have a best practice for IEEE references? If not,
>>> should
>>>>> we write one?
>>>>
>>>> I think that would be a fine idea.  I think you should talk it over
>>>> with Heather (RFC Series Editor) before embarking on that, to make
>>>> sure it meshes with the RFC Editor view of handling references.  And
>>>> it would be nice if the advice could generally apply to references to
>>>> documents by other SDOs, rather than just to IEEE.
>>>
>>> And in fact, we do have some guidance on referencing other SDOs in the RFC
>>> Style Guide (RFC 7322, Section 4.8.66).  But that's not specific to IEEE, and
>>> doesn't get into the detail I think you're looking for.
>>>
>>>>
>>>>
>>>>> - The general expectation is that work at the IETF that depends on an
>>> IEEE
>>>>> standard stays valid when a newer version of that IEEE standard that
>>>>> gets published. This is certainly the case for the RFCs listed above.
>>>>>
>>>>> - My understanding is that the IEEE expects an RFC to reference the
>>>>> IEEE standard without the year-version (e.g. 802.15.4 as opposed to
>>>>> 802.15.4-2006) when that is the case, so as to implicitly include new
>>>>> upcoming versions.
>>>>
>>>> As a general case, that's definitely true.
>>>>
>>>> And I'm sure that when there are clear version-dependencies, that's
>>>> well known and the authors will handle that.
>>>>
>>>> Where it becomes dicey is when (as we should when we reference a
>>>> lengthy specification) we cite a specific section in order to help the
>>>> reader find what we're referencing... and then, while the substance
>>>> doesn't change in a future version, the section number does.  I think
>>>> that can be handled by coding the section reference carefully ("see
>>>> Section 6.1 in the 2006 version", or some such), but it's something
>>>> that probably deserves mention in any advice on how to do the
>>>> references.
>>>>
>>>
>>> I'd be happy to get into more detail with anyone interested in spending some
>>> time on it.  I'd prefer that it be more broadly applicable than just the IEEE.
>>>
>>> - -Heather
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2
>>> Comment: GPGTools - http://gpgtools.org
>>>
>>> iQEcBAEBCAAGBQJVG//4AAoJEER/xjINbZoGZ3oH/iUPtgj+9xtD2h2xhjGIOTNy
>>> xpz3dPX2ZIHTYOrsUde1CmxzinPMBCYyGibppbae0yP5kb3wDoBd9IePoQGfNNLe
>>> gGSROmURw4+cgzk0qTDApiXDz3PbsJ79LbEAZq2KCQFTRF7/tRfMvWMUey2lTdb
>>> G
>>> JbCyEmnVNjQYaJ74s4XtK3PDw5amX5nETaAipTyDsraUMteJYawcRK9OQFZ8KUby
>>> vZu+IMgDOTkSss0sw9e9I63ZS91170C80BCrpHmCOpDESzYKRaNdWtEZVdIE7Tyb
>>> sCSYlpQdJN+6yMWwscULfilTrUOZ9bSOI489NYX1z9oXcc0peYwrAJy4OVqHOA4=
>>> =53Fo
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> ieee-ietf-coord mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>> <Mail Attachment.eml><Mail Attachment.eml><Mail Attachment.eml>_______________________________________________
>> ieee-ietf-coord mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
From: ROBERT GROW <[email-masked]>
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: Ralph Droms <[email-masked]>, "Heather Flanagan (RFC Series Editor)" <[email-masked]>, Tom Phinney <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Apr 2015 21:10:13 +0000

Pascal:

I’m not the best source for accuracy of 802.15 information, but from my files, the history of 802.15.4 is:

IEEE Std 802.15.4-2003
IEEE Std 802.15.4-2006
    IEEE Std 802.15.4a-2007
    IEEE Std 802.15.4c-2009
    IEEE Std 802.15.4d-2009
IEEE Std 802.15.4-2011
    IEEE Std 802.15.4e-2012
    IEEE Std 802.15.4f-2012
    IEEE Std 802.15.4g-2012
    IEEE Std 802.15.4j-2013
    IEEE Std 802.15.4k-2013
    IEEE Std 802.15.4m-2014
    IEEE Std 802.15.4p-2014
Current active PARs
    P802.15.4 (revision)
    P802.15.4-2011/Cor 1
    P802.15.4n
    P802.15.4q
    P802.15.4r
    P802.15.4s

(Why they have a corrigendum and revision project both open today I can’t explain.  They should be able to do the corrigendum corrections in the revision, and reports I looked at indicate that might be what is happening.  The revision received conditional approval for Sponsor Ballot in March, typically meaning that a new revision will be completed this year.  The active amendment projects will then become amendments to IEEE Std 802.15.4-20xx (presumably 2015).)

More information below.

—Bob

On Apr 2, 2015, at 9:28 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

> This is incredibly useful Robert!
>
> Thanks for every single word of it; it's all very clear, but yields additional need for clarification.
>
> - RFC 4944 has the following NORMATIVE reference:
>               [ieee802.15.4]  IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
> Does it mean that the 6LoWPAN is currently not defined on the 2006 and the 2011 versions of 802.15.4?

<RMG> Seems like the reference should probably be without year.  Best to check with an 802.15 expert on any potential problems.  With Ethernet, we don’t care what runs above the MAC sublayer.  I think 802.15 though has done some specifications higher up the stack.  One minor problem I didn’t mention with undated references is that document titles can change with a revision.  I note that IEEE Std 802.15.4 has abbreviated its title between 2003 and 2011.  The title today is:  IEEE Standard for Local and metropolitan area networks—Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs).  Approval of all IEEE standards is actually by the IEEE Standards Association for all IEEE Standards (IEEE Standards Association, IEEE Computer Society and Sponsored by the LAN/MAN Standards Committee is just IEEE organizational stuff.)  The copyright for any IEEE standard is owned by The Institute of Electrical and Electronics Engineers, Inc.

One thing IEEE typically does in include a paragraph before the list of normative references encouraging consideration of the latest version of the references (as well as explaining that undated references indicate the latest revision should be used.  So, by my training, the 2003 dated reference only indicates what was the case when the RFC was written.  It doesn’t mean that 6LoWPAN can’t be used with the current revision.
>
> - RFC 6282 points on the 2006 version, but as INFORMATIVE:
>               [IEEE802.15.4]  IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006.
> Does the INFORMATIVE change anything to the applicability of the RFC to various levels of the MAC/PHY?

<RMG> IETF interpretation of informative and normative may be different than the meaning of the terms in IEEE standards.  Informative content is helpful but not required to implement the standard.  Ethernet doesn’t care if it has IPv4, IPv6 or something else running above it, so for those higher transport protocols, an informative reference is appropriate.  A management RFC though might appropriately use a normative reference to IEEE Std 802.3.1, Ethernet MIBs.  Again though, the dated reference does not necessarily preclude use of an RFC with newer versions of the IEEE standard.
>
> - We are discussing pointing to our charter and documents to " IEEE Std. 802.15.4" with no date. Today, the base 802.15.4 spec is 2011. Would that reference it mean that 2006 and 2003 are implicitly supported not supported?

<RMG> Here, I’ll have to go to Ethernet again because of my lack of familiarity with Wireless PAN.
1.  The original Ethernet standard was dated 1985.  It specified 10BASE5.  A few revisions ago, we deprecated 10BASE-5 with text that remains that 10BASE-5 is not recommended for new installations.  Since 10BASE-5 is still in the current revision project, it will continue to be a conformant speed and media option for Ethernet.
2.  Link Aggregation though is a different case, the specifications for this were moved to IEEE Std 802.1AX, so a undated reference to 802.3 would not get you Link Aggregation specifications.  All you find in Clause 43 now is:  "NOTE—The Link Aggregation specification was moved to IEEE Std 802.1AX(TM)-2008 during the IEEE Std 802.3-2008 revision.”  So an undated reference in a 2007 RFC would not include Link Aggregation, but at least with Std 802.3, an implementer can find the specifications.
3.  You may be familiar with Cat 5e cables for Ethernet.  In 802.3, we typically use ISO/IEC cabling standard references rather than the TIA specifications for Cat x cables.  So, you will find 100BASE-TX 802.3 specifications now reference the 1995 standard for Class D (essentially the same as TIA Cat 5), because the subsequent revision redefined Class D to be equivalent to Cat 5e (what is required for 1000BASE-T).  (We didn’t want to make a Cat 5 cabling installation non-conformant to the current standard just because of the change in the ISO/IEC 11801 standard for Class D.  Not all standards groups will be as careful in preserving conformance of legacy equipment.)

One risk then with an undated reference is if the referenced standard deletes something you are using (e.g., the 802.3 Link Aggregation example); and an old undated reference is no longer valid for the intended purpose of the reference.  There is a similar risk for changes in specification (e.g. the 802.3 Class D example).
>
> - Same question if we added 2011; I understand from the clarification in your mail that it would mean that the amendment is included; but what about 2003 and 2006?

<RMG> You would have to ask an 802.15 expert if anything of relevance was deleted during the revisions.  Typically we just add and correct content over the years, but as noted above, not always.  The 801.15.4-2003 initial standard was superseded by the 2006 revision, and the 2006 revision superseded by the 2011 revision.  The 2011 revision will similarly be superseded by the current revision project when it is approved.
>
> - As it goes, the TSCH operation that we need came in with the amendment 802.15.4e, meaning that -2011 did not incorporate it prior to sometime in 2012 when the amendment was published. If the answer to the one of questions above is that 2006 is implicitly supported, then we need to add something in the node that says that 802.15.4 is OK starting from that date in 2012 or from that amendment. Would you have a suggestion to word that correctly?

<RMG> Making a recommendation here is dangerous because of my ignorance about both 802.15.4 and TSCH.  If referencing 2011, I would probably add an informative note that the RFC relies on the capabilities added to IEEE Std 802.15.4-2011 by IEEE Std 802.15.4e-2012.  (Few of the RFC readers would be aware of the level of detail we have been discussing and the subtlety that amendments become part of the base standard when approved, so a note would make the document user friendly.  Because you might be in a race with the current 802.15.4 revision, I personally would even do that for an undated reference.)

>
> Thanks again!!!
>
> Pascal
>
>
>> -----Original Message-----
>> From: ROBERT GROW [mailto:[email-masked]]
>> Sent: mercredi 1 avril 2015 22:53
>> To: Ralph Droms
>> Cc: Pascal Thubert (pthubert); Tom Phinney; Heather Flanagan (RFC Series
>> Editor); [email-masked]
>> Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
>>
>> When a new revision is approved, in IEEE terminology, the old standard is
>> superseded, including any approved amendments and corrigenda.  It is also
>> possible to withdraw an IEEE standard (less common.  Superseded and
>> withdrawn standards remain available.
>>
>> In IEEE, there is a rule, that once approved an amendment or corrigenda to a
>> standard becomes part of that standard.  So, today, a reference to IEEE Std
>> 802.3-2012 technically also includes IEEE Std 802.3bk-2013, IEEE Std 802.3bj-
>> 2014 and IEEE Std 802.3bm-2015 (as indicated by Ralph's description of 802.15.4
>> being a collection) .  So, a reference to IEEE Std 802.3 (without year) today is
>> identical to the 2012 dated reference, but when the current revision is approved
>> (expected this year), a reference to the 2012 revision would not include the
>> maintenance changes included in the current revision, nor any of the
>> amendments likely to be approved soon after the revision is approved.
>>
>> The current revision of IEEE Std 802.11-2012 includes five amendments.  The
>> cover page of revision drafts and the published revision both include a list of the
>> included documents (previous revision, amendments and corrigenda).
>>
>> IEEE Std 802.15.3-2003 only has two approved amendments but because of IEEE
>> rules, it will have to be revised so that two current amendment projects can be
>> approved.  (After three years, an IEEE standard must be revised if there are three
>> or more approved amendments before an additional amendment can be
>> approved, unless an extension to the rule is granted.)  This results in frequent
>> revisions to active 802 standards, and consequently a motivation to use undated
>> references when possible.
>>
>> As Pat noted, when referencing a specific section of a document, the dated
>> version indicates where to find the actual text considered when writing the RFC.
>> In that case, it would be appropriate to directly reference an amendment even
>> though the amendment is technically part of the base standard (a kindness to
>> readers of the RFC).
>>
>> Pascal, because of the inclusion of amendments and corrigenda in the base, the
>> note might have to be more detailed and include listing the approved
>> amendments also considered by the RFC.  Such a note might be simply, "At the
>> time of publication of this RFC, IEEE Std 802.15.4 consisted of IEEE Std 802.15.4-
>> 2011, IEEE ,,," (there are currently seven approved amendments).  This though
>> creates a possible accuracy problem as there could be a race between doing the
>> technical work on the RFC and approval of an amendment.  An alternative would
>> be, In development of this RFC, IEEE Std 802.99 documents considered included
>> IEEE Std 802.99-2016 and P802.99/D8. (The later allowing consideration of a
>> draft that is not expected to change in a substantive way.)
>>
>> -Bob
>>
>> On Apr 1, 2015, at 10:40 AM, Ralph Droms <[email-masked]> wrote:
>>
>>>
>>>> On Apr 1, 2015, at 1:32 PM 4/1/15, Pascal Thubert (pthubert)
>> <[email-masked]> wrote:
>>>>
>>>> Hello Heather:
>>>>
>>>> We can expect that the text has some dependencies on the target SDO.
>> Because we do not do things the same way.
>>>>
>>>> We, at the IETF, deprecate and RFC by a new one; it is unclear to me what
>> becomes of RFCb that references RFCa after RFCa is deprecated and until RFC is
>> deprecated.
>>>>
>>>> The IEEE does things differently. E.g. IEEE802.15.4 is a collection of the
>> LATEST version of the standard and the sum of all amendments till now. This
>> implies a different handling of the reference.
>>>> If another SDO does things in yet another fashion, we will have to adapt as
>> well. Tom (added to the discussion) and the IEC did a great job at dealing with
>> that problem, and we c(sh)ould take inspiration from them.
>>>
>>> Don't the various versions of an IEEE standards document have appended
>> versioning information; e.g.:
>>>
>>> IEEE STANDARD 802.15.4-2011 - IEEE Standard for Local and metropolitan
>>> area networks--Part 15.4: Low-Rate Wireless Personal Area Networks
>>> (LR-WPANs)
>>>
>>> - Ralph
>>>
>>>>
>>>> We could for instance request to add a note of applicability to the standard
>> reference for all normative references outside the IETF, as suggested in RFC
>> 4897 for some IETF references.
>>>>
>>>> For IEEE, the note could be, like, "this RFC is design to apply on the version of
>> <IEEE standard blah without  a date, e.g. IEEE802.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 <IEEE standard blah without  a date> versions published after
>> the publication of this RFC. The earliest version of <IEEE standard blah without  a
>> date> that is supported is from <date, amendment>.".
>>>>
>>>> What do you think?
>>>>
>>>> Pascal
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ieee-ietf-coord [mailto:[email-masked]] On
>>>>> Behalf Of Heather Flanagan (RFC Series Editor)
>>>>> Sent: mercredi 1 avril 2015 16:26
>>>>> To: [email-masked]
>>>>> Subject: Re: [ieee-ietf-coord] On references to IEEE standards in
>>>>> IETF RFCs
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> On 4/1/15 7:10 AM, Barry Leiba wrote:
>>>>>> Hi, Pascal.  Thanks for digging into this.
>>>>>>
>>>>>>> All in all, do we have a best practice for IEEE references? If
>>>>>>> not,
>>>>> should
>>>>>>> we write one?
>>>>>>
>>>>>> I think that would be a fine idea.  I think you should talk it over
>>>>>> with Heather (RFC Series Editor) before embarking on that, to make
>>>>>> sure it meshes with the RFC Editor view of handling references.
>>>>>> And it would be nice if the advice could generally apply to
>>>>>> references to documents by other SDOs, rather than just to IEEE.
>>>>>
>>>>> And in fact, we do have some guidance on referencing other SDOs in
>>>>> the RFC Style Guide (RFC 7322, Section 4.8.66).  But that's not
>>>>> specific to IEEE, and doesn't get into the detail I think you're looking for.
>>>>>
>>>>>>
>>>>>>
>>>>>>> - The general expectation is that work at the IETF that depends on
>>>>>>> an
>>>>> IEEE
>>>>>>> standard stays valid when a newer version of that IEEE standard
>>>>>>> that gets published. This is certainly the case for the RFCs listed above.
>>>>>>>
>>>>>>> - My understanding is that the IEEE expects an RFC to reference
>>>>>>> the IEEE standard without the year-version (e.g. 802.15.4 as
>>>>>>> opposed to
>>>>>>> 802.15.4-2006) when that is the case, so as to implicitly include
>>>>>>> new upcoming versions.
>>>>>>
>>>>>> As a general case, that's definitely true.
>>>>>>
>>>>>> And I'm sure that when there are clear version-dependencies, that's
>>>>>> well known and the authors will handle that.
>>>>>>
>>>>>> Where it becomes dicey is when (as we should when we reference a
>>>>>> lengthy specification) we cite a specific section in order to help
>>>>>> the reader find what we're referencing... and then, while the
>>>>>> substance doesn't change in a future version, the section number
>>>>>> does.  I think that can be handled by coding the section reference
>>>>>> carefully ("see Section 6.1 in the 2006 version", or some such),
>>>>>> but it's something that probably deserves mention in any advice on
>>>>>> how to do the references.
>>>>>>
>>>>>
>>>>> I'd be happy to get into more detail with anyone interested in
>>>>> spending some time on it.  I'd prefer that it be more broadly applicable than
>> just the IEEE.
>>>>>
>>>>> - -Heather
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG/MacGPG2 v2
>>>>> Comment: GPGTools - http://gpgtools.org
>>>>>
>>>>>
>> iQEcBAEBCAAGBQJVG//4AAoJEER/xjINbZoGZ3oH/iUPtgj+9xtD2h2xhjGIOTNy
>>>>>
>> xpz3dPX2ZIHTYOrsUde1CmxzinPMBCYyGibppbae0yP5kb3wDoBd9IePoQGfNNLe
>>>>>
>> gGSROmURw4+cgzk0qTDApiXDz3PbsJ79LbEAZq2KCQFTRF7/tRfMvWMUey2lTdb
>>>>> G
>>>>>
>> JbCyEmnVNjQYaJ74s4XtK3PDw5amX5nETaAipTyDsraUMteJYawcRK9OQFZ8KUby
>>>>>
>> vZu+IMgDOTkSss0sw9e9I63ZS91170C80BCrpHmCOpDESzYKRaNdWtEZVdIE7Tyb
>>>>>
>> sCSYlpQdJN+6yMWwscULfilTrUOZ9bSOI489NYX1z9oXcc0peYwrAJy4OVqHOA4=
>>>>> =53Fo
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>>
>>>>> ieee-ietf-coord mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>> <Mail Attachment.eml><Mail Attachment.eml><Mail
>>>> Attachment.eml>_______________________________________________
>>>> ieee-ietf-coord mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>
>>> ieee-ietf-coord mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: Pat Kinney <[email-masked]>
Date: Thu, 30 Apr 2015 09:23:17 -0500

Michael;

I understand your confusion.  The standard is IEEE 802.15.4, a specific document has a year at the end, hence IEEE 802.15.4-2003 or IEEE 802.15.4-2006 refer to old versions of the IEEE 802.15.4 standard.  An amendment or corrigendum adds a letter and the year of approval onto the end of the standard it is modifying, e.g. IEEE 802.15.4e-2012 denotes the amendment document for the MAC enhancements.

When an amendment or a corrigendum is approved, it becomes part of the standard, e.g. IEEE 802.15.4 includes amendments a, c, d, e, f, g, j, k, m, and p.  Please note that at this time there is no single document defining the whole 802.15.4 standard, that is what the current revision draft (currently believed to be IEEE 802.15.4-2015) will do.

You have mentioned “and IEEE breaks something”, I would like to clarify this concept. A significant effort is used to make sure all changes are backwards compatible, however sometimes that isn’t always possible.  For example. in 802.15.4-2003 the security was broken, when 802.15.4-2006 was released it fixed the security issue(s) but broke backward compatibility for security, hence the only backward compatibility between 802.15.4-2006 and 802.15.4-2003 is for no security. Accordingly, if a non-IEEE 802.15 group addresses a problem with 802.15.4 by citing an exception to the standard to work around a problem, future versions of the standard may not be backward compatible with the exception.

If a person or persons are concerned about a new revision “breaking” some aspect of the standard, they can participate in the work effort to revise the standard.  Participation is possible by attending the meetings and becoming a voter, or just by attending the conference calls and reading the meeting minutes.  Before a draft is submitted to letter ballot it is open for all to review, it is only after letter ballot has started that it is viewable by voting members only.

Back to Michael’s final statement, I have already stated what is meant by 802.15.4, but what is meant by 802.15.4e-2012?  IEEE 802.15.4e-2012 is a document that states the approved changes to the IEEE 802.15.4-2011 document.  It does not include any other amendments such as 802.15.4g (SUN PHY changes).  It also doesn’t include any fixes for known broken areas of the IEEE 802.15.4-2011 standard such as in the security section.  So, citing IEEE 802.15.4e would require 6tisch to cite exceptions to the standard, i.e. modify the standard.

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, Apr2015, at 8:24, Michael Richardson <[email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Apr 2015 10:50:30 -0400

> Today, undated and without the 'e', IEEE802.15.4 means 2011 plus all

Given that we can't run on 802.15.4-2011, this is why I'm concerned about
referencing "802.15.4".

> So, a reference to IEEE Std 802.3 (without year) today is identical to the
> 2012 dated reference, but when the current revision is approved (expected
> this year), a reference to the 2012 revision would not include the

How does an outsider know when the reference was made?  Is it by the date
of the document making the reference?

If the IETF writes a document in 2014, but it doesn't get published in Jan. 2015,
what IEEE document would "802.15.4" reference?

Robert suggests text like:

> In development of this RFC, IEEE Std 802.99 documents considered included
> IEEE Std 802.99-2016 and P802.99/D8.

and so if we can do this, then I'm happy.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Apr 2015 15:37:12 +0000

Hello Michael

For All I know 4e TSCH is only defined on 2011. There are known similar technologies running over 2006 but they are not 4e...

The undated reference in an RFC to an IEEE spec applies to the present state at the date of the RFC and to all future versions unless the RFC is revised. 

This proved useful for Ethernet; too much maybe since we were fooled into extending IP over Ethernet to Wi-Fi...

Cheers,

Pascal

> Le 30 avr. 2015 à 07:50, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Pat Kinney <[email-masked]>
Date: Thu, 30 Apr 2015 11:55:43 -0500

An amendment references (is based upon) the latest revision when it was approved, hence 802.15.4e is based upon (i.e. it references) 802.15.4-2011.

Pat
Pat Kinney
Kinney Consulting LLC

On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email-masked]> wrote:

Hello Michael

Cheers,

Pascal

---

From: Qin Wang <[email-masked]>
Date: Thu, 30 Apr 2015 20:34:33 +0000 (UTC)

Hi all,
I understand that reference IEEE 802.15.4 includes IEEE802.15.4e by definition. But I have a problem in writing 6TiSCH draft if we remove "e" in reference.  
Here is an example. "A 10ms time slot length is the default value defined by  [IEEE802154e].  Section 6.4.3.3.3 of [IEEE802154e] defines a default  macTimeslotTemplate,...." is in the section 3.4 of minimal draft. Then, the question is how to point the exact place if we use IEEE 802.15.4 as reference.
ThanksQin  

     On Friday, May 1, 2015 12:55 AM, Pat Kinney <[email-masked]> wrote:

Pat
Pat Kinney
Kinney Consulting LLC

Hello Michael

Cheers,

Pascal

---

From: ROBERT GROW <[email-masked]>
Date: Thu, 30 Apr 2015 11:28:48 -0700

May I suggest a couple rules I'd personally use for what should be included in your draft…

We have spent a lot of bits discussing how IEEE references standards.  IEEE does not assume it can mandate to another SDO how that other SDO should do its references.  

1.  Be consistent with IETF conventions for referencing standards.

IEEE includes at the beginning of its reference section an explanation that an undated reference indicates the latest version of the standard.  That is IEEE’s convention.  That does not necessarily mean that any other standards organization has to use that convention in referencing IEEE standards.  This is part of the IEEE-SA Style Manual, not a rule of IEEE-SA.  (That is why that explanation in the document rather than expecting users of the document to know this (e.g., have read the IEEE-SA Style Manual).  And, that is why I previously suggested some kind of footnote that is helpful to the user of your standard.)

2.  Be friendly to the users of your standard. 

IEEE rules also define an amendment or corrigendum as being part of the base standard when approved.  There is logic behind this, more often than not, an amendment will not provide sufficient information for a complete implementation — an implementer typically will need the base document and perhaps other amendments to properly implement a device that includes the functionality added by an amendment.  Mr. Kinney will probably correct me if I’m wrong, but I doubt you can implement a 15.4e device without specification contained in both the base standard.

A lot of participants in IEEE standards development don’t really understand this, let alone users of the standard that don’t participate in standards development.  This policy isn’t reiterated in IEEE standards so often users of the standard will miss this (e.g., question like I can’t find x in IEEE Std …).  How many of the users of your standard will understand this?  If IEEE Std 15.4e is critical help the reader understand that.

1.  Be consistent with IETF conventions for referencing standards.  (Write your references as is done for IETF.)
2.  Be friendly to the users of your standard.  (Use what editorial tools, e.g., footnotes, other kind of notes, etc., to help your readers understand what is important for them to understand.)

—Bob

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Apr 2015 21:49:54 +0000

Hello Qin:

This is why Minimal and probably 6top will need to keep a dated reference. The price to pay will be to publish an update is the conversion is non obvious to future versions on the IEEE standard…

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 30 avril 2015 13:35
To: Pat Kinney; Pascal Thubert (pthubert)
Cc: Michael Richardson; [email-masked]; ROBERT GROW ([email-masked])
Subject: Re: [6tisch] Removing the 'e' in the charter

Hi all,

Thanks
Qin

On Friday, May 1, 2015 12:55 AM, Pat Kinney <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>

On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Michael

Cheers,

Pascal

> Le 30 avr. 2015 à 07:50, Michael Richardson <[email-masked]<mailto:[email-masked]>> a écrit :
>
>
> Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
> [email-masked]<mailto:[email-masked]>

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

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

---

From: Pat Kinney <[email-masked]>
Date: Thu, 30 Apr 2015 17:13:06 -0500

Qin;

You are correct that referring only to the standard does not allow you to refer to sub-clauses or pages and line numbers.  

I would propose changing the current text:
" A 10ms time slot length is the default value defined by [IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e] defines a default macTimeslotTemplate, i.e. the different duration within the slot. These values are summarized in the following table and MUST be used when utilizing the default time slot duration. In this case, the Timeslot IE only transports the macTimeslotTemplateId (0x00) as the timing values are well known. If a timeslot template other than the default is used, the EB MUST contain a complete TimeSlot IE indicating the timeslot duration and the corresponding timeslot timings, requiring 25 bytes. Note however that in case of discrepancy between the values in this document and [IEEE802154e], the IEEE standard specification has precedence.” 

with the following text:
“The timing parameters for the default macTimeslotTemplate (macTsTemplateID = 0) are summarized in the following table and MUST be used when utilizing the default time slot duration. For the case of the default macTimeslotTemplate, the Timeslot IE only transports the macTimeslotTemplateId (0x00) as the timing values are previously known. If a timeslot template other than the default is used, the EB MUST contain a complete TimeSlot IE indicating the timeslot duration and the corresponding timeslot timings. Note however that in case of discrepancy between the values in this document and IEEE 802.15.4, the IEEE standard has precedence.

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] <mailto:[email-masked]>
On 30, Apr2015, at 15:34, Qin Wang <[email-masked]> wrote:

Hi all,

Thanks
Qin

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] <mailto:[email-masked]>

On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:

Hello Michael

Cheers,

Pascal

> Le 30 avr. 2015 à 07:50, Michael Richardson <[email-masked] <mailto:[email-masked]>> a écrit :
> 
> 
> Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

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

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

---

From: Tom Phinney <[email-masked]>
Date: Thu, 30 Apr 2015 15:40:02 -0700

Pat,

I agree with you completely. In my experience, many contributors to
standards believe it to be their job to guide a reader into finding
material in a normative reference by citing specific 'chapter and
verse", or in this case detailed subclause numbering, when instead
they should be indicating the topic area and specific information
that is of importance. Standards that call out lots of specific
subclauses by number are a nightmare to maintain, particularly if
they reference more than one other normative standard in such
detail, because they necessarily need to be updated whenever ANY of
those cited-in-detail normative references are updated.

If the writer of such clauses was told that they would be devoting
one week per year for the rest of their lives to maintaining and
updating all the detailed references that they included, it seems
likely that they would find ways to word the text that did not so
encumber their future.

-Tom

=====

On 2015.04.30 15:13, Pat Kinney wrote:

Qin;

You are correct that referring only to the standard
does not allow you to refer to sub-clauses or pages and line
numbers.

" A 10ms time slot length is the default value
defined by [IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e]
defines a default macTimeslotTemplate, i.e. the different
duration within the slot. These values are summarized in the
following table and MUST be used when utilizing the default time
slot duration. In this case, the Timeslot IE only transports the
macTimeslotTemplateId (0x00) as the timing values are well
known. If a timeslot template other than the default is used,
the EB MUST contain a complete TimeSlot IE indicating the
timeslot duration and the corresponding timeslot timings,
requiring 25 bytes. Note however that in case of discrepancy
between the values in this document and [IEEE802154e], the IEEE
standard specification has precedence.”

with the following text:

“The timing parameters for the default macTimeslotTemplate
(macTsTemplateID = 0) are summarized in the
following table and MUST be used when utilizing the default time
slot duration. For the case of the default macTimeslotTemplate,
the Timeslot IE only transports the macTimeslotTemplateId (0x00)
as the timing values are previously known. If a timeslot
template other than the default is used, the EB MUST contain a
complete TimeSlot IE indicating the timeslot duration and the
corresponding timeslot timings. Note however that in case of
discrepancy between the values in this document and IEEE
802.15.4, the IEEE standard has precedence.

Pat

Pat Kinney

Kinney
Consulting LLC

IEEE 802.15 WG vice chair,
TG chair

ISA100.11a WG chair

O: +1.847.960.3715

Hi
all,

I understand
that reference IEEE 802.15.4 includes IEEE802.15.4e
by definition. But I have a problem in writing
6TiSCH draft if we remove "e" in reference.

Here is an
example. "A 10ms time slot length is the
default value defined by  [IEEE802154e].  Section
6.4.3.3.3 of [IEEE802154e] defines a default
macTimeslotTemplate,...." is in the section 3.4 of
minimal draft. Then, the question is how to point the
exact place if we use IEEE 802.15.4 as reference.

Thanks

Qin

On Friday, May 1, 2015
12:55 AM, Pat Kinney <[email-masked]>
wrote:

An amendment
references (is based upon) the latest revision
when it was approved, hence 802.15.4e is based
upon (i.e. it references) 802.15.4-2011.

Pat

Pat Kinney

Kinney Consulting LLC

ISA100.11a WG chair

O: +1.847.960.3715

On 30, Apr2015, at 10:37, Pascal Thubert
(pthubert) <[email-masked]>
wrote:

Hello Michael

For All I know 4e TSCH is only defined on 2011.
There are known similar technologies running
over 2006 but they are not 4e...

The undated reference in an RFC to an IEEE spec
applies to the present state at the date of the
RFC and to all future versions unless the RFC is
revised.

This proved useful for Ethernet; too much maybe
since we were fooled into extending IP over
Ethernet to Wi-Fi...

Cheers,

Pascal

> Le 30 avr. 2015 à 07:50, Michael Richardson
<[email-masked]>
a écrit :

>> Today, undated and without the 'e',
IEEE802.15.4 means 2011 plus all

>> the amendments.

6tisch mailing list

[email-masked]

6tisch mailing list

[email-masked]

---

From: ROBERT GROW <[email-masked]>
Date: Thu, 30 Apr 2015 16:05:47 -0700

It may not be appropriate (not knowing enough about the content of your drafts), but is there anything to prevent including an undated reference to 15.4 and a dated reference to 15.4e (where something inside the document is referenced)?  Optionally a note could explain that 15.4e will be merged into 15.4. 

—Bob

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 1 May 2015 01:15:19 +0200

<no chair hat>

Little thought exercise.

Let's assume we decide draft-minimal contains an undated reference to
IEEE802.15.4, and is published in 2015.

In 2016, company foo builds and sells products based on
draft-ietf-6tisch-minimal. Company foo goes to a third-party lab which
certifies conformance to draft-ietf-6tisch-minimal. Everything is great,
tens of thousands of networks go out the door. Company foo is happy.
Now IEEE802.15.4-2018 is published. IEEE802.15.4-2018 has small changes
compared to IEEE802.15.4-2015, for example the encoding of the IE header
changes from [type,length,value] to [length,type,value], for whatever
reason, good or bad.
Are company foo's product now stripped off their certification? Even if it
takes foo's engineers 2h to release firmware compliant to
IEEE802.15,4-2015, what is company foo supposed to do with it? Recall all
products? Really!?

Let's get even deeper into trouble: company bar starts making products in
2019 based on the *same* draft-ietf-6tisch-minimal standard as company foo.
These products also pass certification, and start selling. But even foo and
bar implement the *same standard*, their product do not interoperate.

>From what I understand, this is possible if we put an undated reference to
IEEE802.15.4 in draft-ietf-6tisch-minimal. In that case, we have, as a
standardization organization, completely failed. I hope I'm wrong, and I
hope you can show me why.

On Fri, May 1, 2015 at 12:40 AM, Tom Phinney <[email-masked]> wrote:

> material in a normative reference by citing specific 'chapter and verse",
> or in this case detailed subclause numbering, when instead they should be
> indicating the topic area and specific information that is of importance.
> Standards that call out lots of specific subclauses by number are a
> nightmare to maintain, particularly if they reference more than one other
> normative standard in such detail, because they necessarily need to be
> updated whenever ANY of those cited-in-detail normative references are
> updated.
>
> If the writer of such clauses was told that they would be devoting one
> week per year for the rest of their lives to maintaining and updating all
> the detailed references that they included, it seems likely that they would
> find ways to word the text that did not so encumber their future.
>
> -Tom
> =====
>  You are correct that referring only to the standard does not allow you
> to refer to sub-clauses or pages and line numbers.
>
> " A 10ms time slot length is the default value defined by [IEEE802154e].
> Section 6.4.3.3.3 of [IEEE802154e] defines a default macTimeslotTemplate,
> i.e. the different duration within the slot. These values are summarized in
> the following table and MUST be used when utilizing the default time slot
> duration. In this case, the Timeslot IE only transports the
> macTimeslotTemplateId (0x00) as the timing values are well known. If a
> timeslot template other than the default is used, the EB MUST contain a
> complete TimeSlot IE indicating the timeslot duration and the corresponding
> timeslot timings, requiring 25 bytes. Note however that in case of
> discrepancy between the values in this document and [IEEE802154e], the IEEE
> “The timing parameters for the default *macTimeslotTemplate* (
> *macTsTemplateID* = 0) are summarized in the following table and MUST be
> used when utilizing the default time slot duration. For the case of the
> default *macTimeslotTemplate*, the Timeslot IE only transports the
> macTimeslotTemplateId (0x00) as the timing values are previously known. If
> a timeslot template other than the default is used, the EB MUST contain a
> complete TimeSlot IE indicating the timeslot duration and the corresponding
> timeslot timings. Note however that in case of discrepancy between the
> values in this document and IEEE 802.15.4, the IEEE standard has precedence.
>
>
>  Pat
>
>     Pat Kinney
> *Kinney Consulting LLC*
>  I understand that reference IEEE 802.15.4 includes IEEE802.15.4e by
> definition. But I have a problem in writing 6TiSCH draft if we remove "e"
> in reference.
>
>  Here is an example. "A 10ms time slot length is the default value
> defined by  [IEEE802154e].  Section 6.4.3.3.3 of [IEEE802154e] defines a
> default  macTimeslotTemplate,...." is in the section 3.4 of minimal draft.
> Then, the question is how to point the exact place if we use IEEE 802.15.4
> as reference.
>
>  Thanks
> Qin
>
>
>
>
>    On Friday, May 1, 2015 12:55 AM, Pat Kinney <
> [email-masked]> wrote:
>
>
> An amendment references (is based upon) the latest revision when it was
> approved, hence 802.15.4e is based upon (i.e. it references) 802.15.4-2011.
>
> Pat
> Pat Kinney
> Kinney Consulting LLC
> For All I know 4e TSCH is only defined on 2011. There are known similar
> technologies running over 2006 but they are not 4e...
>
> The undated reference in an RFC to an IEEE spec applies to the present
> state at the date of the RFC and to all future versions unless the RFC is
> revised.
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Pat Kinney <[email-masked]>
Date: Thu, 30 Apr 2015 18:45:43 -0500

Thomas;

You could have used 802.3 or 802.11 for your example and everything else would be the same.  So this is not exclusively an issue with 802.15.4.  It’s not in the best interest of 802.15 to break backward compatibility for many reasons, new features will be added but in a manner that does not break backward compatibility.  The biggest issue is when a behavior is broken and fixing it would not allow backward compatibility.  In the previous case, since the behavior is broken stating a company’s product is compliant is not typically done.

Pat

Pat Kinney
Kinney Consulting LLC

On 30, Apr2015, at 18:15, Thomas Watteyne <[email-masked]> wrote:

<no chair hat>

Little thought exercise.

Let's assume we decide draft-minimal contains an undated reference to IEEE802.15.4, and is published in 2015.

In 2016, company foo builds and sells products based on draft-ietf-6tisch-minimal. Company foo goes to a third-party lab which certifies conformance to draft-ietf-6tisch-minimal. Everything is great, tens of thousands of networks go out the door. Company foo is happy.
Now IEEE802.15.4-2018 is published. IEEE802.15.4-2018 has small changes compared to IEEE802.15.4-2015, for example the encoding of the IE header changes from [type,length,value] to [length,type,value], for whatever reason, good or bad.
Are company foo's product now stripped off their certification? Even if it takes foo's engineers 2h to release firmware compliant to IEEE802.15,4-2015, what is company foo supposed to do with it? Recall all products? Really!?

Let's get even deeper into trouble: company bar starts making products in 2019 based on the same draft-ietf-6tisch-minimal standard as company foo. These products also pass certification, and start selling. But even foo and bar implement the same standard, their product do not interoperate.

From what I understand, this is possible if we put an undated reference to IEEE802.15.4 in draft-ietf-6tisch-minimal. In that case, we have, as a standardization organization, completely failed. I hope I'm wrong, and I hope you can show me why.

On Fri, May 1, 2015 at 12:40 AM, Tom Phinney <[email-masked] <mailto:[email-masked]>> wrote:
Pat,

I agree with you completely. In my experience, many contributors to standards believe it to be their job to guide a reader into finding material in a normative reference by citing specific 'chapter and verse", or in this case detailed subclause numbering, when instead they should be indicating the topic area and specific information that is of importance. Standards that call out lots of specific subclauses by number are a nightmare to maintain, particularly if they reference more than one other normative standard in such detail, because they necessarily need to be updated whenever ANY of those cited-in-detail normative references are updated.

If the writer of such clauses was told that they would be devoting one week per year for the rest of their lives to maintaining and updating all the detailed references that they included, it seems likely that they would find ways to word the text that did not so encumber their future.

-Tom
=====
On 2015.04.30 15:13, Pat Kinney wrote:
> O: +1.847.960.3715 <tel:%2B1.847.960.3715>
> On 30, Apr2015, at 15:34, Qin Wang <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all,
> 
> On Friday, May 1, 2015 12:55 AM, Pat Kinney <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> O: +1.847.960.3715 <tel:%2B1.847.960.3715>

---

From: Kris Pister <[email-masked]>
Date: Thu, 30 Apr 2015 18:17:11 -0700

Pat - I'm not on expert on the history of 802, but it does seem like 
802.15.4
is *not* the same as 802.11 .  15.4 makes incompatible revisions a lot 
more than 11.

I have an ancient laptop that has only an 802.11b radio.
When they rolled 11b into 802.11-2007, they didn't change anything (from my
perspective) because the radio still works with everything called 802.11b.

The same can not be said of 802.15.4, which has evolved with many 
incompatible
changes over the years.  Company foo shipping 4e-compliant products 
today may
find that they are not compliant with the TSCH described in 15.4-2015.  
I just don't
think that happened as often in .11 as it happens in .15.4

The world is filled with WiFi radios that have labels like "11b" and "11a"
and "11bg", why can't we have a stable IETF draft that points to "4e"?
If the standard doesn't change, no problem.
If it does change, then there won't be confusion about inter-operation:
if I have 6TisCH/4e products, they will interoperate with 6TiSCH/4e 
products.
There may be other drafts that define how to run 6TiSCH/4xyz.  RPL, UDP, 
DTLS,
and CoAP will run on all of them because they are agnostic.  But the 
lowest layer
needs to be stable so that people know what's interoperable with what.

ksjp

On 4/30/2015 4:45 PM, Pat Kinney wrote:
> 802.3 or 802.11 for your example and everything else would be the same