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

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

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]>
Date: Saturday, 3 December 2022 at 13:31
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 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."

   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 ?

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


   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 ?

   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

   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