Hello Bo and all, Happy holidays. We have published version 19 with all fixed of this review. Thanks for your review and comments. Please find our comments below. Best regards, Authors SCHC over Sigfox draft > On Dec 24, 2022, at 4:50 AM, Bo Wu via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Bo Wu > Review result: Has Nits > > Hi authors, > > I am the assigned Opsdir reviewer. > > Summary: This is a standard track publication. This document defines a profile > of SCHC (RFC 8724) for use in Sigfox networks and provides parameter values and > modes of operation. > > Major issues:None > > Minor issues:Yes > > 1. Section 1： > Sigfox is an LPWAN technology that offers energy-efficient > connectivity for devices at a very low cost. Sigfox brings a > worldwide network composed of Base Stations that receive short (12 > bytes) uplink messages sent by devices over the long-range Sigfox > radio protocol. > > This paragraph gives an overview of Sigfox and also gives some details, such as > 12 bytes uplink messages. It would be clearer that a reference of Sigfox > specification can be provided. Regarding 12 bytes uplink messages, why is it > emphasized here? This is not mentioned in the sections 3.2 uplink and Section > 3.8. Padding says 12 bytes payload. The same applies to 8 bytes downlink > messages. > We have added the reference to the introduction. We believed that the 12/8-byte message sizes are a very singular characteristic of Sigfox. We have added information in section 3.2, 3.3 and 3.8 to make it more clear. > 2. Section 2： > It is suggested that Terminology can be added, such as RSSI, Dtag needs some > definition. > RSSI is expanded in first used. DTag is defined in RFC8724. > 3. Section 3： > About "Provisioning protocol", can you give an example? Is this suggesting > Netconf protocol? > How the Rules are provision is out of the scope of this document and is part of current work in the LPWAN WG in the LPWAN Architecture draft, which mentions: "the use of several protocols for rule management, such as NETCONF[RFC6241], RESTCONF[RFC8040], and CORECONF[I-D.ietf-core-comi]" > 4. Section 3.1 > The terms used in the architecture figure 1 and the document are little > confusing. > > In the figure 1, only sigfox device and Sigfox BS is marked, are the other > network entities not part of sigfox network? Maybe the scope of the sigfox > network can be provided. It is suggested to be consistent that Network Gateway > (NGW) is called the Sigfox cloud-based Network or cloud-based Sigfox Core > Network? > We changed as part of the review process from Sigfox Network to Network Gateway (NGW). We have added below the NGW a label of Sigfox Cloud. Let us know if you think it provides the scope of the Sigfox network. > 5. Section 3.4 SCHC-ACK on Downlink > Section 3.3 Downlink and Section 3.4 are parallel sections. Should section 3.4 > be subsection of Section 3.3? > We have mode section 3.4 as a subsection of section 3.3. > 6. Section 3.6.1.5 All-1 and RCS behaviour > It is better to add a complete title name, e.g. All-1 SCHC Fragments? > We have modified the title. > Minor Nits: > > 7.Abstract > s/The present document/The document > We believed it is better understood “The present document” to avoid mistakes with RFC8724. > 8. Consistency in section title > s/3.6.1.1 SCHC-Sender Abort/ 3.6.1.1 SCHC Sender-Abort Fixed. > 3.7 SCHC-over-Sigfox F/R Message Formats –> SCHC over Sigfox F/R Message Formats Fixed. > 3.7.3.4. SCHC Sender-Abort Messages-> SCHC Sender-Abort Message format Fixed > 3.7.3.5 SCHC Receiver-Abort Message -> SCHC Receiver-Abort Message format Fixed. > The same applies to:: > 3.7.4.4. SCHC Sender-Abort Messages Fixed. > 3.7.4.4. SCHC Sender-Abort Messages Fixed. > 3.7.5.4. SCHC Sender-Abort Messages Fixed. > 3.7.5.5. SCHC Receiver-Abort Message Fixed. > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
