Xavi - please see my responses inline > On Dec 12, 2016, at 11:35 PM, Xavi Vilajosana Guillen <[email protected]> > wrote: > > Dear Jonathan, > > thanks for your comments. See inline our responses: > > 2016-12-12 22:48 GMT+01:00 Jonathan Simon <[email protected] > <mailto:[email protected]>>: > Xavi, Kris - Some questions about draft 17: > > 4: The callouts in figure 1 don't exactly match what's in 4.5.2, namely that > the timelsot and hopping template IDs (as opposed to the full sequence) are > what is carried in the EB. > > XV: The proposed configuration as advertised in the EB uses the default > timeslot and hopping template ID. macTimeslotTemplateId = 0 and the default > (macHoppingSequenceID = 0). Following your suggestion I will change the table > to indicate this (macHoppingSequenceID = 0). Should we also keep the default > sequence as a clarification (indicating that) [5, 6, 12, 7, 15, 4, 14, 11, 8, > 0, 1, 2, 13, 3, 9, 10]?
JS - I don't think you need to call out the specific sequence. It should be sufficient to cite 802.14.5 section 6.2.10 which describes how it is generated. > > 4.5: This paragraph could be interpreted as saying that a compliant node may > choose particular settings, but must be able to understand all possible valid > TSCH settings to be 6TiSCH compliant. I don't understand that you "may" set > to any valid TSCH setting but you "should" set them to what is specified > later on. > > > > XV: You are right. We need to clarify this. I think we want to be clear here > with the recommended frame format. I try to rephrase it. JS - thanks! > > > 4.5.1: > 1) What is the EB source address size? Presumably the dst is short FFFF, > but it isn't stated. > > XV: According to 15.4 -2015 > page 65. > > "The Source Address field, if present, shall contain the address of the > device sending the frame. When a > device has associated and has been allocated a short address (i.e., > macShortAddress is not equal to 0xfffe or > 0xffff), it shall use that address in preference to its extended address > (i.e., macExtendedAddress) wherever > possible. When a device has not yet associated to a PAN, it shall use its > extended address in all > communications requiring the Source Address field. If the Source Address > field is not present, the originator > of the frame shall be assumed to be the PAN coordinator or RFD-TX device, and > the Destination Address > field shall contain the address of the recipient, optional for RFD-TX > devices." > > The destination address should be 0xFFFF as you indicate. (short address). > The source should be the node's extended address as per table 7-6 of > 15.4-2015 (page 117) (12th row of the table). JS - I would think that if the JA beaconing has a short address, whether we use the association process discussed in 15.4 section 6.4.1 or not, then it should beacon using its short address (table 7-6 line 13), unless this makes it impossible for the JN to properly address its join request. In either case, I think an explicit callout to the address size in the text would be helpful. > > 2) "While listening for EBs, a joining node set its own PAN ID to 0xffff..." > Why is the PAN ID set to FFFF? This implies that the EB either doesn't have a > dst PAN ID (contrary to the previous paragraph) or that nodes accept EB's > from any advertising PAN, which makes PANID not useful in partitioning > networks. > > XV: This comes from some discussions we had some time back. I will try to > find the threads. As far as I remember, the concern was that the PAN ID is > not known by the node performing the scan. Then in order to be able to accept > the EB following the filtering rules (level 3) defined in the 15.4-2011. > section 5.1.6.2 or later in section 6.7.2 of 15.4-2015 the PAN ID has to be > set to FFFF. I agree with you that we need to check this again. JS - to me this is policy. If I as a vendor want to partition networks by PANID, then I can do so, and if I want to be able to join any PAN, I can do so. I think a statement that setting to FFFF allows the JN to join any PAN is sufficient. > > > 4.5.2: "EBs SHOULD NOT be used for time synchronization." The JN must > initially set it's clock from the EB, otherwise it will have no idea when to > send in its join request - see 6.2. I think you mean that EB's should not > be used for time synchronization after a node has K2? > > XV: I agree. We need first to join the network. I will correct that. JS - thanks > > 4.6: How do you send in a join request using K2 (since it is a data frame and > not an EB) when you don't have K2 yet? > > XV: Good point. we do not say how K2 is provisioned. This is something that > other documents in the WG should specify. In case K2 is pre-provisioned this > is solved, however, the zero or one touch approaches should clarify this I > guess. Do you have any suggestion for that? I understand that considering > only minimal, if K2 is not pre-provisioned, we cannot join the network unless > we use another mechanism. JS - I think you've hit on the point - frames should be secured with K2 once K2 is provisioned. Then you can say that can be done a priori, or refer to Mališa's minimal security draft (or Michael's draft) as an example of how K2 get's provisioned. > > > Jonathan > > [email protected] <mailto:[email protected]> > > > > > -- > Dr. Xavier Vilajosana Guillén > Research Professor > Wireless Networks Research Group > Internet Interdisciplinary Institute (IN3) > Universitat Oberta de Catalunya > > +34 646 633 681| [email protected] <mailto:[email protected]> | Skype: > xvilajosana > http://xvilajosana.org > <https://urldefense.proofpoint.com/v2/url?u=http-3A__xvilajosana.org&d=DgMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=3DOaKrDPnnwRLCTyzcyokUCKXuQps31_f-91AsGhUTY&s=Jla7GomFTQ4asauScSlvf8A3cngLcCeRuQRGXr0zU8U&e=> > http://wine.rdi.uoc.edu/ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__wine.rdi.uoc.edu_&d=DgMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=3DOaKrDPnnwRLCTyzcyokUCKXuQps31_f-91AsGhUTY&s=JoQxnNqyj0DjMWz2oE7AlLpOcDmcwgJV0_2lBP0WeAw&e=> > > Parc Mediterrani de la Tecnologia > Av. Carl Friedrich Gauss, 5. Edifici B3 > 08860 Castelldefels (Barcelona) > > > Jonathan Simon [email protected] <mailto:[email protected]>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
