Subject: [6tisch] Some comments to minimal

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 May 2015 15:08:46 +0300

When reading the draft once again, I noticed some more issues:

- The document goes to quite deeply in the explaining the format of
  IEs, including the length and Sub-IDs etc, but it completely omits
  the fact that most IEs we are talking about are MLME Nested IEs.

I.e. the format of the data that will be included in the packet will
be:

  <Header IEs> <Header Termination 1 IE> <MLME Payload IE>

The <MLME Payload IE> will then contain the IEs described in the
section 4. The <Header IEs> part will include the IE described in
section 5.

I.e in normal case the format will be:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length1 = 0 |Element ID=0x7f|0| Length2 = xxx       |GrpId=1|1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length3 = 6 |Sub ID = 0x1a  |0| ASN                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ASN                                           |Join Priority  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length4 = 1 |Sub ID = 0x1c  |0| TT ID = 0x00  | Length5 = ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...

Where the Length1 is the length of Header Termination 1 IE, which is
the first 16-bits of the data, then next 16-bits is the MLME Payload
IE (Group ID = 1) and its length is in Length2, which then includes
all nested IEs inside it. The first nested IE would then be the Sync
IE with length of 6 and Sub ID of 0x1a etc...

I.e. if we copy that much of the 802.15.4 it would be better to copy
so much that people could actually implement it. Or better would be
just leave out stuff that is already in the 802.15.4 and only include
things that we need to say here.

For example we could say that for TSCH Timeslot IE we always use the
Timeslot Template ID of 0x00 and there is no other data in the IE.
Especially as the format for rest of the IE is not accurate, as the
format specified there cannot be used in 915 MHz band, as default
values for macTsMaxTx and macTsTimeslotLength do not fit in the
16-bits allocated for them in IE. In latest revision the last fields
are either 2 or 3 octets and their length can be seen from the length
of the IE.

This parts of the document is bad because it includes too much
information to cause confusion, but too little information so you
cannot still implement anything based on this text.

--

The section 8 says:

							One of the
   keys (K1) is used to authenticate EBs (all frame).  As defined in
   Section 4 EBs MUST be authenticated but payload not encrypted.  This
   prevents two independent networks to interfere or enable non-allowed
   nodes to join a particular network.  

Which would indicate that well-known keys cannot be used as K1, as
they do not authenticate the EBs. 

Also I do not understand what the

								This
   prevents two independent networks to interfere or enable non-allowed
   nodes to join a particular network.  

is really trying to say in the "enable non-allowed nodes ..." part. If
it is trying to say that using real key as K1 will prevent nodes which
do not know the key for joining the network, then that is true, but it
is not true for for the well-known keys case. Well-known keys do NOT
provide that feature.
-- 
[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Tue, 05 May 2015 14:16:13 -0700

Tero - thanks for the feedback.  The goal is to make it quick and easy
for people to implement minimal correctly to enable interop, so any
advice on how we can streamline that process is welcome.

>    the fact that most IEs we are talking about are MLME Nested IEs.
Good point.  My understanding is that all of the IEs described in the 
document are
nested MLME IEs except the ACK time correction IE.
> I.e in normal case the format will be:
That's helpful.  It would probably be helpful to put a similar figure in 
the minimal
draft, with explicit examples of the IEs that are necessary in an EB.
> things that we need to say here.
I agree.  What does the rest of the group think?  Put in enough to 
implement it,
or just point to 802.15.4 (-e, -2015, or -nothing pending resolution of 
that debate)?
> Timeslot Template ID of 0x00 and there is no other data in the IE.
I believe that is exactly what the text says.
In 4.2.2: "Timeslot Template ID (b0-b7) = 0x00"
We could delete the rest of section 4.2.2 which describes what to do if 
you *don't*
want the default timeslot template.  Agree?
> cannot still implement anything based on this text.
We'll fix it, pending some input from the group on the questions above.
We have a proposal to replace this text.  We should try to come to 
resolution on that.
I'll send an email on that shortly.

ksjp

---

From: Pat Kinney <[email-masked]>
Date: Tue, 5 May 2015 16:47:01 -0500

I see no reason why the minimal doc should include any IE formatting, instead the minimal doc should reference the 802.15.4 standard.  

To further elaborate, I believe that section 3.3 should only state the number of retries (i.e. The maximum number of link layer retransmissions is set to 3), section 3.4 should only state that the TSCH defaults are to be used (the rest is repeated from 802.15.4), section 4 and section 5 are not needed as they repeat what 802.15.4 states.  Keeping the minimal document from restating 802.15.4 is the simplest way to avoid possible conflict.  Please note that since the 802.15.4 document is needed to provide PHY requirements and many other MAC requirements, repeating select excerpts in the minimal document isn’t significantly helpful.
 
Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On 5, May2015, at 16:16, Kris Pister <[email-masked]> wrote:

>   the fact that most IEs we are talking about are MLME Nested IEs.
Good point.  My understanding is that all of the IEs described in the document are
nested MLME IEs except the ACK time correction IE.
> I.e in normal case the format will be:
That's helpful.  It would probably be helpful to put a similar figure in the minimal
draft, with explicit examples of the IEs that are necessary in an EB.
> things that we need to say here.
I agree.  What does the rest of the group think?  Put in enough to implement it,
or just point to 802.15.4 (-e, -2015, or -nothing pending resolution of that debate)?
I believe that is exactly what the text says.
In 4.2.2: "Timeslot Template ID (b0-b7) = 0x00"
We could delete the rest of section 4.2.2 which describes what to do if you *don't*
want the default timeslot template.  Agree?
We have a proposal to replace this text.  We should try to come to resolution on that.
I'll send an email on that shortly.

ksjp

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 6 May 2015 05:35:58 +0200

Hi Pat,
let me make some comments inline.

PK>I see no reason why the minimal doc should include any IE formatting,
instead the minimal doc should reference the 802.15.4 standard.

We wanted to make a document which is self-contained as now to implement
15.4e TSCH you need 15.4 and the 15.4e TSCH amendment documents + minimal
draft, going back and forth to them (too much paper on the table does not
leave space for the keyboard). I've seen some emails in the ML of people
that is worried about how security Keys can be *interpreted* if we allow
for example well-known keys. In this case, I am worried about people not
being able to smoothly understand and implement something meaningful that
is defined in "too many" documents. That's why we put some effort on
collecting the minimal set of information and arranging it all together
PK>To further elaborate, I believe that section 3.3 should only state the
number of retries (i.e. The maximum number of link layer retransmissions is
set to 3)

Agree

PK> section 3.4 should only state that the TSCH defaults are to be used
(the rest is repeated from 802.15.4),

As said we target a self contained document and that's why the default
timing is there. We already indicate that and also indicate that in case of
discrepancy, 15.4 has precedence.

PK> section 4 and section 5 are not needed as they repeat what 802.15.4
states.

I do not completely agree although I am open to listen others opinion. For
me Section 4 defines the values for the EB IEs that a minimal configuration
must use as well as defines how the EBs are sent (e.g. EB_PERIOD). What
would have happened if instead of the default values we used another
"minimal-defined" values?
Section 5 just indicates the content of ACKs and exemplifies the IEs
contained on it.

PK>  Keeping the minimal document from restating 802.15.4 is the simplest
way to avoid possible conflict.  Please note that since the 802.15.4
document is needed to provide PHY requirements and many other MAC
requirements, repeating select excerpts in the minimal document isn’t
significantly helpful.

Well I agree partially, it helps when implementing, which is one of our
goals (promote adoption of standardized technologies) right? Do you think
that there is a risk that those IEs change along time? If this ever happens
then 15.4-2011 and back would not be interoperable with new revisions. If
the risk exists I would agree with you that the less we say the better for
minimal, however, I would be very worried about the future of this standard
if basic things change so much.

regards,
Xavi

2015-05-05 23:47 GMT+02:00 Pat Kinney <[email-masked]>:

> I see no reason why the minimal doc should include any IE formatting,
> instead the minimal doc should reference the 802.15.4 standard.
>
> To further elaborate, I believe that section 3.3 should only state the
> number of retries (i.e. The maximum number of link layer retransmissions is
> set to 3), section 3.4 should only state that the TSCH defaults are to be
> used (the rest is repeated from 802.15.4), section 4 and section 5 are not
> needed as they repeat what 802.15.4 states.  Keeping the minimal document
> from restating 802.15.4 is the simplest way to avoid possible conflict.
> Please note that since the 802.15.4 document is needed to provide PHY
> requirements and many other MAC requirements, repeating select excerpts in
> the minimal document isn’t significantly helpful.
>
> Pat Kinney
> Kinney Consulting LLC

---

From: [email-masked]
Date: Wed, 6 May 2015 13:32:46 +0530

Hi,

I agree with Xavi. My understanding of minimal is that it is meant to
convey "at least" and mandatory for interoperability, and *not*
necessarily meant to be the "best"  addressing all the possible concerns
and complete in every aspect one could ever come up with. The existing
document is self-contained and is a good starting point for
interoperability. Since the 6tisch is currently tied to 4e, and is going
to be available in the public domain as a reference, we should be ok. The
future proof method seems to be a new link-layer protocol independent
protocol from IETF with appropriate adaptation layers, inspired by
6LoWPAN.

Anand

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

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 7 May 2015 14:37:17 +0200

All,

Personally, I would like for the minimal draft to describe, in detail, what
the mote should do. IMO, "putting it all together" is not easy at all. Most
of the time, different standards don't imbricate (that's English, right?)
perfectly. And little gaps need to be filled, based on interpretation and
experience. Xavi and Kris have gone through this exercise to write the
minimal draft, in order to provide a complete "receipt" to an implementer.
As a nice side-effect, we can all verify that Xavi & Kris haven't made any
mistakes, and that we don't have different interpretations.

With a plugtest participant in mind, I would assume that this is a very
useful document.

That being said, an implementer will need to have the 4e spec open anyways,
so the suggestion of not copy-pasting entire tables can make sense IMO.

One danger, of course, is that the document gets cluttered and is hard to
read. While I really like the fact that the document shows different
packets, it might make sense to move this down into an "example" section, a
bit like https://tools.ietf.org/html/rfc7252#appendix-A?

My 2 cents. I think we are making very good progress in making this
document as clear as possible!

Thomas :-)

On Wed, May 6, 2015 at 10:02 AM, <[email-masked]> wrote:

> > requirements, repeating select excerpts in the minimal document isnâ€™t
> > significantly helpful.
> >
> >> the minimal document isnâ€™t significantly helpful.
> >>
> >> Pat Kinney
> >> Kinney Consulting LLC

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2015 16:15:36 +0300

Xavier Vilajosana writes:
> We wanted to make a document which is self-contained as now to
> implement 15.4e TSCH you need 15.4 and the 15.4e TSCH amendment
> documents + minimal draft, going back and forth to them (too much
> paper on the table does not leave space for the keyboard).

The current document is nowhere near to be self-contained. You still
need to read 15.4 and 15.4e etc to be able to implement anything. 

> I've seen some emails in the ML of people that is worried about how
> security Keys can be *interpreted* if we allow for example
> well-known keys.

For security keys, the minimal draft does not specify anything how
they are identified in the 802.15.4 level. For the MAC MLME or MCPS
calls you need to give KeyIdMode, KeySource and KeyIndex.

How do you map K1 to those 3 values?

The text does not include anything about how the IEs are actually
formatted inside the MLME nested IE. Or how the IE lists are
terminated. Or it also does not mention that IEEE numbers are in LSB
order etc.

> Well I agree partially, it helps when implementing, which is one of our goals
> (promote adoption of standardized technologies) right? Do you think that there
> is a risk that those IEs change along time?

Most likely no, even when there was some people who complained that
802.15.4 IEs are in LTV format not in TLV format, and they wanted to
ues the last frame version to fix that (i.e. the IE formats for 0b10
DATA etc frame types would not have changed, but we would have added
new frame version 0b11 for DATA etc frame types whcih would use
different IE format).

This was discussed in during the maintenance work, and it was decided
that we do not do this change. If we ever end up changing the frame
format again and need to use the last frame version, then this might
be discussion whether we should fix that at that point, but I
personally do not think there is so much difference whether it is LTV
or TLV to make such change.
-- 
[email-masked]