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 >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
