Hi Alexey,
Thank you for your further comments. Please see inline.
Qin
On Thursday, April 12, 2018, 1:20:01 PM EDT, Alexey Melnikov
<[email protected]> wrote:
Hi Xavi,
On Fri, Apr 6, 2018, at 4:39 PM, Xavi Vilajosana Guillen wrote:
Dear Alexey,
We are answering here the two emails we received from you. We want to thank you
very much for the provided constructive review.
Please, see inline our responses (prepended with XV:). The proposed changes
will be published in v12 of the draft after addressing all received reviews.
thanks again,
Xavi
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thank you for a well written document. I have a small list of
questions/comments, which I would like to discuss before recommending approval
of this document:
1) 3.3.2. Deleting Cells
o The CellList in a 6P Request (2-step transaction) or 6P Response
(3-step transaction) MUST either be empty, contain exactly
NumCells cells, or more than NumCells cells.
What is the meaning of "more than NumCells cells" in case of DELETE?
The case where the
CellList is not empty but contains less than NumCells cells is not
supported.
XV: See below please (what follows is your previous email)
I am lost the context for this. But I can double check when a new revision is
published.
2) 3.4.7. Handling Error Responses
How should unrecognized error codes be treated by recipients? For example if
one of the nodes is implementing an extension and the other node doesn't
support such extension.
I think adding some text to this section would help.
XV: Thanks, we agree on the proposal. We propose the following text:
"... Similarly, a node sending a 6P Response or a 6P Confirmation with an
error code MUST NOT add, delete, relocate any cells as part of that 6P
Transaction.
If a node receives an unrecognized Response Code the 6P Transaction MUST be
considered as failed.
In a 3-step 6P Transaction, a 6P Confirmation with an unrecognized Response
Code MUST be responded with a 6P Confirmation with RC_ERR return code and
consider the transaction as failed.
I am not entirely certain on a value in responding to an unrecognized error
with another error (most other protocols just ignore that), but the rest seems
good.
Qin: RC_ERR is generic error code. An unrecognized Return Code should be
considered as a kind of error. What do you think?
Defining what to do after an error has occurred is out of scope of this
document.
The SF defines what to do after an error has occurred. "
3) 4.2. Requirements for an SF
o MAY redefine the format of the CellList field.
o MAY redefine the format of the CellOptions field.
o MAY redefine the meaning of the CellOptions field.
I am a concerned about interoperability problems that might result from these
requirements. Can you elaborate on what kind of format changes you are
expecting? Wouldn't such changes require some sort of extension (e.g. use of a
new extended ADD command)?
XV: 6P Messages are filtered by SFID, this is, a receiver will process (and not
respond RC_ERR_SFID) if it can match the SFID in the 6P header of the received
message.
If two nodes executing a transaction do not implement the same SF they will not
be able to interop. We foresee future SFs that redefine the default format of
these fields
as presented by the current document. This however would not involve as far as
we can understand any problem of interoperability as the changes will be
self-contained in the particular SF.
But a generic parser for these fields wouldn't be able to do that, unless it
knows the format. I thought that is the point of defining their format.
Maybe you can point me to an example on how such SF format might look like. Is
there a draft/proposal in works already?
Qin: For thesefields, a parser is always associated with a specific SF. Some of
SFs may usethe default format defined in this document, while others may
re-define theformat of these fields. For example, a SF re-define the format of
CellList.Instead of a list of (slotOffset, channelOffset), the format could be
asfollows.
(StartCell, NumberOfCell,SlotIncrement, ChannelIncrement). For example, ((2,2),
3, 2,1), means the 3 cells (2,2), (4,3)(6,4)
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
[snip]
3.3.2. Deleting Cells
o If the CellList in the 6P Request is empty, the SF on the
receiving node SHOULD delete any cell from the sender, as long as
Did you mean "all" instead of "any"?
it matches the CellOptions field.
XV: We mean that NumCells cells will be deleted, any can be chosen. We
rephrased the sentence as:
"If the CellList in the 6P Request is empty, the SF on the receiving node
SHOULD delete any NumCells cells from the sender, as long as they match the
CellOptions field."
My question is: if the implementation decides to follow the SHOULD, can it
ignore arbitrary cells, even if they have the matching CellOptions field?
Qin: See the updated paragraph at bottom
o The CellList in a 6P Request (2-step transaction) or 6P Response
(3-step transaction) MUST either be empty, contain exactly
NumCells cells, or more than NumCells cells.
What is the meaning of "more than NumCells cells" in case of DELETE?
XV: this is to provide flexibility to node B. that is A proposes some cells
(>NumCells) that can be deleted. Then B deletes exactly NumCells from the
candidate set.
I didn't think this was useful functionality, but if you think it is, I suggest
you mention this in the document.
Qin: See the updated paragraph at bottom
The case where the
CellList is not empty but contains less than NumCells cells is not
supported.
XV: We updated this text as well covering other reviewer comments.
" The CellList in a 6P Request (2-step transaction) or 6P Response (3-step
transaction) MUST either be empty, contain exactly NumCells cells, or more than
NumCells cells.
The case where the CellList is not empty but contains less than NumCells
cells is not supported.
RC_ERR_CELLLIST code MUST be returned when the CellList contains less than
NumCells cells.
"
Qin: to addressthe two problems above, we rephrase as follows
“The CellList ina 6P Request (2-step transaction) or 6P Response
(3-step transaction) MUST either beempty, contain exactly
NumCells cells, or more than NumCellscells. The case where the
CellList is not empty but contains fewerthan NumCells cells is
not supported. RC_ERR_CELLLIST code MUST be returned whenthe
CellList contains fewer than NumCellscells. If the CellList is
empty, the SF on the receiving nodeSHOULD choose any NumCells
cells with the sender from its schedule,which match the
CellOption field, and delete them. If the CellList contains more
than NumCells cells, the SF on thereceiving node has flexibility
to choose exactly NumCells cells from theCellList to delete.”
Whatdo you think?
Best Regards,
Alexey
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
