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?

->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?

->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.

-> Sequence Number: will it increase +1 despite the failure of the previous
transaction?

-------------------------------------------------------------------------------------



-- 
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

Reply via email to