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 protected]> wrote: > 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 > > > > 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 protected]>: > > > >> 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 protected] > >> > >> On 5, May2015, at 16:16, Kris Pister <[email protected]> wrote: > >> > >> 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. > >> > >> On 5/4/2015 5:08 AM, Tero Kivinen wrote: > >> > 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. > >> 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. 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 = ... | > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > ... > >> 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. > >> > > >> > 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. > >> 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)? > >> > > >> > 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. > >> 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? > >> > 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. > >> We'll fix it, pending some input from the group on the questions above. > >> > > >> > -- > >> > > >> > 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. > >> 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 protected] > >> https://www.ietf.org/mailman/listinfo/6tisch > >> > >> > >> _______________________________________________ > >> 6tisch mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/6tisch > >> > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > _______________________________________________ > > 6tisch mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6tisch > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
