Re: [lp-wan] AD review for draft-ietf-lpwan-schc-over-sigfox-13

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you very much, Sergio.

As you have seen by now, I have requested an IETF wide Last Call. If any comments by reviewer can be addressed by the authors before the end of the year, then I will put this draft to the IESG telechat for early January 2023.

Regards

-éric


From: lp-wan <[e-mail]> on behalf of Sergio Aguilar Romero <[e-mail]>
Date: Tuesday, 6 December 2022 at 03:34
To: Eric Vyncke <[e-mail]>
Cc: lp-wan <[e-mail]>, Juan Carlos Zuniga <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [lp-wan] AD review for draft-ietf-lpwan-schc-over-sigfox-13

Hello Eric,

Thanks for your review.

Please find our comments below.

We have uploaded a new version of the draft.

Best regards,

Authors SCHC over Sigfox draft


On Dec 5, 2022, at 8:03 AM, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>> wrote:

Sergio et al.,

Thanks for your email and the revision -14 of the I-D. Please look for EV> below, I am expecting a reply on those comments. Sorry to add another pass but the earlier in the process the changes are done, the faster the process.

Regards

-éric

From: Sergio Aguilar Romero <[e-mail]<mailto:[e-mail]>>
Date: Saturday, 3 December 2022 at 13:31
To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>
Cc: lp-wan <[e-mail]<mailto:[e-mail]>>, Juan Carlos Zuniga <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lp-wan] AD review for draft-ietf-lpwan-schc-over-sigfox-13

Hello Erick,

Sorry the delay in the response.

We have published a new version with the corrections.

Please find our responses below.

Thanks for your review.

Best regards,

Authors SCHC over Sigfox draft

----- %< ------ some text elided ----- %< ---------
   Critical
   ---------


   Generic about "RECOMMENDED" as an adjective, most RFC prefers to use "SHOULD" as a verb (but they are equivalent). *BUT* when used, in accordance to RFC 2119, there should be an explanation on *when* not following is acceptable or a description of the consequences of not following the recommendation.

We have removed the RECOMMENDED and changed for SHOULD.

EV> I was probably not clear... but, when using SHOULD/RECOMMENDED, the expectation is that the consequence of not following the SHOULD are also explained (or giving a use case when it is probably OK to deviate). See RFC 2119:


     " 3<https://www.rfc-editor.org/rfc/rfc2119.html#section-3>. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."


We have added some text after the SHOULD explaining the implications. In some cases the SHOULD was modified to a MUST, as it is considered that it must not be ignored.




   S 3.10 " padding MUST be used with bits equal to  0." What is the expected receiver behavior ?

We have added a line at the end of section 3.10 (now 3.8). The receiver must remove the padding bits.

EV> " The receiver MUST removed the added padding bits." Should probably be "remove" and the sentence is a little ambiguous, should the text add " before passing the payload to the application" ? or something similar ?

Thanks, we have added that the receiver must remove the added padding bits before the reasembly process.



   S 5 is it "integrity key" or "authentication key" ?

We change the confidentiality to authentication key. There are two keys integrity and authentication.

EV> to be honest, I am still puzzled by the text about using an authentication key for confidentiality...

We have review the paragraphs and notice that it should be encryption key. The encryption key is used to perform payload encryption. The authentication is related with a code, explained in the first paragraph of S 5.




   Comments
   --------------



   About Sigfox, the introduction explains simply what SCHC is, but does not really explain what Sigfox is... A couple of paragraphs will be welcome (in addition or replacing the text in section 3.1)

We added an explanation at the end of section 3

EV> the text is nice but why not adding it in the introduction / section 1 ?

We have move the tex to the introduction.





   Figure 1, be specific that External Network is IPv6-based

We have added IP-based network, as it can be current internet, i.e.,

EV> unsure what you meant in the above sentence ;-)
EV> but, the "IP-based network" should be in the legend below the figure for clarity and consistency


We meant,
“As it can be current intenet, i.e., a server api."

We have added to the legend: External IP-based Network.



   Figure 2 does not seem to bring a lot of value and does not look the same as similar IETF messages, suggest to remove it

The idea behind figure 2 is no indicate that SCHC Messages (SCHC Packets or Fragments) are sent in the Sigfox payload (differently as in LoRaWAN where the FPort is used for the RuleID). Therefore to make it clear that no Sigfox header are reused as part of the SCHC Fragments, this figure was added.

We have make the figure similar to figure 5 of RFC9011.

Let us know if still need to be removed.

EV> this was only a suggestion ;-) up to the authors to decide whether to keep it

Thanks for all suggestions! We may leave the figure for clarity.