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

> On Dec 1, 2022, at 7:17 AM, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
> 
> Dear authors,
> 
> It is now more than 2 weeks after this AD review, and I have seen neither a revised IETF draft nor a reply.
> 
> As some authors are new at the IETF: the IETF publication process is currently blocked at this stage until an action is taken by the authors :-( even if,  as far as I can tell, the comments below are easy and actionable.
> 
> When can we expect a revised I-D and/or a reply to address all the points below ?
> 
> Regards
> 
> -éric
> 
> 
> On 16/11/2022, 12:01, "lp-wan on behalf of Eric Vyncke (evyncke)" <lp-wan-bounces@ietf.org on behalf of evyncke=40cisco.com@dmarc.ietf.org> wrote:
> 
>    Dear authors, dear shepherd,
> 
>    First of all, thank you all (including the WG) for the work done on this document.
> 
>    As usual, before requesting the IETF last call on your document, I have done my own AD review in order to facilitate the next steps in the publication process. I am expecting an action or a reply on all the points below 😊
> 
>    I hope that this will help
> 
>    Regards
> 
>    -éric
> 
>    Critical
>    ---------
> 
>    Shepherd review point 11, "Proposed Standard, which makes sense for such content." Is not really an explanation __ Ana, can you update with something like "to ensure interoperation among implementations"  ?
> 
>    Shepherd review point 18, please indicate the status and roadmap of the compound document.
> 
>    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.

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

>    S 5 is it 'reply attacks' or 'replay attacks' ?

We fixed to replay attacks.

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

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

> 
>    Comments
>    --------------
> 
>    Abstract, the first paragraph sounds like a marketing statement and brings little value. Suggest removing it and expand SCHC in the remaining paragraph.

New abstract is provided in new version.

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

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

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

>    S 3.1: "SCHC Compressor/Decompressor (SCHC C/D + F/R)" sounds incomplete -- missing F/R expansion -- Moreover the C/D F/R were already expanded.

We changed to be more clear and removed the term compressor/decompressor, and only refer to Compression/Decompression (C/D). This way we think is more clear.

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

>    S 3.4: expand / explain FCN at first use (or at least add a reference)

We modify the text to expand / explain the FCN.

> 
>    S 3.6: "Since only Uplink messages/fragments" but what about Downlink ? Or this part moved to the uplink part ? S 3.6.1
> 

Well noted, Sigfox protects messages in uplink and downlink.

>    S 3.6 "The L2 Word Size used by Sigfox is 1 byte (8 bits)." Appears out of the blue here ...
> 

We have moved it to the end of section 3.1 Network Architecture

>    S 3.6.1 unsure whether the text "Data packets are self-... transmitting a data packet." Brings any added value
> 

We have added some information to the before sentence.

>    S 3.7.1.3. should there be an explanation on when to send a sender-abort ? Explanation comes only in S 3.8 (either put a forward reference or move S 3.8 before ?)
> 

We have section 3.8 and 3.9 before section 3.6.1 (of version 13)

>    S 3.7 I really like all the packet descriptions, a little too late to change the I-D, but it would help the reader to have those figures in the relevant parts of section 3.6. I suggest to at least add a forward reference in section 3.6 to those figures.
> 

We have added forward references to the fragments examples and fragmentation sequence examples when the fragmentation mode are presented.

>    S 3.17 did I say that I like those descriptions ? OTOH, in which aspects are they Sigfox specific ? Aren't they RFC 8724 examples ?

Section 3.7 presents examples on the parametrization of the fields provided by RFC8724. In RFC8724, messages are generic while in section 3.7 we actually give the exact values of the different fields involved.

> 
>    S 5 " generated and sent by the device" seems to apply only to the uplink part. What about downlink ?
> 

We have added the network, representing downlink.

>    S 5 s/ at the application level/ at the application layer/
> 

Done.
> 
> 
>    Nits
>    -----
>    In English, "e.g." is always followed by a comma as in "e.g.,"
> 
Noted and fixed.

>    Same for "i.e."

Noted and fixed.
> 
>    s/ 0 bits/ 0 bit/ ?
Fixed.

> 
>    S 3.8 and S 3.9 should the leading '*' be removed ?
Fixed.
> 
>    Figure 32, suggest to remove "--->" after the breaking "X"

Fixed. We have follow the same logic in all figures.

> 
>    _______________________________________________
>    lp-wan mailing list
>    lp-wan@ietf.org
>    https://www.ietf.org/mailman/listinfo/lp-wan
> 