Subject: Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 6 Apr 2018 17:39:12 +0200

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)

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Additionally:

3.2.2.  Generic 6P Message Format

   6P Version (Version):  The version of the 6P protocol.  Only version
         0 is defined in this document.  Future specifications MAY
         define further versions of the 6P protocol.

Use of MAY in the last sentence doesn't seem correct, as there is no way to
test conformance to it. I suggest you just change it to lowercase "may" and
add
boilerplate to reference RFC 8174 in addition to RFC 2119.

XV: thanks for this comment. We have changed the MAY to may as suggested.
We agree with your point.

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

   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.

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

3.3.5.  Listing Cells

   When node B receives a LIST request, the returned CellList in the 6P
   Response contains between 1 and MaxNumCells cells,

Here you say "between 1 and MaxNumCells".

   starting from the
   specified offset.  Node B SHOULD include as many cells as fit in the
   frame.  If the response contains the last cell, Node B MUST set the
   Code field in the response to RC_EOL ("End of List", as per
   Figure 37), indicating to Node A that there no more cells that match
   the request.  Node B MUST return at least one cell, unless the
   specified Offset is beyond the end of B's cell list in its schedule.
   If node B has less than Offset cells that match the request, node B
   returns an empty CellList and a Code field set to RC_EOL.

And here you say that 0 is allowed. You should update the above to say
"between
0 and MaxNumCells".

XV: thanks for this catch. we fixed that. This was a left over from a
previous version.

kind regards
Xavi

2018-04-05 14:03 GMT+02:00 Alexey Melnikov <[email-masked]>:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-6tisch-6top-protocol-11: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/
>
>
>
> ----------------------------------------------------------------------
> 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.
>
> 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.
>
> 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)?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I am agreeing with Benjamin's DISCUSS about versioning. I think you need to
> describe in a bit more details which messages/parts of protocol should
> remain
> unchanged for forward compatibility with future versions.
>
> Additionally:
>
> 3.2.2.  Generic 6P Message Format
>
>    6P Version (Version):  The version of the 6P protocol.  Only version
>          0 is defined in this document.  Future specifications MAY
>          define further versions of the 6P protocol.
>
> Use of MAY in the last sentence doesn't seem correct, as there is no way to
> test conformance to it. I suggest you just change it to lowercase "may"
> and add
> boilerplate to reference RFC 8174 in addition to RFC 2119.
>
> 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.
>
> 3.3.5.  Listing Cells
>
>    When node B receives a LIST request, the returned CellList in the 6P
>    Response contains between 1 and MaxNumCells cells,
>
> Here you say "between 1 and MaxNumCells".
>
>    starting from the
>    specified offset.  Node B SHOULD include as many cells as fit in the
>    frame.  If the response contains the last cell, Node B MUST set the
>    Code field in the response to RC_EOL ("End of List", as per
>    Figure 37), indicating to Node A that there no more cells that match
>    the request.  Node B MUST return at least one cell, unless the
>    specified Offset is beyond the end of B's cell list in its schedule.
>    If node B has less than Offset cells that match the request, node B
>    returns an empty CellList and a Code field set to RC_EOL.
>
> And here you say that 0 is allowed. You should update the above to say
> "between
> 0 and MaxNumCells".
>
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Apr 2018 18:19:47 +0100

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:
> ----------------------------------------------------------------------> 
> 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
>       CellList is not empty but contains less than NumCells cells is
>       not>       supported.
> 
>       
I am lost the context for this. But I can double check when a new
revision is published.
>  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.
> 
>  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.
>  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. "
>                
> 
> 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?
> 
> 
> ----------------------------------------------------------------------> COMMENT:
> ---------------------------------------------------------------------- [snip]
> 3.3.2.  Deleting Cells
> 
>       receiving node SHOULD delete any cell from the sender, as long
>       as> 
> 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?
>       
>    o  The CellList in a 6P Request (2-step transaction) or 6P Response>       (3-step transaction) MUST either be empty, contain exactly
> 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.
> 
>       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.> "
Best Regards,
Alexey

---

From: Qin Wang <[email-masked]>
Date: Thu, 19 Apr 2018 20:51:40 +0000 (UTC)

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-masked]> wrote:  
 
 Hi Xavi,

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 

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

      The case where the

I am lost the context for this. But I can double check when a new revision is published.

 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.

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

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)

 [snip]
3.3.2.  Deleting Cells

      
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

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

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-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Apr 2018 11:48:55 +0100

Hi Qin,

On Thu, Apr 19, 2018, at 9:51 PM, Qin Wang wrote:
> On Thursday, April 12, 2018, 1:20:01 PM EDT, Alexey Melnikov
> <[email-masked]> wrote:> 
> 
> Hi Xavi,
> 
>> thank you very much for the provided constructive review.>> 
>> received reviews.>> 
>> ---------------------------------------------------------------
>> ------->> DISCUSS:
>> ---------------------------------------------------------------
>> ------->> 
>> 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
>> What is the meaning of "more than NumCells cells" in case of DELETE?>> 
>>       The case where the
>>       not>>       supported.
> revision is published.>>       
>>  example if>>  one of the nodes is implementing an extension and the other node
>>  doesn't>>  support such extension.
>> 
>>  XV: Thanks, we agree on the proposal. We propose the following text:>>  
>>  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
>>  return code and consider the transaction as failed.> I am not entirely certain on a value in responding to an unrecognized
> 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?I am just concerned that in the 3-step transaction you are adding 4th
step just to convey to the sender that the last error code was not
supported. An unrecognized error should already be treated as an error,
so the transaction already failed at this point.
>>  this document.>>  The SF defines what to do after an error has occurred. "
>>                
>> 
>> 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
>> changes will be self-contained in the particular SF.> But a generic parser for these fields wouldn't be able to do that,
> their format.> 
> like. Is there a draft/proposal in works already?> 
> 
> Qin: For these fields, a parser is always associated with a specific
> SF. Some of SFs may use the default format defined in this document,
> while others may re-define the format of these fields. For example, a
> SF re-define the format of CellList. Instead of a list of (slotOffset,
> channelOffset), the format could be as follows.> (StartCell, NumberOfCell, SlotIncrement, ChannelIncrement). For
> example, ((2,2), 3, 2,1), means the 3 cells (2,2), (4,3) (6,4)I think you need to make this very clear early in the document that this
is your intent.  I don't think this is wise, but this is just my (non
blocking) preference.
>> 
>> ---------------------------------------------------------------
>> ------->> COMMENT:
>> ---------------------------------------------------------------
>> ------->  [snip]
>> 3.3.2.  Deleting Cells
>> 
>>       as>> 
>> 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,
> CellOptions field?> 

> 
>>       
>>    o  The CellList in a 6P Request (2-step transaction) or 6P
>>    Response>>       (3-step transaction) MUST either be empty, contain exactly
>> What is the meaning of "more than NumCells cells" in case of DELETE?>> 
>> 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.> 
>>       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 address the two problems above, we rephrase as follows

>> “The CellList in a 6P Request (2-step transaction) or 6P Response

>>       NumCells cells, or more than NumCells cells.  The case where
>>       the>>       CellList is not empty but contains fewer than NumCells cells is>>       not supported.  RC_ERR_CELLLIST code MUST be returned when the>>       CellList contains fewer than NumCells cells.  If the CellList
>>       is>>       empty, the SF on the receiving node SHOULD 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 the receiving node has
>>       flexibility>>       to choose exactly NumCells cells from the CellList to delete.”>> 
>> What do you think?

This is much better. Thank you!

---

From: 王沁 <[email-masked]>
Date: Fri, 20 Apr 2018 23:48:19 +0800 (GMT+08:00)

Hi Alexey,

Please see inline.

Thanks
Qin

-----原始邮件-----
发件人:"Alexey Melnikov" <[email-masked]>
发送时间:2018-04-20 18:48:55 (星期五)
收件人: "Qin Wang" <[email-masked]>, "Xavi Vilajosana Guillen" <[email-masked]>
抄送: tisch <[email-masked]>, "Pascal Thubert" <[email-masked]>, [email-masked], "The IESG" <[email-masked]>, [email-masked]
主题: Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)

Hi Qin,

Hi Alexey,

Qin

Hi Xavi,

Dear Alexey, 

thanks again,

Xavi 

DISCUSS:

of this document:

1) 3.3.2.  Deleting Cells

      The case where the

      supported.

 support such extension.

I am just concerned that in the 3-step transaction you are adding 4th step just to convey to the sender that the last error code was not supported. An unrecognized error should already be treated as an error, so the transaction already failed at this point.

Qin: I see your point. We update the paragraph as follows.

“If a node

   receives an unrecognized return code the 6P Transaction MUST be

   considered as failed.  In particular, in a 3 step 6P Transaction, a

   6P Response with an unrecognized return code MUST be responded with a

   6P Confirmation with return code RC_ERR and consider the transaction

   as failed.  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.”

What do you think?

Qin: For these fields, a parser is always associated with a specific SF. Some of SFs may use the default format defined in this document, while others may re-define the format of these fields. For example, a SF re-define the format of CellList. Instead of a list of (slotOffset, channelOffset), the format could be as follows.

(StartCell, NumberOfCell, SlotIncrement, ChannelIncrement). For example, ((2,2), 3, 2,1), means the 3 cells (2,2), (4,3) (6,4)

I think you need to make this very clear early in the document that this is your intent.  I don't think this is wise, but this is just my (non blocking) preference.

Qin: Add sentences in 3.2.3 and 3.2.4 to clarify.

COMMENT:

 [snip]

3.3.2.  Deleting Cells

      

      The case where the

      supported.

"

      NumCells cells, or more than NumCells cells.  The case where the

      CellList is not empty but contains fewer than NumCells cells is

      not supported.  RC_ERR_CELLLIST code MUST be returned when the

      CellList contains fewer than NumCells cells.  If the CellList is

      empty, the SF on the receiving node SHOULD choose any NumCells

      cells with the sender from its schedule, which match the

      than NumCells cells, the SF on the receiving node has flexibility

      to choose exactly NumCells cells from the CellList to delete.”

What do you think?