Hello Qin, Thanks for your reply. Please see inline,
Regards, JM 2017-06-07 22:46 GMT+02:00 Qin Wang <[email protected]>: > Hi Jonathan, > > Sorry, in previous email I missed your comment about section 4.3.5. > > Your question is: if the SF manages several slotframes, when retrieving > the LIST, how to differentiate them, since they appear as a tuple > (slotOffset,channelOffset). My question is if it is worthy to make the > differentiation when receiving all the cells. Or this will be handled by > the SF? IMO an example will be good. > > According to my understanding, SF0 uses Metadate to express slotframe ID, > see the description of Metadata in 6P draft. Thus, it is SF0 who handles > this. For example, SF0 can define in this way: if specific slotframe ID in > Metadata, then the Cells in the CellList of Response belong the specific > slotframe; if setting some value like FF in Metadata to say all of > slotframes, then the CellList of Response will include all of cells > scheduled between the two neighbors. But, this should be defined and > explained in SF0 draft. What do you think? > > [JM]: so this is left for the SFs to manage what information to ask for. > Good. > > > Thanks > Qin > > > On Wednesday, June 7, 2017 3:54 PM, Qin Wang <[email protected]> > wrote: > > > Hi Jonathan, > > Thank you very much for your review. Please see inline. > > Qin > > > > On Wednesday, June 7, 2017 11:21 AM, Jonathan Muñoz < > [email protected]> wrote: > > > Dear 6P authors, W.G, > > I read the 6top Protocol draft - v05, and I find it very clear. I have > some questions and few comments. Hopefully you'll find them useful. > > Best, > > Jonathan Munoz > > ------------------------------ ------------------------------ > ------------------------- > ->Section 4.1: "If no dedicated cells are scheduled between nodes A and B, > shared > cells MAY be used. -> Is there another option? if not, shouldn't say > MUST? > [Qin]: I think there is another option, i.e. do nothing if no dedicated > cells are scheduled between node A and node B. What do you think? > [JM]: I think that if this is the description of the 6P Transactions, they > either happen in a dedicated cell or a shared cell. IMO, doing nothing is > always an option but it won't then classify as a 6P Transaction. > > > ->Section 4.3.2: > " All cells in the CellList MUST already be scheduled between the > two nodes and must match the CellOptions field. If node A puts cells in its > CellList that are not already scheduled between the two nodes and match the > CellOptions field, node B replies with a RESET return code" > > Section 4.3.3: > "Upon receiving the request, node B's SF verifies that all the cells > in the Relocation CellList are indeed scheduled with node A, and are > associate the options specified in the CellOptions field. If that check > fails, node B MUST send a 6P Response to node A with return code > CELLLIST_ERR." > > Both errors give a different response but it looks to me that they have > the same source -mismatch in their schedule-. Is it ok? > > [Qin] You are right. We change error code in 4.3.2 to CELLLIST_ERR. > > ->Section 4.3.5: > if the SF manages several slotframes, when retrieving the LIST, how > to differentiate them, since they appear as a tuple > (slotOffset,channelOffset). My question is if it is worthy to make the > differentiation when receiving all the cells. Or this will be handled by > the SF? IMO an example will be good. > > ->Figures: 17, -6P COUNT Response and Confirmation- > 19, -6P LIST Response and Confirmation- > 21, -6P CLEAR Response and Confirmation- > > Will these transaction have a confirmation message? it seems to me > they are a 2-step transactions, always. > > [Qin] accepted. > > -> Sequence Number: will it increase +1 despite the failure of the > previous transaction? > > [Qin]: I think so. Is there any particular reason for not doing in this > way? > > [JM]: perfect, thanks for clarifying. > ------------------------------ ------------------------------ > ------------------------- > > > -- > Jonathan Muñoz > PhD student at Gridbee Communications & INRIA Paris > +33 (0) 6 59 05 93 83 > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > -- Jonathan Muñoz PhD student at Gridbee Communications & INRIA Paris +33 (0) 6 59 05 93 83 <+33%206%2059%2005%2093%2083>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
