Subject: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

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

Dear all:

The 6TiSCH WG is discussing which reference it should place about the IEEE802.15.4 standard in our upcoming RFCs.

I have been reviewing how the IETF has been proceeding in the past, and found that we have been quite inconsistent:

- RFC 894 has NO reference to Ethernet at all, indicates that the "memo applies to the Ethernet (10-megabit/second, 48-bit addresses)", but does not limit the applicability to other speeds.
Clearly the memo was implicitly extended to any subsequent version of Ethernet.

- RFC 2644 has NO reference to Ethernet either, but just a reference to an EUI-64 tutorial, and that was before a best practice was established to separate normative and informative reference in RFCs.

- 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?

- RFC 6282 points on the 2006 version, but as INFORMATIVE:
               [IEEE802.15.4]  IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006.
How do I interpret that WRT to the 2011 and the upcoming 2015 version?

- https://tools.ietf.org/html/draft-rfc-editor-rfc2223bis is mostly a formatting guide but does not enter such consideration.

- BCP97 and RFC4897 do not discuss documents that are sourced outside the IETF; they are about procedures and warning that a downref exists and when that can be acceptable.

- 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.

- ISO/IEC has produced clear rules on how that can be implemented (see Tom's mail attached)

All in all, do we have a best practice for IEEE references? If not, should we write one?

Cheers,

Pascal

Subject: Re: [6tisch] removing the 'e'
From: Tom Phinney <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2015 21:56:39 +0000
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>

Dear all:

I was contributing a comment on this subject via the chat channel when the Thursday meeting closed. Diego, who was managing the chat channel, captured it and we subsequently have had the attached exchange.

In ISO and IEC standards the practice is to list the generic document within the list of Normative References unless there are explicit references to specific subclauses of the referenced document, in which case a specific edition needs to be called out because subclause numbering often change from one edition to the next.

Thus, if a 6tisch document references subclause m.n.p within the new 2015 edition of IEEE802.15.4, the reference would be to IEEE802.15.4:2015, m.n.p. Otherwise the reference WITHIN the standard is simply to IEEE802.15.4, without qualification as to the specific edition. While such an unqualified reference presumes that material on the referenced topic will not disappear from future editions of IEEE802.15.4, such an assumption is almost always valid and leads to much less confusion by those trying to use the standard over its lifetime.

The specific wording to cover both dated and undated references that the latest version of the ISO/IEC editing directives itself uses is:

   The following documents, in whole or in part, are normatively referenced in this document and
   are indispensable for its application. For dated references, only the edition cited applies. For
   undated references, the latest edition of the referenced document (including any
   amendments) applies.

   The related text from the ISO/IEC editing directives with regard to use of Normative References is:

   6.2.2 Normative references

   This conditional element shall give a list of the referenced documents cited (see 6.6.7.5) in
   the document in such a way as to make them indispensable for the application of the
   document. For dated references, each shall be given with its year of publication, or, in the
   case of enquiry or final drafts, with a dash together with a footnote “To be published.”, and full
   title. The year of publication or dash shall not be given for undated references. When an
   undated reference is to all parts of a document, the publication number shall be followed by
   the indication “(all parts)” and the general title of the series of parts (i.e. the introductory and
   main elements, see Annex E).

   In principle, the referenced documents shall be documents published by ISO and/or IEC.
   Documents published by other bodies may be referred to in a normative manner provided that
   a) the referenced document is recognized by the ISO and/or IEC committee concerned as
   having wide acceptance and authoritative status as well as being publicly available,
   b) the ISO and/or IEC committee concerned has obtained the agreement of the authors or
   publishers (where known) of the referenced document to its inclusion and to its being
   made available as required — the authors or publishers will be expected to make
   available such documents on request,
   c) the authors or publishers (where known) have also agreed to inform the ISO and/or IEC
   committee concerned of their intention to revise the referenced document and of the
   points the revision will concern, and
   d) the ISO and/or IEC committee concerned undertakes to review the situation in the light of
   any changes in the referenced document.

   The list shall be introduced by the following wording:
   “The following documents, in whole or in part, are normatively referenced in this
   document and are indispensable for its application. For dated references, only the edition
   cited applies. For undated references, the latest edition of the referenced document
   (including any amendments) applies.”

   The above wording is also applicable to a part of a multipart document.

   The list shall not include the following:
   • referenced documents which are not publicly available;
   • referenced documents which are only cited in an informative manner;
   • referenced documents which have merely served as bibliographic or background material
   in the preparation of the document.

   Such referenced documents may be listed in a bibliography (see 6.4.2).

   An example from the same ISO/IEC Directives, Part 2 document demonstrates proper dated-citation usage, including usage of the date only as necessary to reduce ambiguity:

   D.1.1 Scope of rules and examples provided in Annex D

   Annex D provides a synthesis of the rules and examples given in ISO 10241-1:2011, and is
   intended to cover those rules applicable to the forms of terms and definitions most commonly
   present in ISO and IEC standards. For the complete set of rules and examples, refer to
   ISO 10241-1.

   It seems likely that actual references to the 2015 edition of IEEE802.15.4 will, in fact, need to cite specific subclauses. If that is the case, then this entire discussion of whether or not to cite the edition is moot, because such citations are essential to ensure that any specific sublclause references actually point to relevant text.

   -Tom

Subject: Re: Last comment
From: "Prof. Diego Dujovne" <[email-masked]>
To: Tom Phinney <[email-masked]>
Date: Mon, 30 Mar 2015 03:16:54 +0000

Tom,

       I think what you say is completely relevant to

discuss on 6tisch so as to keep the references correct

and coherent among the documents.

      I encourage you to send these comments to the

ML, or, if you wish, I can do it for you (referencing you

as the author, of course).

     I hope to see you on the next 6tisch webex call, which

should be announced soon.

     Tell me what you think about this.

     Thank you.

     Regards,

                            Diego Dujovne

2015-03-26 13:59 GMT-03:00 Tom Phinney <[email-masked]<mailto:[email-masked]>>:

   I saw that the meeting was concluding just as I finished typing. My comment was about the general nature of references. I agree with Pat Kinney that references need to be to the current edition, which requires updates to specs that cite subclause numbers. That's why it's best not to cite such numbers. The standard text at the start of Clause 2, the Normative Reference clause, in IEC and ISO standards is

      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) applies.

   Thus most references can be to the current edition, whatever that is, meaning that the normative reference lists the document but not the edition or publication date. However, when it is necessary to cite within the specification specific subclause numbers of another document, which can change from one edition to another of that second document, then the edition listed in the normative references section must be dated.

   As to whether I can participate in the next 6tisch interim meeting, that, as always, depends on the date and time of the meeting. I participated on Monday and early this morning because it fit my schedule. However, I should have left for a class after the first hour. Instead I stayed on the connection until there was an unintended loss of connection, then reconnected to hear the end of the session.
   ===

   On 2015.03.26 09:41, Prof. Diego Dujovne wrote:

      Tom,

             Your last comment could not be included.

      Would you be able to participate on the next 6tisch

      interim meeting and reproduce that comment please?

      "Tom Phinney: An unqualified reference to a standard implies the edition listed in the normative references, which needs to specify either issue date (year) or edition. Any subclause references should be to that edition."

      Thank you!

      Regards,

                             Diego Dujovne

      --

      DIEGO DUJOVNE
      Académico Escuela de Ingeniería en Informática y Telecomunicaciones
      Facultad de Ingeniería UDP
      www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
      (56 2) 676 8125

      --

      DIEGO DUJOVNE
      Académico Escuela de Ingeniería en Informática y Telecomunicaciones
      Facultad de Ingeniería UDP
      www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
      (56 2) 676 8125

---

From: Barry Leiba <[email-masked]>
Date: Wed, 1 Apr 2015 10:10:11 -0400

Hi, Pascal.  Thanks for digging into this.

> All in all, do we have a best practice for IEEE references? If not, should

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.

> - 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.

Barry

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Wed, 01 Apr 2015 07:26:00 -0700

On 4/1/15 7:10 AM, Barry Leiba wrote:
>> All in all, do we have a best practice for IEEE references? If not,
should
>> we write one?

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.

> that probably deserves mention in any advice on how to do the

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

---

From: Pat Thaler <[email-masked]>
Date: Wed, 1 Apr 2015 16:20:36 +0000

There is some guidance on referencing IEEE standards in RFC 7241 IEEE 802 / IETF Relationship  in 3.4

When an IEEE 802 standard is revised, it normally retains the same
number and the date is updated. Therefore, IEEE 802 standards are
dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011.
There are two ways of referencing IEEE 802 standards: undated and
dated references. IEEE 802 practice allows undated reference to be
used when referencing a whole standard. An undated reference
indicates that the most recent version of the standard should be
used. A dated reference refers to a specific revision of an IEEE 802
standard. Since clauses, subclauses, tables, figures, etc., may be
renumbered when a standard is revised, a dated reference should be
used when citing specific items in a standard.

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Heather Flanagan (RFC Series Editor)
Sent: Wednesday, April 01, 2015 7:26 AM
To: [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

should

- -Heather

_______________________________________________
ieee-ietf-coord mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 17:32:29 +0000

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.

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

> Sent: mercredi 1 avril 2015 16:26
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 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.
> 
> >
> >
> >> 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
> 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-----
> 
> 

Date: Tue, 31 Mar 2015 14:37:52 +0000

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:
> https://standards.ieee.org/findstds/standard/802.15.4e-2012.html
>
> On 3/31/2015 10:18 AM, Brett, Patricia (PA62) wrote:
>> 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?
>>
>> 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
>> 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:
>>> 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]
>>>> 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
>>>>
>>>> On 3/30/2015 11:23 AM, Pascal Thubert (pthubert) wrote:
>>>>> 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
>>>>>
>>>>> 6tisch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>> --
>>>> email: [email-masked] | Skype: rstruik
>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>
>> --
>> email: [email-masked] | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>
>> 6tisch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tisch
>
>

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

Date: Tue, 31 Mar 2015 14:30:00 +0000

Just to be clear about the ISO/IEC approach, there are two places where
a dated reference might be specified. The first is simply within the
Normative References clause of a standard, where the specific edition to
which the standard refers can be cited when that is deemed appropriate.
For IETF documents, where a different document number is assigned for
each revised republication, the document number alone suffices. However,
for standards from other standards development organizations (SDOs), the
specific year of the edition usually is required when it is deemed
necessary to uniquely identify a specific edition of the cited standard.

The second place where a dated reference must be specified is when the
text of the standard cites a specific subclause of the referenced other
standard as normative text. In that case it is necessary to cite the
year of the referenced standard within the reference so that an
oversight during future editing of the citing standard does not
inadvertently reference the wrong clause of a revision of the referenced
standard, which could otherwise occur when the base edition of the
referenced standard is updated within the Normative References clause of
the citing standard.

A hypothetical example from the current documents shows the various
difficulties:

- Current normative references within 6tich documents would be to IEEE
802.15.4:2011 or to IEEE 802.15.4e:2012. Both would be listed in the
document's Normative References clause.

- A textual reference could take the generic form "IEEE 802.15.4", which
would be appropriate when referring to aspects that are common among all
editions and revisions to IEEE 802.15.4.

- A second form of textual reference would be to either "IEEE
802.15.4:2011" or "IEEE 802.15.4e:2012", which designates the specific
referenced source document but not a specific subclause within that
cited document.

- The third form of textual reference is to a specific subclause of a
specific document. In that case the reference form must include the
date, such as "IEEE 802.15.4e:2012, 4.7.2" to reference subclause 4.7.2
of IEEE 802.15.4e:2012. Including the date at the point of reference
ensures detection of future editing errors during maintenance of the
citing standard.

Note that the specific syntax of an undated or dated reference depends
on the SDO that is writing the standard. The above shows the required
syntax for ISO/IEC standards, in which the document number itself often
contains a hyphen ("-"), thus making the hyphen unusable as a date
separator. IETF and IEEE each have somewhat different requirements. The
rules about inclusion of spaces within the citation also differ by SDO.

Regards,
-Tom
=====
On 2015.03.31 05:21, Brian Haberman wrote:
> Pascal,
>
> On 3/31/15 2:58 AM, Pascal Thubert (pthubert) wrote:
>> Thanks a bunch Tom!
>>
>> I think that the case must be brought to the attention of the ADs,
>> CC'ing Brian. I'm unclear what the IETF best practice is for external
>> documents such as IEEE, but the IEC approach seems very well though
>> through. If we do not have such a detailed BCP, then this should be
>> exposed to the IAB.
> I am not aware of a BCP that discusses references to external documents.
>   Format-wise, that is the purview of the RFC Editor.  I am not sure why
> the IAB would care about references...
>
> I am generally leery of a blanket reference to the generic
> specification.  The WG has developed its solution based on a particular
> version of the IEEE specification, so I would expect to see references
> annotated by the year of the 15.4 spec.
>
> Regards,
> Brian
>

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

Dear all:

   -Tom

Tom,

     Thank you.

     Regards,

                            Diego Dujovne

      Tom,

      Thank you!

      Regards,

                             Diego Dujovne

      --

      DIEGO DUJOVNE

      --

      DIEGO DUJOVNE

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 1 Apr 2015 12:41:59 -0500

Hi, Heather,

On Wed, Apr 1, 2015 at 9:26 AM, Heather Flanagan (RFC Series Editor) <
[email-masked]> wrote:

> gets

That sounds like a fine idea.

If I might make a suggestion, you might talk with the IAB Liaison Oversight
program lead, Ralph Droms, and let him and the liaison managers chase down
which other SDOs ought to be involved.

Spencer

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Apr 2015 13:40:07 -0400

> On Apr 1, 2015, at 1:32 PM 4/1/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Heather:
> 

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

> <Mail Attachment.eml><Mail Attachment.eml><Mail Attachment.eml>_______________________________________________

---

From: ROBERT GROW <[email-masked]>
Date: Wed, 1 Apr 2015 13:53:29 -0700

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2015 16:28:35 +0000

This is incredibly useful Robert!

Thanks for every single word of it; it's all very clear, but yields additional need for clarification.

- 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?

- 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? 

- 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?

- 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?

Thanks again!!!

Pascal

> 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]
> 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
> 
> >> 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.
> >
> > 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
> >>
> >>
> >>> From: ieee-ietf-coord [mailto:[email-masked]] On
> >>> Behalf Of Heather Flanagan (RFC Series Editor)
> >>>> 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.
> >>>>
> >>>> 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
> >>>
> >>>
> >> <Mail Attachment.eml><Mail Attachment.eml><Mail
> >> Attachment.eml>_______________________________________________

---

From: ROBERT GROW <[email-masked]>
Date: Thu, 2 Apr 2015 14:10:13 -0700

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

> 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.
> 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 implicitl…

<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 answ…

<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.)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2015 12:43:47 +0000

Hello Robert (and Heather because some of the below is or you probably):

This was not my question. I was using 15.4 as an example but really my question relates to what comes implicitly with a reference. Like if we refer to 802.x do we mean that we work indifferently on all versions of x?
My questions illustrate a number of cases where the implicit is non obvious, and each question discussed a different implicit that really needs clarification so the reader understand what is really mandatory:

- 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? 
The point being that we want 6LoWPAN to work on all 802.15.4 versions and there is nothing in the tech specs that prevents it, and I'm concerned that the spec is not effectively saying that.

- 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?
I'll note that NORMATIVE seems to imply that we cannot live without this reference, and INFORMATIVE makes that a side information/. Does that change the meaning of the IEEE reference?  

Thanks for all!

Pascal

> Sent: jeudi 2 avril 2015 23:10
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms; Heather Flanagan (RFC Series Editor); Tom Phinney; ieee-ietf-
> [email-masked]
> 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
> 
> 
> <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.
> >
> <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
> >
> >
> >> Cc: Pascal Thubert (pthubert); Tom Phinney; Heather Flanagan (RFC
> >> Series Editor); [email-masked]
> >> 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
> >> 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
> >>
> >> becomes of RFCb that references RFCa after RFCa is deprecated and
> >> until RFC is deprecated.
> >>>>
> >> LATEST version of the standard and the sum of all amendments till
> >> now. This implies a different handling of the reference.
> >> 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
> >>>
> >>>>
> >> <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
> >>>>>> 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.
> >>>>>>> - The general expectation is that work at the IETF that depends
> >>>>>>> on an
> >>>>> IEEE
> >>>>>>> 802.15.4-2006) when that is the case, so as to implicitly
> >>>>>>> include new upcoming versions.
> >>>>>>
> >>>>>> And I'm sure that when there are clear version-dependencies,
> >>>>>> that's well known and the authors will handle that.
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Apr 2015 07:02:08 +0000

Dear all:

This flow has been dormant, and still 6TiSCH is expecting an answer on how to refer to IEEE specs in docs that are now passed last call.
To make that decision, 6TiSCH could use a better understanding of what it means NOT TO remove the dates when we do not have a clear dependency on a particular version of the IEEE standard, thus the questions below.
Can someone shed some light or are we just fully unclear?

Pascal

> From: Pascal Thubert (pthubert)
> Sent: vendredi 3 avril 2015 14:43
> To: 'ROBERT GROW'; Heather Flanagan (RFC Series Editor)
> Cc: Ralph Droms; Tom Phinney; [email-masked]
> Subject: RE: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
> 
> This was not my question. I was using 15.4 as an example but really my question
> relates to what comes implicitly with a reference. Like if we refer to 802.x do we
> mean that we work indifferently on all versions of x?
> My questions illustrate a number of cases where the implicit is non obvious, and
> each question discussed a different implicit that really needs clarification so the
> reader understand what is really mandatory:
> 
> The point being that we want 6LoWPAN to work on all 802.15.4 versions and
> there is nothing in the tech specs that prevents it, and I'm concerned that the
> spec is not effectively saying that.
> 
> I'll note that NORMATIVE seems to imply that we cannot live without this
> reference, and INFORMATIVE makes that a side information/. Does that change
> the meaning of the IEEE reference?
> 
> > Cc: Ralph Droms; Heather Flanagan (RFC Series Editor); Tom Phinney;
> > ieee-ietf- [email-masked]
> > 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:
> >
> > > Thanks for every single word of it; it's all very clear, but yields
> > > additional need
> > for clarification.
> > >
> > >               [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.
> > >
> > >               [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.
> > >
> > 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).
> > >
> > 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.
> > >
> > 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
> > >
> > >
> > >> 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-
> > >> 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
> > >> amendments before an additional amendment can be approved, unless
> > >> an extension to the rule is granted.)  This results in frequent
> > >> 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.
> > >> 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
> > >>
> > >>>>> From: ieee-ietf-coord [mailto:[email-masked]]
> > >>>>> On Behalf Of Heather Flanagan (RFC Series Editor)
> > >>>>> 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
> > >>>>>> Where it becomes dicey is when (as we should when we reference
> > >>>>>> a lengthy specification) we cite a specific section in order to
> > >>>>>> some such), but it's something that probably deserves mention
> > >>>>>> in any advice on how to do the references.
> > >>>>>>
> > >>>>>

---

From: "Das, Subir" <[email-masked]>
Date: Thu, 9 Apr 2015 12:22:16 +0000

Pascal,
As I mentioned in the 6tisch mailing list, we should refer  to as "IEEE Std. 802.15.4-2015" assuming that IEEE-SA will publish the document  before IESG approves it and 6tisch WG members can look at the Standard. Otherwise, we should refer to two standards: "IEEE Std. 802.15.4-2011" and "IEEE Std. 802.15.4e-2012".  OTH, if the IETF document clearly says that there are no dependencies on a specific version of the IEEE Standard and 6tisch protocol will interoperate irrespective of  a particular MAC version, then we should be ok.   What I have read so far in 6tisch mailing list is that some folks think that there are some dependencies and other do not.

Let me also ask few clarifying questions:
- What are the benefits of not mentioning the year of publication or  what will we lose if we mention the publication year?
- How do we know what is coming in future versions? With my experience in IEEE, I have seen things get deleted and added during revision of a standard.

-Subir

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 09, 2015 3:02 AM
To: ROBERT GROW; Heather Flanagan (RFC Series Editor)
Cc: Tom Phinney; Ralph Droms; [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

Dear all:

Pascal

> This was not my question. I was using 15.4 as an example but really my
> question relates to what comes implicitly with a reference. Like if we
> refer to 802.x do we mean that we work indifferently on all versions of x?
> My questions illustrate a number of cases where the implicit is non
> obvious, and each question discussed a different implicit that really
> needs clarification so the reader understand what is really mandatory:
>
> 802.15.4-2003", October 2003.
> Does it mean that the 6LoWPAN is currently not defined on the 2006 and
> the
> The point being that we want 6LoWPAN to work on all 802.15.4 versions
> and there is nothing in the tech specs that prevents it, and I'm
> concerned that the spec is not effectively saying that.
>
> 802.15.4-2006", October 2006.
> to various levels of the MAC/PHY?
> I'll note that NORMATIVE seems to imply that we cannot live without
> this reference, and INFORMATIVE makes that a side information/. Does
> that change the meaning of the IEEE reference?
>
> that reference it mean that 2006 and 2003 are implicitly supported not supported?
>
> - 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?
>
> - 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?
>
> Thanks for all!
>
> Pascal
>
>
> > 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
> > > Thanks for every single word of it; it's all very clear, but
> > > yields additional need
> > for clarification.
> > >
> > <RMG> Seems like the reference should probably be without year.
> > Best to check with an 802.15 expert on any potential problems.  With
> > 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.
> >
> > > Does the INFORMATIVE change anything to the applicability of the
> > > RFC to
> > 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.
> > >
> > 10BASE-5 is still in the current revision project, it will continue
> > to be a conformant speed and media option for Ethernet.
> > 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
> > 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
> > <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
> > 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?
> >
> > ignorance about both 802.15.4 and TSCH.  If referencing 2011, I
> > would probably add an informative note that the RFC relies on the
> > would be aware of the level of detail we have been discussing and
> > the subtlety that amendments become part of the base standard when
> > >> corrigenda.  It is also possible to withdraw an IEEE standard
> > >> (less common.  Superseded and withdrawn standards remain available.
> > >>
> > >> corrigenda to a standard becomes part of that standard.  So,
> > >> today, a reference to IEEE Std
> > >> 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
> > >> 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
> > >> 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
> > >> amendment even though the amendment is technically part of the
> > >> base standard (a kindness to readers of the RFC).
> > >>
> > >> 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.
> > >> 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.
> > >>>
> > >>> metropolitan area networks--Part 15.4: Low-Rate Wireless
> > >>> Personal Area Networks
> > >>> (LR-WPANs)
> > >>>
> > >>> - Ralph
> > >>>
> > >>>>
> > >> 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
> > >>>>> From: ieee-ietf-coord
> > >>>>> [mailto:[email-masked]]
> > >>>>>> 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 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.
> > >>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> 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.
> > >>>>>>
> > >>>>>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Apr 2015 08:32:06 -0400

> On Apr 9, 2015, at 8:22 AM 4/9/15, Das, Subir <[email-masked]> wrote:
> 
> Pascal,

Seems like this issue is the first thing to sort out - what is the consensus in the WG about dependencies.  Then we can figure out exactly how to write the reference to reflect those dependencies.

- Ralph

>>>> amendment

---

From: Pat Kinney <[email-masked]>
Date: Thu, 9 Apr 2015 07:44:24 -0500

Firstly, I agree to Bob's proposal.

Secondly, Subir raises valid points. 6tisch is not a typical IETF specification, rather than residing in L3, L4, or above, it resides in L2 and has close ties to 802.15.4.  One issue in using the dated version is that corrections and enhancements from later versions intended to aid 6tisch will be left out.

The IEEE 802.15.4 revision has now entered the Sponsor Ballot phase. Therefore, I believe that the revision is sufficiently on a schedule to allow the WG to understand in a timely manner, the TSCH aspects of the standard.

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 9, Apr2015, at 7:22, Das, Subir <[email-masked]> wrote:

Pascal,

-Subir

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 09, 2015 3:02 AM
To: ROBERT GROW; Heather Flanagan (RFC Series Editor)
Cc: Tom Phinney; Ralph Droms; [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

Dear all:

Pascal

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Apr 2015 09:50:45 -0400

> Secondly, Subir raises valid points. 6tisch is not a typical IETF
> specification, rather than residing in L3, L4, or above, it resides in
> L2 and has close ties to 802.15.4.  One issue in using the dated
> version is that corrections and enhancements from later versions
> intended to aid 6tisch will be left out.
>
> The IEEE 802.15.4 revision has now entered the Sponsor Ballot phase.
> Therefore, I believe that the revision is sufficiently on a schedule
> to allow the WG to understand in a timely manner, the TSCH aspects of
> the standard.

One thing that some documents have done with this sort of thing is to
use the dated reference, but to state something like this in the text
of the document:

"This document is expected to be compatible with future versions of
IEEE Std. 802.15.4, and readers should consult the version of that
document that is current at the time.  The version current at this
writing, and for which compatibility has been confirmed, is IEEE Std.
802.15.4-2015 [reference]."

Barry

---

From: Geoff Thompson <[email-masked]>
Date: Wed, 1 Apr 2015 10:34:10 -0700

Pat/Heather-

Is there a pointer to RFC 7241 in RFC 7322, Section 4.8.66?
If not, perhaps one should be added on the next iteration.

Geoff Thompson

> On Apr 1, 2015, at 9:20 AMPDT, Pat Thaler <[email-masked]> wrote:
> 
> gGSROmURw4+cgzk0qTDApiXDz3PbsJ79LbEAZq2KCQFTRF7/tRfMvWMUey2lTdbG

---

From: Pat Thaler <[email-masked]>
Date: Thu, 9 Apr 2015 20:46:35 +0000

- What are the benefits of not mentioning the year of publication or  what will we lose if we mention the publication year?
Benefits of using an undated reference: You are always referring to the latest version of the spec - including the things we add in future years.

Disadvantage of an undated reference: clause/subclause numbering may change. If for example, you have a reference to 6.5.1.2, in a future version of the standard a subclause may have been inserted so the material you referenced is now 6.6.1.3 and your reference points to the wrong spot. So if you have references that point to a particular subclause, then you need a dated reference.

- How do we know what is coming in future versions? With my experience in IEEE, I have seen things get deleted and added during revision of a standard.
You don't know. In IEEE 802 standards, we rarely remove anything or make incompatible new additions.  It would be more typical to put in a note that said that a feature or part of the standard wasn't recommended for new designs.

Generally it would be better to use undated references unless you absolutely need to make reference to specific parts of the standard by Clause or subclause number. (That is IEEE's reference policy - I haven't seen any Clause numbers change, e.g. Clause 5 become Clause 6 because we inserted a new Clause 5 - if we deleted a Clause we would probably put in a note that said it was no longer used and, at least in IEEE 802.1 and IEEE 802.3 we always add new Clauses to the end. Subclause numbers do change with revisions.)

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Das, Subir
Sent: Thursday, April 09, 2015 5:22 AM
To: Pascal Thubert (pthubert); ROBERT GROW; Heather Flanagan (RFC Series Editor)
Cc: Tom Phinney; Ralph Droms; [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

Pascal,

-Subir

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 09, 2015 3:02 AM
To: ROBERT GROW; Heather Flanagan (RFC Series Editor)
Cc: Tom Phinney; Ralph Droms; [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

Dear all:

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Apr 2015 09:31:02 +0000

Hello Pat:

This is the piece that is about clear. What is less clear is the answer to the set of questions I am asking below, taking the example of 6LoWPAN and 6TiSCH.
My questions have implications like whether we need to update an RFC that has a dated reference when the IEEE 802 standard is revised. 
Pat Kinney's recommendation to 6TiSCH is to remove dates, and I'm in the process of documenting to the group what if we do, what if we don't.
I attached my unanswered questions, as I already posted them to this most, for your convenience.

Thanks for your help!

Pascal

> From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of
> Pat Thaler
> Sent: mercredi 1 avril 2015 18:21
> To: Heather Flanagan (RFC Series Editor); [email-masked]
> When an IEEE 802 standard is revised, it normally retains the same number and
> the date is updated. Therefore, IEEE 802 standards are dated with the year of
> approval, e.g., IEEE Std 802.1Q(TM)-2011.
> There are two ways of referencing IEEE 802 standards: undated and dated
> references. IEEE 802 practice allows undated reference to be used when
> referencing a whole standard. An undated reference indicates that the most
> recent version of the standard should be used. A dated reference refers to a
> specific revision of an IEEE 802 standard. Since clauses, subclauses, tables,
> figures, etc., may be renumbered when a standard is revised, a dated reference
> should be used when citing specific items in a standard.
> 
> Regards,
> Pat
> 

Subject: RE: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: ROBERT GROW <[email-masked]>, "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Cc: Ralph Droms <[email-masked]>, Tom Phinney <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 3 Apr 2015 12:42:56 +0000

Thanks for all!

Pascal

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 14 Apr 2015 15:45:03 -0700

> 802.15.4-2015 [reference]."

I've been following along to see if the thread came to any final
conclusions; it seems to me that this isn't actually a question of how
to properly cite an IEEE document. You have a technical question here:
when someone is implementing this spec, what supporting material should
the reader be able to reference? If they need to be aware of something
specific to a particular revision of an IEEE standard, then point to
that very specific revision.  If they need to be aware of the IEEE in
its current state (whatever that is) then reference that.  If things are
enough in flux that you aren't entirely sure, then Barry's
recommendation above makes sense.

As a side note, I will be making sure that the appropriate pointers to
RFC 7241 will be added to the RFC Style Guide.

- -Heather

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Apr 2015 06:33:51 +0000

Hello Heather:

Actually this thread only appeared dormant. I consulted with other parties, and got to the following conclusions:

1) Pat's mail, attached, is a reference for the meaning of undated references. 

The best practice should be to use undated references for IEEE specs; that is, unless there is a compelling need to cite a particular section, in which case the dated reference should be added too.
We can have a disclaimer saying that compatibility with future specification is expected but not guaranteed. If a compatibility issue arises, there are mechanisms to solve it, so it is at worse a temporary issue. 
OTOH, an RFC with a dated IEEE reference means that the RFC only applies to that specific IEEE specification. Now, that is trouble (see below).

2) For my 4 questions (in the other attached mail), here's what I gathered:

- RFC 4944 (6LoWPAN) is not defined on current IEEE specs. We need to publish something new (update, errata?) to extend 6LoWPAN on 2006, 2011, and next versions of 802.15.4 -> cc'ing 6lo chairs.
- RFC 6282 probably has the same problem, though in that case, the reference to a dated IEEE spec is not NORMATIVE. Whether NORMATIVE makes any difference there is a question to you, Heather.
- If we publish today an RFC that references IEEE802.15.4 with no date, it will effectively reference 2011 plus current amendments, until IEEE ships the new version, which is expected by the end of this year. This means that unless specified otherwise, the RFC is *not* applicable to the 2006 and 2003 versions.
- We have to debate within 6TiSCH if people actually expect 15.4e to work on 802.15.4:2006, but the IEEE does not provide any guarantee that it does, so this should be exactly what we need.

Anything wrong in any of this? 

My take is that I need to communicate with:
- 6lo to get the 6LoWPAN specs updated (to undated, plus explicit support of all backwards versions of IEEE802.15.4)
- 6tisch to confirm we remove the date in charter and all specs

Again, anything wrong in any of this?

Cheers,

Pascal

> Heather Flanagan (RFC Series Editor)
> Sent: mercredi 15 avril 2015 00:45
> I've been following along to see if the thread came to any final conclusions; it
> seems to me that this isn't actually a question of how to properly cite an IEEE
> document. You have a technical question here:
> when someone is implementing this spec, what supporting material should the
> reader be able to reference? If they need to be aware of something specific to a
> particular revision of an IEEE standard, then point to that very specific revision.
> If they need to be aware of the IEEE in its current state (whatever that is) then
> reference that.  If things are enough in flux that you aren't entirely sure, then
> Barry's recommendation above makes sense.
> 
> As a side note, I will be making sure that the appropriate pointers to RFC 7241
> will be added to the RFC Style Guide.
> 
> - -Heather
> 
> iQEcBAEBCAAGBQJVLZhvAAoJEER/xjINbZoGED8H/0aZNHnWjrMLwdjX7bPayl4W
> b64zvx9bqk/UtQ9CyA5iHqAHwfyt7qGvV/2BBvAZ2uzQAuhsfY10e42a5XqMn2J9
> SM2pUiQfTlwJ6wZojlxshBnidZQlWYoRuyqfjkc/ofcgN0v3WwzCVcVvwzuMkCzf
> BREuAj7ojv8JsBubQTHuQlr8n6tM4oR+5z0CYmWUmkHbTJ3wrszw6xl/2HCRgCjY
> K5ib3I2iqU2G9oaCKwuCwmXDATQJxvhxkmWlu06LwE4jLoFGiEDtwmWfFji2iYCd
> HIOQVsO55uzrVgAgUAk3qc81uBMyEwIG6ebUi/Xh8YPcYg7Ar03JbM56BM14SbE
> =
> =zuk2

Subject: RE: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
From: Pat Thaler <[email-masked]>
To: "Das, Subir" <[email-masked]>, "Pascal Thubert (pthubert)" <[email-masked]>, ROBERT GROW <[email-masked]>, "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Cc: Tom Phinney <[email-masked]>, Ralph Droms <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 9 Apr 2015 20:46:35 +0000

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Das, Subir
Sent: Thursday, April 09, 2015 5:22 AM
To: Pascal Thubert (pthubert); ROBERT GROW; Heather Flanagan (RFC Series Editor)
Cc: Tom Phinney; Ralph Droms; [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

Pascal,

-Subir

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 09, 2015 3:02 AM
To: ROBERT GROW; Heather Flanagan (RFC Series Editor)
Cc: Tom Phinney; Ralph Droms; [email-masked]
Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs

Dear all:

Pascal

Thanks for all!

Pascal

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 20 Apr 2015 09:09:37 -0700

On 4/14/15 11:33 PM, Pascal Thubert (pthubert) wrote:
> Hello Heather:
>
> Actually this thread only appeared dormant. I consulted with other
> parties, and got to the following conclusions:
>
> The best practice should be to use undated references for IEEE specs;
> that is, unless there is a compelling need to cite a particular
> section, in which case the dated reference should be added too. We
> can have a disclaimer saying that compatibility with future
> specification is expected but not guaranteed. If a compatibility
> issue arises, there are mechanisms to solve it, so it is at worse a
> temporary issue. OTOH, an RFC with a dated IEEE reference means that
> the RFC only applies to that specific IEEE specification. Now, that
> is trouble (see below).
>
> - RFC 4944 (6LoWPAN) is not defined on current IEEE specs. We need to
> publish something new (update, errata?) to extend 6LoWPAN on 2006,
> 2011, and next versions of 802.15.4 -> cc'ing 6lo chairs. - RFC 6282
> probably has the same problem, though in that case, the reference to
> a dated IEEE spec is not NORMATIVE. Whether NORMATIVE makes any
> difference there is a question to you, Heather. - If we publish today
> an RFC that references IEEE802.15.4 with no date, it will effectively
> reference 2011 plus current amendments, until IEEE ships the new
> version, which is expected by the end of this year. This means that
> unless specified otherwise, the RFC is *not* applicable to the 2006
> and 2003 versions. - We have to debate within 6TiSCH if people
> actually expect 15.4e to work on 802.15.4:2006, but the IEEE does not
> provide any guarantee that it does, so this should be exactly what we
> need.
>
> My take is that I need to communicate with: - 6lo to get the 6LoWPAN
> specs updated (to undated, plus explicit support of all backwards
> versions of IEEE802.15.4) - 6tisch to confirm we remove the date in
> charter and all specs
>

This all seems fine to me.

- -Heather

> 
> Cheers,
>
> Pascal
>
>
>> -----Original Message----- From: ieee-ietf-coord
>> [mailto:[email-masked]] On Behalf Of Heather
>> Flanagan (RFC Series Editor) Sent: mercredi 15 avril 2015 00:45 To:
>> [email-masked] Subject: Re: [ieee-ietf-coord] On
>> references to IEEE standards in IETF RFCs
>>
>>
>>>>> Secondly, Subir raises valid points. 6tisch is not a typical
>>>>> IETF specification, rather than residing in L3, L4, or above,
>>>>> it resides in L2 and has close ties to 802.15.4.  One issue
>>>>> in using the dated version is that corrections and
>>>>> enhancements from later versions intended to aid 6tisch will
>>>>> be left out.
>>>>>
>>>>> The IEEE 802.15.4 revision has now entered the Sponsor Ballot
>>>>> phase. Therefore, I believe that the revision is sufficiently
>>>>> on a schedule to allow the WG to understand in a timely
>>>>> manner, the TSCH aspects of the standard.
>>>>
>>>> One thing that some documents have done with this sort of thing
>>>> is to use the dated reference, but to state something like this
>>>> in the text of the document:
>>>>
>>>> "This document is expected to be compatible with future
>>>> versions of IEEE Std. 802.15.4, and readers should consult the
>>>> version of that document that is current at the time.  The
>>>> version current at this writing, and for which compatibility
>>>> has been confirmed, is IEEE Std. 802.15.4-2015 [reference]."
>>>>
>>>>
>
> conclusions; it seems to me that this isn't actually a question of
> how to properly cite an IEEE document. You have a technical question
> here: when someone is implementing this spec, what supporting
> material should the reader be able to reference? If they need to be
> aware of something specific to a particular revision of an IEEE
> standard, then point to that very specific revision. If they need to
> be aware of the IEEE in its current state (whatever that is) then
> reference that.  If things are enough in flux that you aren't
> entirely sure, then Barry's recommendation above makes sense.
>
> As a side note, I will be making sure that the appropriate pointers
> to RFC 7241 will be added to the RFC Style Guide.
>
> -Heather
>
>>
>> _______________________________________________ ieee-ietf-coord
>> mailing list [email-masked]