Subject: Re: [lp-wan] My comments on draft-ietf-lpwan-ipv6-static-context-hc-17 up until now

From: <[email-masked]>
Date: Wed, 5 Dec 2018 15:56:52 +0000

Hello Charlie,

Thanks so much for providing another round of comments. There are greatly beneficial to producing a high quality –18 version of the document.
Please find below a rewriting of your comment/question and my answer, should you wish to discuss it further.
A few of these points might benefit from suggested text by you.
Best regards

Dominique

CEP1: 8.4.1 No-ACK mode, why "SCHC Receiver-Abort MUST NOT be sent"?
DB: The No-ACK mode is meant to support unidirectional links, therefore we do not want to send control traffic in the reverse direction. Besides, what would the Receiver-Abort report about that is not an ACK ? This is No-ACK mode.

CEP2a: 8.4.2.  AK=Always, questioning "The tiles are not required to be of uniform size.  Padding is kept to a minimum: only the last SCHC Fragment is padded as needed."
DB: The sender algorithm states that the Fragment messages are built to carry one tile that is sized such that no padding is needed (except for the last tile).
This mode does not support variable MTU size, therefore the tiles do not have to be of uniform (small) size. They are not necessarily a multiple of L2 Words, so Header mis-alignement is not an issue either.

CEP2b: 8.4.2.1 what is the rationale for "Each SCHC Fragment MUST contain exactly one tile in its Payload."?
DB: This is describing the old ACK-Always mode in the new SCHC F/R parlance that defines the partitioning of the SCHC Packet into tiles.
Since this mode does not support variable MTU, each Fragment message carries as much data as it can with the given MTU, which we say is a tile.

CEP3: 8.4.2.1 "All tiles with the number 0 in their window, as well as the last tile, MUST be at least the size of an L2 Word.".
DB: This was intended to meet the mandates that Regular Fragments MUST be distinguishable by size from ACK REQs, and that All-1 Fragments MUST be distinguishable by size from Sender-Abort.
This statement is now deemed to be over-constraining (there are other solutions to meet the same mandates), so we will remove this statement in –18 and let implementers figure out how they meet the mandates.

CEP4: 8.4.2.1 In the situation described, Sender-Abort is not needed, the receiver is already aborting : "if the current window is the last one and the SCHC ACK indicates that all tiles were correctly received yet integrity check was a failure, the fragment sender MUST send a SCHC Sender-Abort, it MUST release all resource associated with this SCHC Packet and it MAY exit with an error condition."
DB: In fact, the receiver does not know that it has received all the tiles until MIC is correct. It knows it has received a few tiles of the last window, and that it has received the last tile, but it doesn't know the index for the last tile (because the All-1 FCN is used to indicate "last tile", not index). Therefore, it might be missing some tiles in the last window but wouldn't know.
Therefore, in the situation described (the receiver has indeed received all tiles yet the MIC is wrong), the sender knows that the situation is unrecoverable, while the receiver doesn't.

CEP5: 8.4.2.2 "Entering an "acceptance phase", the receiver MUST first clear the  empty Bitmap for this window, then". It would be nice if you would allow implementations to re-use bitmap structures.
DB: Agreed. However, I fail to see how this sentence prevents it. To me, clearing meant resetting the bits to zero, not disposing of the structure.
Can you let me know if I got this wrong or propose better text?

CEP6 8.4.2.2 "Any received SCHC F/R message with a W bit different from the local W bit MUST be silently ignored and discarded." Isn't this *always* true?
DB: This is not always true. For example, when the receiver has just sent an ACK for a window, it might receive a fragment with the flipped W bit (first tile of the next window),  or an ACK REQ with the current W bit (if the ACK was lost). Both are valid and must be processed.

CEP7: 8.4.3 "No SCHC ACK is fed back by the fragment receiver for windows that it knows have been fully received.".  Proposed change to "No SCHC ACK is sent by the fragment receiver for windows for which all tiles have been received."
DB: There is a difference between the receiver having received all tiles and the receiver knowing it. This only happens in the last window. See my response to CEP4 above for the description of such a case.
Furthermore, note that the receiver does not know it is processing the last window until it receives an All-1 Fragment.
I reckon my sentence is convoluted, but it is accurate. Any better wording you can suggest?

CEP8: 8.4.3.1 "The fragment sender MAY send the last tile as the Payload of an All-1 SCHC Fragment.". Proposed change to "The fragment sender SHOULD send the last tile as the Payload of an All-1 SCHC Fragment.".
DB: We anticipate some technologies might be so constrained that the MIC alone will barely fit in the minimal MTU, not leaving space for a tile. Those technologies will likely send their last tile as part of a Regular Fragment. MAY therefore seems more appropriate than SHOULD.

CEP9: 8.4.3.1 Should check whether Attempts is per Window or per Packet.
DB: Indeed, in this mode (ACK-on-Error), Attempts is per Packet. While in ACK-Always mode, it is per Window.

CEP10: 8.4.3.1 "otherwise,  if the SCHC ACK shows no missing tile at the receiver, the sender MUST send a SCHC Sender-Abort, …". It seems inappropriate to transmit an Abort for an already failed Window transmission. Why is this needed?
DB: This stems from the same reasons discussed in CEP7 and CEP4 above.
The sender knows something is unrecoverably wrong at the receiver, while the receiver doesn't. Typically, the receiver's best guess would be it is missing one or several tiles in the last window, but it can't know for sure.

CEP11: 8.4.3.2 "From reception of an All-1 SCHC Fragment onward, a receiver MUST check the integrity of the reassembled SCHC Packet at least every time it prepares for sending a SCHC ACK for the last window.". Proposed change to "After receiving an All-1 SCHC Fragment, a receiver MUST…"
DB: "from … onward" was meant to insist that it was not just at the reception of the All-1 Fragment, but any time after the reception of the All-1 Fragment until the end of reassembly of this SCHC Packet.
If you trust that "After …" is clear enough, I can change it.

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 28 November 2018 22:10
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] My comments on draft-ietf-lpwan-ipv6-static-context-hc-17 up until now

Hello folks,

Attached to this email, please find a file containing my comments on draft-ietf-lpwan-ipv6-static-context-hc-17.txt.   Most of my substantive comments are inserted as 'pretend-xml' comments prefixed by "<!--  CEP".  Earlier I had sent about half of these comments to the authors, thus my updated filename contains "cepB".  I also append a diff file for my comments versus draft-ietf-lpwan-ipv6-static-context-hc-17.txt, as well as the diff file between these comments and my previous comments to the authors.  I believe the authors already accepted most of the comments I had sent to them earlier.

The great majority of the comments are editorial.  Some of the comments would be construed as technical comments aimed at modifying the strength of certain mandates, and reducing the chance for misinterpretation.

Since I am in a hurry to get these comments into consideration, I had to stop reviewing at page 50.   I would like to provide comments for the remainder of the document.  Later today I will list the most important questions and comments I have about the document.

Thanks for your consideration of these review comments.

Regards,
Charlie P.

On 11/28/2018 11:15 AM, Suresh Krishnan wrote:
Hi Charlie,

On Nov 28, 2018, at 1:50 PM, Charlie Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Hello Pascal,

Thanks for pointing out the quoted passage.  But I was responding to the following:

The -18 edition will conclude the WG process for SCHC/IP, and as shepherd I will now ask for publication.

I noticed the word "now".  Besides that, predicting that an unpublished document would conclude the WG Last Call process seems wrong to me.  Of course we can hope for the best.

This is certainly conditional on the issues being addressed by -18. If you do find open issues in -18 I am sure they will be addressed before the document leaves the WG.

During a recent conversation with the authors, I was left with the impression that my remaining comments on draft ...-17.txt would still be welcome.  Is that no longer the case?

Do you have an ETA to complete your review? As long as you can get this done pretty soon, I don’t see why your comments will not be welcome.

Thanks
Suresh

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 6 Dec 2018 15:47:08 -0800

Hello Dominique,

Please see a bit of follow-up below.

On 12/5/2018 7:56 AM, [email-masked] wrote:
> DB: The No-ACK mode is meant to support unidirectional links, 
> therefore we do not want to send control traffic in the reverse 
> direction. Besides, what would the Receiver-Abort report about that is 
> not an ACK ? This is No-ACK mode.

The receiver might have other reasons for an abort (out of memory, ..., ??).

>
> CEP2a: 8.4.2.  AK=Always, questioning "The tiles are not required to 
> be of uniform size.  Padding is kept toa minimum: only the last SCHC 
> Fragment is padded as needed."
> DB: The sender algorithm states that the Fragment messages are built 
> to carry one tile that is sized such that no padding is needed (except 
> for the last tile).

This is a good idea, of course. I think I was just pointing out that 
that padding should *always* be kept to a minimum.  And that such 
statements typically belong in a previous section about padding.

>
> CEP2b: 8.4.2.1 what is the rationale for "Each SCHC Fragment MUST 
> contain exactly one tile in its Payload."?
> DB: This is describing the old ACK-Always mode in the new SCHC F/R 
> parlance that defines the partitioning of the SCHC Packet into tiles.
> Since this mode does not support variable MTU, each Fragment message 
> carries as much data as it can with the given MTU, which we say is a tile.

O.K.  I think that last sentence also belongs in the text.  As best I 
can tell, it's not there now, but I might have missed something.

>
> CEP4: 8.4.2.1 In the situation described, Sender-Abort is not needed, 
> the receiver is already aborting : "if the current window is the last 
> one and the SCHC ACK indicates that all tiles were correctly received 
> yet integrity check was a failure, the fragment sender MUST send a 
> SCHC Sender-Abort, it MUST release all resource associated with 
> this SCHC Packet and it MAY exit with an error condition."
> DB: In fact, the receiver does not know that it has received all the 
> tiles until MIC is correct. It knows it has received a few tiles of 
> the last window, and that it has received the last tile, but it 
> doesn't know the index for the last tile (because the All-1 FCN is 
> used to indicate "last tile", not index). Therefore, it might be 
> missing some tiles in the last window but wouldn't know.
> Therefore, in the situation described (the receiver has indeed 
> received all tiles yet the MIC is wrong), the sender knows that the 
> situation is unrecoverable, while the receiver doesn't.

O.K.  Thanks for the explanation.  My intuition was not yet strong 
enough to figure that out, or I just missed it.  Or maybe other people 
would be similarly puzzled, I don't know.  Besides that, I somehow think 
that most fragment receivers are going to wait until they have all of 
the tiles, and not recompute the MIC over and over again every time they 
receive a tile.  Do they need to wait for Inactivity Timer to fire 
before deciding that no more fragments are forthcoming?

>
> CEP5: 8.4.2.2 "Entering an "acceptance phase", the receiver MUST first 
> clear the empty Bitmap for this window, then". It would be nice if you 
> would allow implementations to re-use bitmap structures.
> DB: Agreed. However, I fail to see how this sentence prevents it. To 
> me, clearing meant resetting the bits to zero, not disposing of the 
> structure.

I think the text as written above is good for that purpose.  It is 
slightly different than what was written in revision 17.

>
> CEP6 8.4.2.2 "Any received SCHC F/R message with a W bit different 
> from the local W bit MUST be silently ignored and discarded." Isn't 
> this *always* true?
> DB: This is not always true. For example, when the receiver has just 
> sent an ACK for a window, it might receive a fragment with the flipped 
> W bit (first tile of the next window),  or an ACK REQ with the current 
> W bit (if the ACK was lost). Both are valid and must be processed.

O.K.

>
> CEP7: 8.4.3 "No SCHC ACK is fed back by the fragment receiver for 
> windows that it knows have been fully received.".  Proposed change to 
> "No SCHC ACK is sent by the fragment receiver for windows for which 
> all tiles have been received."
> DB: There is a difference between the receiver having received all 
> tiles and the receiver knowing it. This only happens in the last 
> window. See my response to CEP4 above for the description of such a case.
> Furthermore, note that the receiver does not know it is processing the 
> last window until it receives an All-1 Fragment.

I can try.  How about:

"When the fragment receiver knows that a window has been fully received, 
it does not send SCHC ACK."

>
> CEP8: 8.4.3.1 "The fragment sender MAY send the last tile as the 
> Payload of an All-1 SCHC Fragment.". Proposed change to "The fragment 
> sender SHOULD send the last tile as the Payload of an All-1 SCHC 
> Fragment.".
> DB: We anticipate some technologies might be so constrained that the 
> MIC alone will barely fit in the minimal MTU, not leaving space for a 
> tile. Those technologies will likely send their last tile as part of a 
> Regular Fragment. MAY therefore seems more appropriate than SHOULD.

SHOULD means "do it unless you have a good reason not to do it". That 
seems pretty close to what you want.

> in ACK-Always mode, it is per Window.

I'll check, but if that distinction is not made explicit in the draft, I 
think your text above should be added.

>
> CEP10: 8.4.3.1 "otherwise,  if the SCHC ACK shows no missing tile at 
> the receiver, the sender MUST send a SCHC Sender-Abort, …". It seems 
> inappropriate to transmit an Abort for an already failed Window 
> transmission. Why is this needed?
> The sender knows something is unrecoverably wrong at the receiver, 
> while the receiver doesn't. Typically, the receiver's best guess would 
> be it is missing one or several tiles in the last window, but it can't 
> know for sure.

O.K.

>
> CEP11: 8.4.3.2 "From reception of an All-1 SCHC Fragment onward, a 
> receiver MUST check the integrity of the reassembled SCHC Packet at 
> least every time it prepares for sending a SCHC ACK for the last 
> window.". Proposed change to "After receiving an All-1 SCHC Fragment, 
> a receiver MUST…"
> DB: "from … onward" was meant to insist that it was not just at the 
> reception of the All-1 Fragment, but any time after the reception of 
> the All-1 Fragment until the end of reassembly of this SCHC Packet.

For me the wording using "After" sounds more clear.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 7 Dec 2018 07:14:08 -0800

Hello again Dominique,

I finally typed in the rest of my comments.  As noted elsewhere, I 
didn't fully review the state diagrams.  I suppose it is clear that they 
are informational and not normative.  Please let me know if you are 
interested in a closer review for them.  Maybe that should wait until 
after the next revision.

All of the comments in the attached file could be considered editorial, 
but some have to do with the use of "MAY" and for that reason might be 
considered technical.  I only show the differences since my previous 
comments.

Happy Holidays,
Charlie P.

On 12/5/2018 7:56 AM, [email-masked] wrote:
> Hello Charlie,
>
> Thanks so much for providing another round of comments. There are 
> greatly beneficial to producing a high quality –18 version of the 
> document.
> This mode does not support variable MTU size, therefore the tiles do 
> not have to be of uniform (small) size. They are not necessarily a 
> multiple of L2 Words, so Header mis-alignement is not an issue either.
>
> CEP3: 8.4.2.1 "All tiles with the number 0 in their window, as well as 
> the last tile, MUST be at least the size of an L2 Word.".
> DB: This was intended to meet the mandates that Regular Fragments MUST 
> be distinguishable by size from ACK REQs, and that All-1 Fragments 
> MUST be distinguishable by size from Sender-Abort.
> This statement is now deemed to be over-constraining (there are other 
> solutions to meet the same mandates), so we will remove 
> this statement in –18 and let implementers figure out how they meet 
> the mandates.
>
> De : lp-wan <[email-masked] <mailto:[email-masked]>> 
> on behalf of Charlie Perkins <[email-masked] 
> <mailto:[email-masked]>>
> À : "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> Objet : [lp-wan] My comments on 
> draft-ietf-lpwan-ipv6-static-context-hc-17 up until now
>
> Hello folks,
>
> Attached to this email, please find a file containing my comments on 
> draft-ietf-lpwan-ipv6-static-context-hc-17.txt.   Most of my 
> substantive comments are inserted as 'pretend-xml' comments prefixed 
> by "<!--  CEP".  Earlier I had sent about half of these comments to 
> the authors, thus my updated filename contains "cepB".  I also append 
> a diff file for my comments versus 
> draft-ietf-lpwan-ipv6-static-context-hc-17.txt, as well as the diff 
> file between these comments and my previous comments to the authors.  
> I believe the authors already accepted most of the comments I had sent 
> to them earlier.
>
> The great majority of the comments are editorial.  Some of the 
> comments would be construed as technical comments aimed at modifying 
> the strength of certain mandates, and reducing the chance for 
> misinterpretation.
>
> Since I am in a hurry to get these comments into consideration, I had 
> to stop reviewing at page 50.   I would like to provide comments for 
> the remainder of the document.  Later today I will list the most 
> important questions and comments I have about the document.
>
>>> On Nov 28, 2018, at 1:50 PM, Charlie Perkins 
>>> <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Hello Pascal,
>>>
>>> I noticed the word "now".  Besides that, predicting that an 
>>> unpublished document would conclude the WG Last Call process seems 
>>> wrong to me.  Of course we can hope for the best.
>>>
>> This is certainly conditional on the issues being addressed by -18. 
>> If you do find open issues in -18 I am sure they will be addressed 
>> before the document leaves the WG.
>>>
>>> During a recent conversation with the authors, I was left with the 
>>> impression that my remaining comments on draft ...-17.txt would 
>>> still be welcome.  Is that no longer the case?
>>>
>> Do you have an ETA to complete your review? As long as you can get 
>> this done pretty soon, I don’t see why your comments will not be welcome.
>>
>> Thanks
>> Suresh
>>
>> [email-masked]://www.ietf.org/mailman/listinfo/lp-wan
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 09:36:40 +0000

Hello Charlie,

Thanks for this round of comments and suggestions. This is a huge help!
I have a question.
You commented that RFC 3385, 6282, 6936 and 8200 are listed in our draft in the Informative References section while they "seem to be a normative reference" (sic).
I'm unclear on this point: should a reference be put in the Informative or Normative sections because of their use in the protocol being defined or because of their own status (Standards Track, etc)?
For example, 6282 is mentioned as a mere example of what other standards do with UDP checksum, and SCHC does not depend on 6LoWPAN.
In any case, I think at least 8200 deserves to be normative for us, because our section on UDP Checksum complies with it and even derives from it.
For the other ones, I need to check.
Can you please provide your view on the point above (normative by own status or by virtue of use in the draft at hand)?
Best regards

Dominique

De : Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date : Friday 7 December 2018 16:14
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] My comments on draft-ietf-lpwan-ipv6-static-context-hc-17 up until now

Hello again Dominique,

I finally typed in the rest of my comments.  As noted elsewhere, I didn't fully review the state diagrams.  I suppose it is clear that they are informational and not normative.  Please let me know if you are interested in a closer review for them.  Maybe that should wait until after the next revision.

All of the comments in the attached file could be considered editorial, but some have to do with the use of "MAY" and for that reason might be considered technical.  I only show the differences since my previous comments.

Happy Holidays,
Charlie P.

On 12/5/2018 7:56 AM, [email-masked]<mailto:[email-masked]> wrote:
Hello Charlie,

Dominique

Hello folks,

Regards,
Charlie P.

Hello Pascal,

Thanks
Suresh

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 12 Dec 2018 10:55:54 +0100

Hello,

Adding to Dominique's message, we may want to consider the IESG statement
on Informative and Normative references:
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/

I understand that Dominique's view is aligned with the IESG statement above.

Cheers,

Carles

> You commented that RFC 3385, 6282, 6936 and 8200 are listed in our draft
> in the Informative References section while they "seem to be a normative
> reference" (sic).
> I'm unclear on this point: should a reference be put in the Informative or
> Normative sections because of their use in the protocol being defined or
> because of their own status (Standards Track, etc)?
> For example, 6282 is mentioned as a mere example of what other standards
> do with UDP checksum, and SCHC does not depend on 6LoWPAN.
> In any case, I think at least 8200 deserves to be normative for us,
> because our section on UDP Checksum complies with it and even derives from
> it.
> Can you please provide your view on the point above (normative by own
> status or by virtue of use in the draft at hand)?
> Best regards
>
> Dominique
>
> De : Charlie Perkins
> <[email-masked]<mailto:[email-masked]>>
> À : Dominique Barthel
> <[email-masked]<mailto:[email-masked]>>
> Cc : "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> Objet : Re: [lp-wan] My comments on
> I finally typed in the rest of my comments.  As noted elsewhere, I didn't
> fully review the state diagrams.  I suppose it is clear that they are
> informational and not normative.  Please let me know if you are interested
> in a closer review for them.  Maybe that should wait until after the next
> revision.
>