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
