Subject: Re: [6tisch] Removing the 'e' in the charter

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 May 2015 10:48:12 +0000

Hello Thomas

I agree that we shouldn't place cie Foo in such a situation. We must also be clear that a certification can not concern minimal alone. There will be say an IPSO 4.0 which will define a stack and conformance and interop will be guaranteed forever to that 4.0; so as a pure standard procedure we are covered.

Now, as a community, if we make it so that there are hundreds of non-Interoperable standards then cie Foo will have a minimalistic market and it will die. IOW we'd be shooting ourselves in the feet or probably higher in between if we let that happen.

The way to prevent that is not to use the  references wrongly. That has no power at all. It's only a way to ensure that what we write auto- deprecates itself whatever the rest of the world does. We are effectively making minimal an interim standard when Tom and Pat illustrate that it sometimes can be otherwise.

The way to prevent that is to actively participate to the standards that define the elements that the solutions depend upon.

My view: 6TiSCH can certainly express concerns to our IG at IEEE, and individuals are encouraged to contribute to IEEE when they can; but 6TiSCH should still do the right thing as to what we publish, in our best interest. In my view, our best interest is to produce a stable and durable layer 3 operation, as loosely coupled as possible from L2 evolution.

And I think we're doing just that and encourage those impacted by L2 stability (or lack thereof) to reconsider their text and figure if we have cases where Pat's example writing applies.

I hope that makes sense...

Pascal

Le 1 mai 2015 à 01:16, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> a écrit :

<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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>

On 30, Apr2015, at 15:34, Qin Wang <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>

On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> a écrit :
>
>
> Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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: "S.V.R.Anand" <[email-masked]>
Date: Fri, 01 May 2015 22:31:28 +0530

Hi,

I agree with the proposal that 'e' needs to be removed. I am of the view 
that
removing 'e' is good for the charter as it gives flexibility for IETF to
propose future drafts without being tied to a particular specification as in
the case of IEEE. Here is my take on this. Let us assume hypothetically that
the idea of TDMA based channel hopping over basic 15.4 had occurred to 
one of
the Internet experts and proposed an Internet draft that defines an abstract
MAC layer, much before IEEE came up with 4e. What would have happened in 
that
scenario ? 6tisch would have been defined on top of that layer. Right ?
Just that it did not happen.

What I mentioned above could have easily happened, as after all, time based
link sharing on top of an existing physical MAC is not new to the Internet
world at all. Loosely speaking rate limiters, packet shapers, MPLS, 
VLANs, and
friends are trying to create virtual/abstract MACs on top of the 
physical MACs,
ala IEEE 802.3.

Essentially, 4e is just one way of creating MAC access abstraction. IETF 
should
have the flexibility of defining other interesting link sharing 
mechanisms, not
unduely limited by what IEEE defines. 4e can be a subset.

Anand

On Friday 01 May 2015 03:19 AM, Pascal Thubert (pthubert) wrote:
>
 > Hello Qin:
 >
 >
 >
 > This is why Minimal and probably 6top will need to keep a dated 
reference. The price to pay will be to publish an update is the 
conversion is non obvious to future versions on the IEEE standard&
 >
 >
 >
 > Cheers,
 >
 >
 >
 > Pascal
 >
 >
 >
 > From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
 > Sent: jeudi 30 avril 2015 13:35
 > To: Pat Kinney; Pascal Thubert (pthubert)
 > Cc: Michael Richardson; [email-masked]; ROBERT GROW ([email-masked])
 > Subject: Re: [6tisch] Removing the 'e' in the charter
 >
 >
 >
 > 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-masked]> 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.
 > O: +1.847.960.3715
 > [email-masked]
 >
 >
 >
 >
 >
 >
 > On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) 
<[email-masked]> 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-masked]> 
a écrit :
 > >
 > >
 > > Pascal Thubert (pthubert) <[email-masked]> wrote:
 > > Michael Richardson <[email-masked]>, Sandelman Software Works
 > > [email-masked]
 > [email-masked]
 > [email-masked]
 > This message has been scanned for viruses and
 > dangerous content by MailScanner, and is
 > believed to be clean.
 >
 > [email-masked]

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 May 2015 17:08:58 +0000

+1

This abstraction would work on many PHYs, including .11ac;
We have to start small but the vision can be much larger...

Cheers,
Pascal

Le 1 mai 2015 à 19:02, S.V.R.Anand <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

I agree with the proposal that 'e' needs to be removed. I am of the view that
removing 'e' is good for the charter as it gives flexibility for IETF to
propose future drafts without being tied to a particular specification as in
the case of IEEE. Here is my take on this. Let us assume hypothetically that
the idea of TDMA based channel hopping over basic 15.4 had occurred to one of
the Internet experts and proposed an Internet draft that defines an abstract
MAC layer, much before IEEE came up with 4e. What would have happened in that
scenario ? 6tisch would have been defined on top of that layer. Right ?
Just that it did not happen.

What I mentioned above could have easily happened, as after all, time based
link sharing on top of an existing physical MAC is not new to the Internet
world at all. Loosely speaking rate limiters, packet shapers, MPLS, VLANs, and
friends are trying to create virtual/abstract MACs on top of the physical MACs,
ala IEEE 802.3.

Essentially, 4e is just one way of creating MAC access abstraction. IETF should
have the flexibility of defining other interesting link sharing mechanisms, not
unduely limited by what IEEE defines. 4e can be a subset.

Anand

On Friday 01 May 2015 03:19 AM, Pascal Thubert (pthubert) wrote:
>
> Hello Qin:
>
>
>
> This is why Minimal and probably 6top will need to keep a dated reference. The price to pay will be to publish an update is the conversion is non obvious to future versions on the IEEE standard&
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> Cc: Michael Richardson; [email-masked]<mailto:[email-masked]>; ROBERT GROW ([email-masked]<mailto:[email-masked]>)
> On Friday, May 1, 2015 12:55 AM, Pat Kinney <[email-masked]><mailto:[email-masked]> wrote:
>
>
>
> On 30, Apr2015, at 10:37, Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]> wrote:
>
> Hello Michael
>
> > Le 30 avr. 2015 à 07:50, Michael Richardson <[email-masked]><mailto:[email-masked]> a écrit :
> >
> >
> > Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]> wrote:
> > Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 01 May 2015 22:42:49 +0530

Absolutely :)

On Friday 01 May 2015 10:38 PM, Pascal Thubert (pthubert) wrote:
> Le 1 mai 2015 à 19:02, S.V.R.Anand <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
>> Hi,
>>
>> 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> 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-masked]> a écrit :
>> > >
>> > >
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 
>> and is
>> believed to be clean.
>> [email-masked] <mailto:[email-masked]>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>

---

From: Kris Pister <[email-masked]>
Date: Fri, 01 May 2015 10:42:53 -0700

+1 on removing e from the charter.
+1 on removing e from any higher layer documents

This statement is not completely correct:
 > an Internet draft that defines an abstract MAC layer, much before
 > IEEE came up with 4e. What would have happened in that

If we had that abstract MAC layer, then things like PCE and OTF control of
resources would be defined on the abstraction, and perhaps YANG models
and CoAP resources, etc.  I think that we can still do that without the e,
which is good.

But the original goal of 6TiSCH was to create a document to define the
interface between the very flexible 4e/TSCH layer, and all of the
very useful abstractions of the IETF.  If there were an existing abstraction
of TSCH MAC behavior, that would make life easier, but we would still
need at least one simple document to say
* this is how you beacon and join
* this is the minimal MAC capability that you MUST implement

Without that document, there are myriad incompatible ways that smart
well-intentioned people can properly implement these things.  That's what
minimal is meant to do.  It needs to be specific to allow interop today, and
five years from today, which means it can't be subject to a shifting spec,
and must refer to 4e (or -2015 if that comes out before we go to IESG 
review).
Everything above it should be agnostic, and can drop the e and the -20xx .

ksjp

On 5/1/2015 10:12 AM, S.V.R.Anand wrote:
>>> > 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.
>>> >
>>> >
>>> >
>>> > 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

---

From: "S.V.R. Anand" <[email-masked]>
Date: Sat, 02 May 2015 11:23:56 +0530

Kris,

I certainly see you point and agree with your basic concern of
interoperability. We can have 4e in the minimal draft to get things
started.

Ideally, I would have liked the top down approach by defining abstract
link as seen by the network layer, its requirements and give 4e as one
of the suitable candidates that meets these. If the minimal draft
conveys this spirit, we all can breathe freely !

When I mentioned about the abstract MAC layer over basic 15.4, the idea
is to convey that what the network layer cares about is the links and
their states. This requirement automatically translates to some kind of
beaconing and the link information they should carry. Whether beaconing
happens over ICMP or UDP, or ..., is a different matter. This is what I
would have done if I were to have proposed that fictional draft I was
talking about in pre-4e era. RPL, RSVP, OSPF and many more have ways of
providing means of joining the network, learning about links and
maintaining them without being tied to a particular link protocol.

It is very relieving that we are thinking about the future before it is
too late to rectify.

Thanks

Anand

review).
 >>> Le 1 mai 2015 à 19:02, S.V.R.Anand <[email-masked]> a écrit :
 >>>
 >>>> Hi,
 >>>>
physical MACs,
mechanisms, not
 >>>> > 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.