Thomas;

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

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email protected] <mailto:[email protected]>

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

<no chair hat>

Little thought exercise.

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

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

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

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


On Fri, May 1, 2015 at 12:40 AM, Tom Phinney <[email protected] 
<mailto:[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 <tel:%2B1.847.960.3715>
> [email protected] <mailto:[email protected]>
> On 30, Apr2015, at 15:34, Qin Wang <[email protected] 
> <mailto:[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] 
> <mailto:[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 <tel:%2B1.847.960.3715>
> [email protected] <mailto:[email protected]>
> 
> 
> 
> 
> 
> 
> On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email protected] 
> <mailto:[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] 
> > <mailto:[email protected]>> a écrit :
> > 
> > 
> > Pascal Thubert (pthubert) <[email protected] <mailto:[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] <mailto:[email protected]>>, 
> > Sandelman Software Works
> > -= IPv6 IoT consulting =-
> > 
> > 
> > 
> > _______________________________________________
> > 6tisch mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/6tisch 
> > <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/6tisch 
> <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/6tisch 
> <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/6tisch 
> <https://www.ietf.org/mailman/listinfo/6tisch>


_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch 
<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

Reply via email to