Subject: Re: [6tisch] removing the 'e'

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

+1

We do not need to wait, though. We can ask the 6TiSCH I-G at the IEEE to make such an evaluation based on the current WIP...

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Subir Das
Sent: mardi 31 mars 2015 19:20
To: Brian Haberman
Cc: [email-masked]
Subject: Re: [6tisch] removing the 'e'

Agree with what Brian said here. I think 802.15.4- 2011 is more appropriate unless 802.15.4 - 2015 is published  by the IEEE-SA before the RFC is published. If we choose to do 802.15.4-2015, then it would be good if WG discusses and understands the impact to IETF document(s), if there is any.
-Subir

On Tue, Mar 31, 2015 at 8:21 AM, Brian Haberman <[email-masked]<mailto:[email-masked]>> 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

>
> Cheers,
>
> Pascal
>
> From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tom
> Phinney Sent: lundi 30 mars 2015 23:57 To: [email-masked]<mailto:[email-masked]> 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
> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/6tisch
>

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 12:24:04 +0000

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:[email-masked]]
> Sent: mardi 31 mars 2015 19:21
> To: Pascal Thubert (pthubert); [email-masked]
> 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:[email-masked]] On Behalf Of Brian Haberman Sent:
> >> mardi 31 mars 2015 14:22 To: [email-masked] Subject: Re: [6tisch]
> >> removing the 'e'
> >>
> >> Pascal,
> >>
> >>> 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...
> >>
> >> 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:[email-masked]] On Behalf Of Tom
> >>> Phinney Sent: lundi 30 mars 2015 23:57 To: [email-masked]
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> For undated references, the latest edition of the referenced
> >>> document (including any amendments) applies.
> >>>
> >>> 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).
> >>>
> >>> available as required - the authors or publishers will be expected
> >>> to make available such documents on request, c) the authors or
> >>> 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 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
> >>> demonstrates proper dated-citation usage, including usage of the
> >>> date only as necessary to reduce ambiguity:
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> [email-masked] https://www.ietf.org/mailman/listinfo/6tisch
> >>>

---

From: Rene Struik <[email-masked]>
Date: Wed, 01 Apr 2015 10:43:46 -0400

Hi Pascal:

If I understand IETF process well, IETF groups usually make their own 
assessments and do not delegate this to external bodies (6TiSCH I-G or 
otherwise).

BTW - I raised this as topic for the December 19, 2014 6TiSCH security 
call, see 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02815.html. For 
minutes of that call, see 
https://bitbucket.org/6tisch/meetings/wiki/141219_webex.

Best regards, Rene

On 4/1/2015 5:24 AM, Pascal Thubert (pthubert) wrote:
>
> +1
>
> We do not need to wait, though. We can ask the 6TiSCH I-G at the IEEE 
> to make such an evaluation based on the current WIP...
>
> Cheers,
>
> Pascal
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Subir Das
> *Sent:* mardi 31 mars 2015 19:20
> *To:* Brian Haberman
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] removing the 'e'
>
> Agree with what Brian said here. I think 802.15.4- 2011 is more 
> appropriate unless 802.15.4 - 2015 is published  by the IEEE-SA before 
> the RFC is published. If we choose to do 802.15.4-2015, then it would 
> be good if WG discusses and understands the impact to IETF 
> document(s), if there is any.
>
> -Subir
>
> On Tue, Mar 31, 2015 at 8:21 AM, Brian Haberman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Pascal,
>
> > From: 6tisch [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Tom
> <mailto:[email-masked]> Subject:
> > [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/6tisch>
> >
>
>
> [email-masked] <mailto:[email-masked]>
> [email-masked]

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

---

From: Rene Struik <[email-masked]>
Date: Wed, 01 Apr 2015 11:01:21 -0400

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

==

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 16:05:13 +0000

Hello René:

We are not looking at interoperable MACs, but at MACs upon which our specifications operate as expected. 802.11AC is not compatible with 802.11A, but we can do the same IP and IPv6 over both.

The silos do epsilons, because they can, they are in a closed world and they want some optimization, additional security, you name it.
But then again we are not a silo and we are not defining the layers beneath us. We pick the IEEE standards as they come, and we design for them.

So my question to you is: Do the incompatibility that you are aware of affect 6LoWPAN in a fashion that RFC4944 would not work anymore in one of the listed versions? 

Cheers,

Pascal

> From: Rene Struik [mailto:[email-masked]]
> Sent: mercredi 1 avril 2015 17:01
> To: Pascal Thubert (pthubert); Brian Haberman; [email-masked]
> 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.
> 
> 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.
> 
> 
> > 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.
> > - 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.
> >
> > - 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
> >
> >>> 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.
> >>
> >>> 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.
> >>> 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.
> >> 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
> >>
> >>>> documents. Format-wise, that is the purview of the RFC Editor.  I
> >>>> am not sure why the IAB would care about references...
> >>>>
> >>>>> 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 related text from the ISO/IEC editing directives with regard
> >>>>> to use of Normative References is:
> >>>>>
> >>>>> 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.
> >>>>> 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.
> >>>>>
> >>>>> following documents, in whole or in part, are normatively
> >>>>> document (including any amendments) applies."
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 6tisch mailing
> >>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/6tisch
> >>>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 16:40:59 +0000

I'm not aware of such process at the IETF, René. Can you please produce a reference?

I'll note that in any fashion, the I-G members are also individual contributors to 6TiSCH and registered to the mailing list.
Cross participation has been an effective mechanism to avoid problems before they have a chance to show up, it is quite typical between IEEE and IETF, and it saves a lot of liaison hassle.

I-G members happen to have access to the specs in question and can:

1)      Tell us in advance if a change would impact us so we can try to be agnostic (e.g. extend the 6top data model)

2)      Influence the IEEE process to avoid such an impact in the first place

This looks precisely like the reason why we formed that I-G, which Pat has been representing to us so far. I have attended I-G meetings during IEEE as well.

Cheers,

Pascal

From: Rene Struik [mailto:[email-masked]]
Sent: mercredi 1 avril 2015 16:44
To: Pascal Thubert (pthubert); Subir Das; Brian Haberman
Cc: [email-masked]
Subject: Re: [6tisch] removing the 'e'

Hi Pascal:

If I understand IETF process well, IETF groups usually make their own assessments and do not delegate this to external bodies (6TiSCH I-G or otherwise).

BTW - I raised this as topic for the December 19, 2014 6TiSCH security call, see http://www.ietf.org/mail-archive/web/6tisch/current/msg02815.html. For minutes of that call, see https://bitbucket.org/6tisch/meetings/wiki/141219_webex.

Best regards, Rene

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Subir Das
Sent: mardi 31 mars 2015 19:20
To: Brian Haberman
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] removing the 'e'

On 3/31/15 2:58 AM, Pascal Thubert (pthubert) wrote:
> CC'ing Brian. I'm unclear what the IETF best practice is for external

Regards,
Brian

> a footnote "To be published.", and full title. The year of
> number shall be followed by the indication "(all parts)" and the
> available as required - the authors or publishers will be expected to
> The list shall be introduced by the following wording: "The following
> amendments) applies."

6tisch mailing list

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Wed, 01 Apr 2015 13:54:43 -0400

Hi Pascal:

Once again, the question you put forward to the mailing list was whether 
we should have "blind trust" based on an external spec on which the ink 
is not dry yet (and to which lots of ink may still be applied).

IETF process is described in, e.g., RFC 7282 - On Consensus and Humming 
in the IETF (June 2014). To me, this implies that IETF does its own due 
diligence and decides for itself, rather than delegating its assessments 
to the wisdom of external bodies. As you will appreciate, I did not 
suggest that receiving data points and analysis from such external 
bodies would not be welcome: au contraire! I think this would be great 
input to an assessment by an IETF group. Ultimately, though, an IETF 
group should make up its own mind; the external body may wish, but 
should not do this for them. This touches on autonomy of SDOs for their 
own decision making. {Please correct me if I misunderstand this and IETF 
would have an external master.}

I am not sure why we have this discussion or why a simple response to 
the question you put forward provokes so much debate.

Best regards, Rene

On 4/1/2015 12:40 PM, Pascal Thubert (pthubert) wrote:
>
> I’m not aware of such process at the IETF, René. Can you please 
> produce a reference?
>
> I’ll note that in any fashion, the I-G members are also individual 
> contributors to 6TiSCH and registered to the mailing list.
>
> Cross participation has been an effective mechanism to avoid problems 
> before they have a chance to show up, it is quite typical between IEEE 
> and IETF, and it saves a lot of liaison hassle.
>
> 1)Tell us in advance if a change would impact us so we can try to be 
> agnostic (e.g. extend the 6top data model)
>
> 2)Influence the IEEE process to avoid such an impact in the first place
>
> This looks precisely like the reason why we formed that I-G, which Pat 
> has been representing to us so far. I have attended I-G meetings 
> during IEEE as well.
>
> Cheers,
>
> Pascal
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* mercredi 1 avril 2015 16:44
> *To:* Pascal Thubert (pthubert); Subir Das; Brian Haberman
> *Cc:* [email-masked]
>     We do not need to wait, though. We can ask the 6TiSCH I-G at the
>     IEEE to make such an evaluation based on the current WIP...
>
>     Cheers,
>
>     Pascal
>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     appropriate unless 802.15.4 - 2015 is published  by the IEEE-SA
>     before the RFC is published. If we choose to do 802.15.4-2015,
>     then it would be good if WG discusses and understands the impact
>     to IETF document(s), if there is any.
>
>     -Subir
>
>     documents.
>     particular
>     document
>     standard
>     with
>     that
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2015 19:59:13 +0000

The note I proposed to add the the reference, Rene, was not blind trust. Please re read it carefully.

In the meantime, we are working on the generic problem of forward looking references with the RFC editor, and for all I know advice will be asked to the IAB for their role in liaison.

Cheers,
Pascal

Le 1 avr. 2015 à 19:54, Rene Struik <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal:

Once again, the question you put forward to the mailing list was whether we should have "blind trust" based on an external spec on which the ink is not dry yet (and to which lots of ink may still be applied).

IETF process is described in, e.g., RFC 7282 - On Consensus and Humming in the IETF (June 2014). To me, this implies that IETF does its own due diligence and decides for itself, rather than delegating its assessments to the wisdom of external bodies. As you will appreciate, I did not suggest that receiving data points and analysis from such external bodies would not be welcome: au contraire! I think this would be great input to an assessment by an IETF group. Ultimately, though, an IETF group should make up its own mind; the external body may wish, but should not do this for them. This touches on autonomy of SDOs for their own decision making. {Please correct me if I misunderstand this and IETF would have an external master.}

I am not sure why we have this discussion or why a simple response to the question you put forward provokes so much debate.

Best regards, Rene

On 4/1/2015 12:40 PM, Pascal Thubert (pthubert) wrote:
I’m not aware of such process at the IETF, René. Can you please produce a reference?

I’ll note that in any fashion, the I-G members are also individual contributors to 6TiSCH and registered to the mailing list.
Cross participation has been an effective mechanism to avoid problems before they have a chance to show up, it is quite typical between IEEE and IETF, and it saves a lot of liaison hassle.

Cheers,

Pascal

Hi Pascal:

Best regards, Rene

Cheers,

Pascal

Regards,
Brian

6tisch mailing list

--