Hi Xavi, Thanks for the summary. Please see inline.
> > >I tried to summarize the action items we identified during the call. Please >comment if you do not agree. Here a list: > > >1 clarify the use of RC_END_OF_LIST text upon receiving a list command and >reaching the end of the list [Qin]: agree > >2 Clarify that if a node has too many cells to add that do not fit in the >packet, the node has to issue multiple ADD requests. > * add a section saying what happens if you have to many cells to add. [Qin]: agree > >3 Detail 3-way transaction as 2 way is done (4.3.7. Adding Cells with 2-way >Transaction). Explain how 3-way transaction works in the same manner as it is >done in 4.3.7 for 2-way transaction. > [Qin]: agree >>4 Add sentence detailing why there is a 3-way transaction and what it enables >>--> add an example use case -> why use 3-way: > -> It is useful when: > - when we want the destination to select candidate cells, > - when the origin doesn't care which cells to be allocated. [Qin]: Remove the second scenario, Because when the origin doesn't care which cells to be allocated, the origin node can use 2-way transaction as well. > - when the destination is not able to allocate the requested cells.> > > - the selection of the transaction type is up to the SF.> > >5 Clarify in the case of 2-WAY and 3-WAY transaction what happen if a >requesting node cannot be allocated any cell in the destination. > [Qin]: I think it is a case different from pure 2-way and 3-way cases. The origin node starts a 2-way transaction, but ends up 3-way transaction because the destination node cannot allocate any cell from the candidate celllist. Should we use another name for it to distinguish from pure 3-way transaction? >>6 Indicate that we wait for link layer ACK at the 6P transaction to commit. >>-> In a response the node commits after succesful transmission. >They will commit at the end of the slot. > [Qin]: agree >>7- Add a section describing when there is a real inconsistency after all the >>retransmissions failed. > [Qin]: agree >>8- Merge GBA GAB using 2 bits and rename it as Generation. We update it when >>we commit. Use lolipop counter (0, 1-2). GTX and GRX are also merged and >>renamed to Generatin counter. > [Qin]: agree >>9-RELOCATION: content-> what cell to relocate. >relocation request uses first cell of the cell list to indicate the cell to be >moved. The rest of the cells are candidate cells being proposed. if it is >empty the other side decides. > [Qin] propose that relocation request can use NumCells to indicate how many cells need to be removed, and accordingly, uses the first NumCells cells in the celllist to indicate the cells to be removed, the rest of cells are candidate cels being proposed. Thought? >>10-Add error code for figure 6 when the response is proposing other cells as >>there is no match -> add error RC_NOMATCH > >* In STATUS and list commands return the content in the payload but also >return an error code in case of the schedule mismatch. > [Qin]: I think it happens when Generation counter is mismatched> > > >Items that for me are not still clear: > > >11- Handling multiple SFs in LIST, STATUS. The SFID represents the used SF. >Indicate that if 0xFFFF is used as SFID in the LIST, STATUS query, the >response includes all cells handled by the different SFs. > [Qin]: agree> >12- Indicate that it is recommended that when a cell is allocated by a >particular SF, the SFID needs to be stored together with the cell information. >This is useful when multiple SFs are running in parallel. > [Qin]: Considering #11, I think it has to be a strong recommendation.> >13- Say maybe that multiple SFs cannot be modifiying the same slotframe? > [Qin]: agree> >impact on minimal -> > >14- minimal slotframe handle -> move from 0 to 0x80. This is to enable higher >priority slotframes to be added. If not minimal will always be the highest >priority. Alternative. Do not say which handle minimal uses and let it be >chosen by the network operator. This is announced in the EB so can be changed. >Maybe say default value but others can be used and properly announced in the >EB. > [Qin]: agree to "Alternative"> Thanks Qin _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
