Hi Jonathan,
Thank you very much for your review. Please see inline.
Qin

    On Wednesday, June 7, 2017 11:21 AM, Jonathan Muñoz 
<jonathan.mu...@inria.fr> 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?
->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?

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

-- 
Jonathan MuñozPhD student at Gridbee Communications & INRIA Paris+33 (0) 6 59 
05 93 83_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


   
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to