<no chair hat> Little thought exercise.
Let's assume we decide draft-minimal contains an undated reference to IEEE802.15.4, and is published in 2015. In 2016, company foo builds and sells products based on draft-ietf-6tisch-minimal. Company foo goes to a third-party lab which certifies conformance to draft-ietf-6tisch-minimal. Everything is great, tens of thousands of networks go out the door. Company foo is happy. Now IEEE802.15.4-2018 is published. IEEE802.15.4-2018 has small changes compared to IEEE802.15.4-2015, for example the encoding of the IE header changes from [type,length,value] to [length,type,value], for whatever reason, good or bad. Are company foo's product now stripped off their certification? Even if it takes foo's engineers 2h to release firmware compliant to IEEE802.15,4-2015, what is company foo supposed to do with it? Recall all products? Really!? Let's get even deeper into trouble: company bar starts making products in 2019 based on the *same* draft-ietf-6tisch-minimal standard as company foo. These products also pass certification, and start selling. But even foo and bar implement the *same standard*, their product do not interoperate. >From what I understand, this is possible if we put an undated reference to IEEE802.15.4 in draft-ietf-6tisch-minimal. In that case, we have, as a standardization organization, completely failed. I hope I'm wrong, and I hope you can show me why. On Fri, May 1, 2015 at 12:40 AM, Tom Phinney <[email protected]> wrote: > Pat, > > I agree with you completely. In my experience, many contributors to > standards believe it to be their job to guide a reader into finding > material in a normative reference by citing specific 'chapter and verse", > or in this case detailed subclause numbering, when instead they should be > indicating the topic area and specific information that is of importance. > Standards that call out lots of specific subclauses by number are a > nightmare to maintain, particularly if they reference more than one other > normative standard in such detail, because they necessarily need to be > updated whenever ANY of those cited-in-detail normative references are > updated. > > If the writer of such clauses was told that they would be devoting one > week per year for the rest of their lives to maintaining and updating all > the detailed references that they included, it seems likely that they would > find ways to word the text that did not so encumber their future. > > -Tom > ===== > On 2015.04.30 15:13, Pat Kinney wrote: > > Qin; > > You are correct that referring only to the standard does not allow you > to refer to sub-clauses or pages and line numbers. > > I would propose changing the current text: > " A 10ms time slot length is the default value defined by [IEEE802154e]. > Section 6.4.3.3.3 of [IEEE802154e] defines a default macTimeslotTemplate, > i.e. the different duration within the slot. These values are summarized in > the following table and MUST be used when utilizing the default time slot > duration. In this case, the Timeslot IE only transports the > macTimeslotTemplateId (0x00) as the timing values are well known. If a > timeslot template other than the default is used, the EB MUST contain a > complete TimeSlot IE indicating the timeslot duration and the corresponding > timeslot timings, requiring 25 bytes. Note however that in case of > discrepancy between the values in this document and [IEEE802154e], the IEEE > standard specification has precedence.” > > with the following text: > “The timing parameters for the default *macTimeslotTemplate* ( > *macTsTemplateID* = 0) are summarized in the following table and MUST be > used when utilizing the default time slot duration. For the case of the > default *macTimeslotTemplate*, the Timeslot IE only transports the > macTimeslotTemplateId (0x00) as the timing values are previously known. If > a timeslot template other than the default is used, the EB MUST contain a > complete TimeSlot IE indicating the timeslot duration and the corresponding > timeslot timings. Note however that in case of discrepancy between the > values in this document and IEEE 802.15.4, the IEEE standard has precedence. > > > Pat > > Pat Kinney > *Kinney Consulting LLC* > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > [email protected] > > On 30, Apr2015, at 15:34, Qin Wang <[email protected]> wrote: > > Hi all, > > I understand that reference IEEE 802.15.4 includes IEEE802.15.4e by > definition. But I have a problem in writing 6TiSCH draft if we remove "e" > in reference. > > Here is an example. "A 10ms time slot length is the default value > defined by [IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e] defines a > default macTimeslotTemplate,...." is in the section 3.4 of minimal draft. > Then, the question is how to point the exact place if we use IEEE 802.15.4 > as reference. > > Thanks > Qin > > > > > On Friday, May 1, 2015 12:55 AM, Pat Kinney < > [email protected]> wrote: > > > An amendment references (is based upon) the latest revision when it was > approved, hence 802.15.4e is based upon (i.e. it references) 802.15.4-2011. > > Pat > Pat Kinney > Kinney Consulting LLC > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > [email protected] > > > > > > > On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello Michael > > For All I know 4e TSCH is only defined on 2011. There are known similar > technologies running over 2006 but they are not 4e... > > The undated reference in an RFC to an IEEE spec applies to the present > state at the date of the RFC and to all future versions unless the RFC is > revised. > > This proved useful for Ethernet; too much maybe since we were fooled into > extending IP over Ethernet to Wi-Fi... > > Cheers, > > Pascal > > > Le 30 avr. 2015 à 07:50, Michael Richardson <[email protected]> a > écrit : > > > > > > Pascal Thubert (pthubert) <[email protected]> wrote: > >> Today, undated and without the 'e', IEEE802.15.4 means 2011 plus all > >> the amendments. > > > > Given that we can't run on 802.15.4-2011, this is why I'm concerned about > > referencing "802.15.4". > > > >> So, a reference to IEEE Std 802.3 (without year) today is identical to > the > >> 2012 dated reference, but when the current revision is approved > (expected > >> this year), a reference to the 2012 revision would not include the > >> maintenance changes included in the current revision, nor any of the > >> amendments likely to be approved soon after the revision is approved. > > > > How does an outsider know when the reference was made? Is it by the date > > of the document making the reference? > > > > If the IETF writes a document in 2014, but it doesn't get published in > Jan. 2015, > > what IEEE document would "802.15.4" reference? > > > > Robert suggests text like: > > > >> In development of this RFC, IEEE Std 802.99 documents considered > included > >> IEEE Std 802.99-2016 and P802.99/D8. > > > > and so if we can do this, then I'm happy. > > > > > > > > > > -- > > Michael Richardson <[email protected]>, Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > _______________________________________________ > > 6tisch mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > _______________________________________________ > 6tisch mailing [email protected]https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
