Re: [6tisch] removing the 'e'

[Rene Struik <[e-mail]>]

Hi Pascal:

While ideally the below holds, this is not the case with 802.15.4 (802.15.4-2003, vs. 802.15.4-2006, vs. 802.15.4-2011), nor do I expect this to hold for draft 802.15.4rev or whatever standard would result from this. Please see some concrete data point re incompatibility of 802.15.4-2003 vs. 802.15.4-2006 below.

[excerpt of 802.15.4-2006, clause 7.5.8.2.3, Step b)]
b) If the Security Enabled subfield of the Frame Control field of the frame to be unsecured is set to one and the Frame Version subfield of the Frame Control field of the frame to be unsecured is set to zero, the procedure shall set the unsecured frame to be the frame to be unsecured and return with the
unsecured frame, the security level, the key identifier mode, the key source, the key index, and a status of UNSUPPORTED_LEGACY.

One of the problems is that implementations that claim to use 802.15.4 hardly ever implement a version of the specification as is, despite marketing this as such. Often, specifications are "based on" 802.15.4 (plus or minus some epsilon, where epsilon is strictly larger than zero). This seems to include ZigBee and ISA SP100.

Rene

==

The general expectation is that anything that depends on an IEEE standard works the same on the newer version of that standard that gets published. So we are supposed to reference the standard not the year. But as you point out this leave a lot in the vague. Including the starting point from which the reference applies, which for us means the day 802.15.4e was published, because implicitly 4e was included in the 802.15.4 reference from that day on.


On 4/1/2015 8:24 AM, Pascal Thubert (pthubert) wrote:
> Hello Brian:
>
>> To me, the above would argue that referencing 802.15.4-2015 makes it clear which version of that spec is needed to support the 6tisch spec.
> Whatever we do, we want to make sure that we do not lock 6TiSCH to a particular version of IEEE standards in such a fashion that complying products are stuck to that version.
>
> The general expectation is that anything that depends on an IEEE standard works the same on the newer version of that standard that gets published. So we are supposed to reference the standard not the year. But as you point out this leave a lot in the vague. Including the starting point from which the reference applies, which for us means the day 802.15.4e was published, because implicitly 4e was included in the 802.15.4 reference from that day on.
>
> Even if the MAC becomes incompatible with earlier versions, or PHYs are added or deprecated, history shows that the general expectation above tends to stand true, and the interop problem, if any, generally occur at the MAC/PHY layers if at all.  For instance, the IEEE was free to upgrade, say, Ethernet bridging from spanning tree to L2R, and that was transparent to IP as should be. Yes, IP has dependencies on Ethernet, but they are loose enough to allow transparent upgrades on both layers.
>
> I have been reviewing how the IETF has proceeded in the past, and found that by leaving it to the WGs we have been quite inconsistent:
>
> - RFC894 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 a EUI-64 tuto, 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 mesh header is 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.
> Does it mean that we cannot compress IPv6 on the 2011 version?
>
> - https://tools.ietf.org/html/draft-rfc-editor-rfc2223bis is mostly a formatting guide but does not enter such consideration.
>
> - BCP 97 and RFC4897 do not discuss documents that are sourced outside the IETF; they are about procedures and warning that a down-ref exists and when that can be acceptable.
>
> All in all, we have ignored the problem, been quite creative, and mostly placed ourselves in some twilight zone if not a corner; there is a need clarify what our position should be; and I do not see that the RFC editor should be responsible of producing that general practice. I understand that this is out of scope for the IAB.
>
> I'll be asking around, e.g. taking the generic question to IEEE-IETF coordination see if there is a position that we are unaware of. So far my take is that we should reference the generic standard with a carefully written note that explain from which version of the standard we start to operate, and that we expect but cannot guarantee compatibility with versions of the standard published after the date of the RFC.
>
> Makes sense?
>
> Pascal
>
>> -----Original Message-----
>> From: Brian Haberman [mailto:[e-mail]]
>> Sent: mardi 31 mars 2015 19:21
>> To: Pascal Thubert (pthubert); [e-mail]
>> Subject: Re: [6tisch] removing the 'e'
>>
>> Hi Pascal,
>>
>> On 3/31/15 8:57 AM, Pascal Thubert (pthubert) wrote:
>>> Hello Brian:
>>>
>>> Adding the year is apparently not the expectation of the group that
>>> owns the reference that we make. I mentioned the IAB because of a best
>>> practice question; I'm asking if there needs to be a best practice at
>>> the IETF like there is at IEC as well-documented in Tom Phinney's
>>> email, and if so, then who should write it? I take from your email
>>> that you do not think there is such a need.
>> I do not think there is a need for yet another set of rules.  We should be
>> exercising good judgement and doing what is right for each situation.
>>
>> I am still confused by your mention of the IAB.  The IAB has nothing to do with
>> BCPs related to IETF stream documents.
>>
>>> Regardless, there appears to be a tension that 6TiSCH needs to
>>> resolve, I really like the way IEC did it, and I would not mind doing
>>> the exact same: If you have a dependency on a text that is particular
>>> to one version, be specific, else be generic.
>> Then that is an issue for 6tisch to resolve collectively.
>>
>>> So far, 6TiSCH does not have a dependency on a particular version, so
>>> we could keep it generic with 802.15.4, with a mention that a part of
>>> the overall interoperability depends on the MAC and PHY layers and is
>>> independent on 6TiSCH.
>> If we were to assume that:
>>
>> 1. IEEE publishes 802.15.4-2015
>> 2. the 6tisch protocol spec is published *after* 802.15.4-2015 3. the published
>> 6tisch protocol references generically 802.15.4
>>
>> what happens to the IETF spec if the IEEE publishes 802.15.4-2017, that spec
>> overhauls the 15.4e behavior, and renders the 6tisch spec useless?
>>
>> To me, the above would argue that referencing 802.15.4-2015 makes it clear
>> which version of that spec is needed to support the 6tisch spec.
>>
>> The above may not be an issue given I am still coming up to speed on all aspects
>> of 6tisch.
>>
>> Regards,
>> Brian
>>
>>> My reading is that we'd leave it up to manufacturers to select the
>>> MAC/PHY version that they like, and they have their own reasons to
>>> pick one; the caveat is that they might not interop with one another
>>> at the IEEE layers, but should that be our problem?
>>>
>>> At least I understand that we need to be specific for the plug test.
>>> And that we can resolve within the WG.
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message----- From: 6tisch
>>>> [mailto:[e-mail]] On Behalf Of Brian Haberman Sent:
>>>> mardi 31 mars 2015 14:22 To: [e-mail] Subject: Re: [6tisch]
>>>> removing the 'e'
>>>>
>>>> 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
>>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>> From: 6tisch [mailto:[e-mail]] On Behalf Of Tom
>>>>> Phinney Sent: lundi 30 mars 2015 23:57 To: [e-mail]
>>>>> Subject: Re: [6tisch] removing the 'e'
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ 6tisch mailing list
>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch


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