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
