Re: [auth48] AUTH48: RFC-to-be 9391 <draft-ietf-lpwan-schc-over-nbiot-15> for your review

[Ana Minaburo <[e-mail]>]

Hello Karen,

Thank you very much for all your corrections. I approve this RFC for
publication.

Have a nice day!
Ana

On Wed, Apr 12, 2023 at 12:40 AM Karen Moore <[e-mail]> wrote:

> Hello Ana,
>
> Thank you for your reply.  We have updated our files based on your
> responses.
>
> FILES
> The updated XML file is here:
>  https://www.rfc-editor.org/authors/rfc9391.xml
>
> The updated output files are here:
>  https://www.rfc-editor.org/authors/rfc9391.txt
>  https://www.rfc-editor.org/authors/rfc9391.pdf
>  https://www.rfc-editor.org/authors/rfc9391.html
>
> This diff file shows all changes made during AUTH48:
>  https://www.rfc-editor.org/authors/rfc9391-auth48diff.html
>
> This diff file shows all changes made to date:
>  https://www.rfc-editor.org/authors/rfc9391-diff.html
>
> Note that it may be necessary for you to refresh your browser to view the
> most recent version. Please review the document carefully to ensure
> satisfaction as we do not make changes once it has been published as an RFC.
>
> Please contact us with any further updates or with your approval of the
> document in its current form.  We will await approvals from each author
> prior to moving forward in the publication process.
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9391
>
> Thank you,
>
> RFC Editor/kc
>
>
> > On Apr 11, 2023, at 6:16 AM, Ana Minaburo <[e-mail]> wrote:
> >
> > Dear RFC Editor,
> >
> > Thank you for your inputs, see my comments below.
> >
> > Ana
> >
> > On Sat, Apr 8, 2023 at 2:32 AM <[e-mail]> wrote:
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >
> > 1) <!--[rfced] To match the document title more closely, we updated the
> > short title that spans the header of the PDF as follows.  Please
> > let us know of any objections.
> >
> > Original:
> >    LPWAN SCHC NB-IoT
> >
> > Current:
> >    SCHC over NB-IoT
> > -->
> > [Ana] Agree: SCHC over NB-IoT
> >
> >
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
> >
> > [Ana] SCHC, Header Compression, Fragmentation, 3GPP, 5G, IoT, Sensor
> network, cellular network, LTE, LTE-M.
> >
> > 3) <!--[rfced] We believe that Section 5.1 provides more than 1 scenario,
> > so may we update "a scenario" to "scenarios" in this sentence for
> > clarity and "standard" to "normative" for consistency with the
> > section title?
> > [Ana] Yes, Section 5.1 Has one global scenario with two different ways
> to use it.
> >
> > Original:
> >    This document has two parts, a standard end-to-end scenario
> >    describing how any application must use SCHC over the 3GPP
> >    public service.  And informational scenarios about how 3GPP
> >    could use SCHC in their protocol stack network.
> >
> > Perhaps:
> >    This document has two parts: normative end-to-end scenarios
> >    describing how any application must use SCHC over the 3GPP
> >    public service and informational scenarios about how 3GPP
> >    could use SCHC in their protocol stack network.
> > -->
> >
> > [Ana]  Agree (perhaps)
> >
> >
> > 4) <!-- [rfced] To make the terminology list complete and parallel, may
> > we add definitions for the following terms? If so, please provide
> > the desired text.
> >
> >    Device - User Equipment (Dev-UE)
> >    Data over Non-Access Stratum (DoNAS)
> >    Hybrid Automatic Repeat Request (HARQ)
> >    Non-Access Stratum (NAS)
> >    Network Gateway - CIoT Serving Gateway Node (NGW-CSGN)
> >    Non-IP Data Delivery (NIDD)
> > -->
> > [Ana] Yes, we are using the RFC8376 Terminology.
> >
> > Device - User Equipment (Dev-UE) as defined in RFC8376 section 3.
> >    Data over Non-Access Stratum (DoNAS). Sending User Data within
> signalling messages over the NAS functional layer
> >    Hybrid Automatic Repeat Request (HARQ) It is a combination of
> high-rate forward error correction (FEC) and automatic repeat request (ARQ)
> error-control.
> >    Non-Access Stratum (NAS). Functional layer for signalling messages,
> it establishes communication sessions and maintain the communication while
> the user moves.
> >    Network Gateway - CIoT Serving Gateway Node (NGW-CSGN) as defined in
> RFC8376 section 3.
> >    Non-IP Data Delivery (NIDD). End to End communication between the UE
> and the Application Server.
> >
> >
> >
> > 5) <!--[rfced] For the description of "NGW-PGW" in Section 3, is it an
> > interface between the internal and external network?  Please
> > clarify.
> >
> > Original:
> >    NGW-PGW. Network Gateway - Packet Data Network Gateway.
> >    An interface between the internal with the external network.
> >
> > Perhaps:
> >    Network Gateway - Packet Data Network Gateway (NGW-PGW):
> >    An interface between the internal and external network.
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 6) <!-- [rfced] May we update this sentence as shown below to
> > match use in other RFCs (i.e., "path connectivity" instead of
> > "Connectivity path" and "device monitoring" instead of "Device
> > Monitoring")?
> >
> > Original:
> >    The main functions of the NGW-SCEF are Connectivity path
> >    and Device Monitoring.
> >
> > Perhaps:
> >    The main functions of the NGW-SCEF are path connectivity
> >    and device monitoring.
> > -->
> >
> > [Ana] Agree (perhaps)
> >
> > 7) <!-- [rfced] To avoid the use of incomplete sentence structures, may
> we update
> > the use cases (First, Second, third) to complete sentences as follows?
> >
> > Original:
> >    This document identifies the use cases of SCHC over the NB-IoT
> >    architecture.
> >
> >    First, the radio transmission where, see Section 5.2.1, the Dev-UE
> >    and the RGW-eNB can use the SCHC functionalities.
> >
> >    Second, the packets transmitted over the control path can also use
> >    SCHC when the transmission goes over the NGW-MME or NGW-SCEF.  See
> >    Section 5.2.2.
> >
> >    These two use cases are also valid for any 3GPP architecture and not
> >    only for NB-IoT.  And as the 3GPP internal network is involved, they
> >    have been put in the informational part of this section.
> >
> >    And third, over the SCHC over Non-IP Data Delivery (NIDD) connection
> >    or at least up to the operator network edge, see Section 5.1.1.
> >
> > Suggested:
> >    This document identifies the use cases of SCHC over the NB-IoT
> >    architecture.
> >
> >    The first use case is of the radio transmission (see Section 5.2.1)
> >    where the Dev-UE and the RGW-eNB can use the SCHC functionalities.
> >
> >    The second is where the packets transmitted over the control path can
> >    also use SCHC when the transmission goes over the NGW-MME or NGW-
> >    SCEF (see Section 5.2.2).
> >
> >    These two use cases are also valid for any 3GPP architecture and not
> >    only for NB-IoT.  And as the 3GPP internal network is involved, they
> >    have been put in the informational part of this section.
> >
> >    And the third covers the SCHC over Non-IP Data Delivery (NIDD)
> >    connection or at least up to the operator network edge (see
> >    Section 5.1.1).
> > -->
> > [Ana] Agree suggested
> >
> >
> > 8) <!--[rfced] Would the titles of Sections 5.1 and 5.2 be clearer if
> > "Part" was updated as "Scenarios"? Please review and let us know
> > your preference.
> >
> > Original:
> >    5.1  Normative Part
> >
> >    5.2  Informational Part
> >
> > Perhaps:
> >    5.1  Normative Scenarios
> >
> >    5.2  Informational Scenarios
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 9) <!-- [rfced] For clarity and easier readability, we split this
> > sentence into two sentences. Please clarify if "for use with the
> > operators" is correct or if it should perhaps be "for use by
> > operators".
> >
> > Original:
> >    The RuleID field size may range
> >    from 2 bits, resulting in 4 rules to an 8-bit value that would yield
> >    up to 256 rules that can be used with the operators and seems quite a
> >    reasonable maximum limit even for a device acting as a NAT.
> >
> > Current:
> >    The RuleID field size may range
> >    from 2 bits, resulting in 4 rules, to an 8-bit value, yielding up to
> >    256 rules for use with the operators. A 256-rule maximum limit seems
> >    to be quite reasonable, even for a device acting as a NAT.
> >
> > Perhaps:
> >    The RuleID field size may range
> >    from 2 bits, resulting in 4 rules, to an 8-bit value, yielding up to
> >    256 rules for use by operators. A 256-rule maximum limit seems
> >    to be quite reasonable, even for a device acting as a NAT.
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 10) <!-- [rfced] FYI: We have used the <sup> element for superscript
> > in this document. You can view how it looks in Section 5.1.1.2.
> >
> > Note: In the HTML and PDF, it appears as superscript. In the text output,
> > <sup> generates "2^(N-1)".
> >
> > Original:
> >    *  WINDOW_SIZE of 2^N-1 is RECOMMENDED.
> >
> > Current (in the text output):
> >    *  WINDOW_SIZE of 2^(N-1) is RECOMMENDED.
> > -->
> > [Ana] NEW: WINDOW_SIZE of (2^N) -1 is RECOMMENDED.
> >
> >
> > 11) <!--[rfced] Regarding Table 10.5.163a of [TS24008], please confirm if
> > units of N can only be "1 hour or 10 hours" or if N can be a range of
> > "1 hour to 10 hours".
> >
> > Original:
> >    Table 10.5.163a in [TS24008] specifies a range for the radio timers
> >    as N to 3N in increments of one where the units of N can be 1 hour
> >    or 10 hours.
> >
> > Perhaps:
> >    Table 10.5.163a in [TS24008] specifies a range for the radio timers
> >    as N to 3N in increments of 1 where the units of N can be 1 hour
> >    to 10 hours.
> > -->
> > [Ana] The Timer is incremented by a multiple of 1 hour or a multiple of
> 10 hours
> >  NEW: Table 10.5.163a in [TS24008] defines the radio timers values with
> units incrementing by N. The units of N can be 1 hour
> >    or 10 hours. The range used for IoT is of N to 3N, where N increments
> by one.
> >
> >
> > 12) <!--[rfced] Please clarify the following titles. Are SCHC entities
> > placed over the radio link (and over DoNAS)? If so, please let us
> > know if option A or B may capture the intended meaning.
> >
> > Original:
> >    5.2.1.1.  SCHC Entities Placing over the Radio Link
> >    5.2.2.1.  SCHC Entities Placing over DoNAS
> >
> > Perhaps:
> > A) 5.2.1.1.  SCHC Entity Placement over the Radio Link
> >    5.2.2.1.  SCHC Entity Placement over DoNAS
> >
> > or
> >
> > B) 5.2.1.1   Placing SCHC Entities over the Radio Link
> >    5.2.2.1   Placing SCHC Entities over DoNAS
> > -->
> > [Ana] Agree B
> >
> >
> > 13) <!-- [rfced] We are unable to parse this sentence, specifically
> >  "unless for". Is fragmentation taken care of "for" or "except
> >  for" the TM? Please let us know how we may update this for
> >  clarity.
> >
> > Original:
> >    The RLC layer takes care of fragmentation unless for the
> >    Transparent Mode.
> >
> > Perhaps:
> > A) The RLC layer takes care of fragmentation for the TM.
> >
> > or
> >
> > B) The RLC layer takes care of fragmentation except for the TM.
> > -->
> > [Ana] Agree B
> >
> >
> > 14) <!--[rfced] Is "Transparent Mode transmission mode" correct, or
> should
> > it be "Transparent Mode transmission" (i.e., remove "mode" to
> > avoid redundancy)?
> > [Ana] Yes, Transparent Mode transmission is correct
> >
> > Original:
> >    However, if other protocol overhead optimizations are targeted
> >    for NB-IoT traffic, SCHC fragmentation may be used for
> >    TM transmission mode in the future.
> >
> > Perhaps:
> >    However, if other protocol overhead optimizations are targeted
> >    for NB-IoT traffic, SCHC fragmentation may be used for
> >    TM transmission in the future.
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 15) <!-- [rfced] How may we clarify how the last part of the sentence
> > (starting at "and a good resource optimization...") relates to
> > the rest of the sentence? Note that there is similar text in
> > Appendix B.
> >
> > Original:
> >    Depending on the size of buffered data to transmit,
> >    the Dev-UE might deploy the connected mode transmissions
> >    instead, limiting and controlling the DoNAS transmissions to
> >    predefined thresholds and a good resource optimization balance for
> >    the terminal and the network.
> >
> > Perhaps:
> >    Depending on the size of buffered data to be transmitted,
> >    the Dev-UE might deploy the connected mode transmissions
> >    instead, which would limit and control the DoNAS
> >    transmissions to predefined thresholds and would be a good
> >    resource optimization balance for the terminal and the network.
> > -->
> >   [Ana] NEW: Depending on the size of the buffered data to be
> transmitted,
> > the Dev-UE might deploy the connected mode transmission instead.
> > The connected mode would limit and control the DoNAS transmissions to
> predefined thresholds,
> > and it would be a good resource optimization balance for the terminal
> and the network.
> >
> >
> > 16) <!--[rfced] Since RFC 5795 and [TS36323] both discuss "ROHC", we
> moved
> > "operation" before the citations as shown below.  If that is not
> > correct, please let us know. Also, should "has made for" be "has
> > been made for" or other for clarity?
> >
> > Original:
> >    It will configure SCHC and the static context distribution
> >    as it has made for ROHC [RFC5795] operation [TS36323].
> >
> > Current:
> >    It will configure SCHC and the static context distribution
> >    as it has made for ROHC operation [RFC5795] [TS36323].
> >
> > Perhaps:
> >    It will configure SCHC and the static context distribution
> >    as it has been made for ROHC operation [RFC5795] [TS36323].
> > -->
> >    [Ana] Agree (perhaps)
> >
> >
> > 17) <!-- [rfced] How may we clarify who/what needs to "get more rules to
> > deal with each case"? Also, would "apply" or "develop" more rules
> > perhaps be clearer than "get" more rules?
> >
> > Original:
> >    The use of IPv6 and IPv4 may force to get more rules
> >    to deal with each case.
> >
> > Perhaps:
> >    The use of IPv6 and IPv4 may force the operator to
> >    develop more rules to deal with each case.
> > -->
> >   [Ana] Agree (perhaps)
> >
> >
> > 18) <!-- [rfced] For reference [3GPP-R15], is the intention to link to
> the
> > 3GPP homepage or directly to Release 15? If the latter, may we
> > update the title to "Release 15" and the URL to
> > "https://www.3gpp.org/specifications-technologies/releases/release-15"?
> >
> > Original:
> >    [_3GPPR15]  3GPP, "The Mobile Broadband Standard", 2019,
> >                <https://www.3gpp.org/release-15>.
> >
> > Perhaps:
> >    [R15-3GPP]  3GPP, "Release 15", April 2019,
> >                <https://www.3gpp.org/specifications-technologies/
> >                releases/release-15>.
> > -->
> >   [Ana] Agree (perhaps)
> >
> >
> > 19) <!-- [rfced] The titles of the following references do not match the
> > titles of the corresponding documents in the zip files. We have
> > updated the titles to match as shown below; please review and let
> > us know if any further updates are needed.
> >
> > A)
> > Original:
> >    [TR24301]  3GPP, "Evolved Universal Terrestrial Radio Access
> >               (E-UTRA); Medium Access Control (MAC) protocol
> >               specification", 2019, <https://www.3gpp.org/ftp//Specs/
> >               archive/24_series/24.301/24301-f80.zip>.
> >
> > Current:
> >    [TR24301]  3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
> >               Packet System (EPS); Stage 3", 3GPP TS 24.301 V15.8.0,
> >               December 2019, <https://www.3gpp.org/ftp//Specs/
> >               archive/24_series/24.301/24301-f80.zip>.
> >
> > B)
> > Original:
> >    [TS23222]  3GPP, "Common API Framework for 3GPP Northbound APIs",
> >               2022, <https://www.3gpp.org/ftp/Specs/
> >               archive/23_series/23.222/23222-f60.zip>.
> >
> > Current:
> >    [TS23222]  3GPP, "Functional architecture and information flows to
> >               support Common API Framework for 3GPP Northbound APIs;
> >               Stage 2", 3GPP TS 23.222 V15.6.0, September 2022,
> >               <https://www.3gpp.org/ftp/Specs/
> >               archive/23_series/23.222/23222-f60.zip>.
> >
> > C)
> > Original:
> >    [TS24008]  3GPP, "Mobile radio interface layer 3 specification.",
> >               2018, <https://www.3gpp.org/ftp//Specs/
> >               archive/24_series/24.008/24008-f50.zip>.
> >
> > Current:
> >    [TS24008]  3GPP, "Mobile radio interface Layer 3 specification; Core
> >               network protocols; Stage 3", 3GPP TS 24.008 V15.5.0,
> >               December 2018, <https://www.3gpp.org/ftp//Specs/
> >               archive/24_series/24.008/24008-f50.zip>.
> > -->
> >   [Ana] Agree (all currents)
> >
> >
> > 20) <!-- [rfced] FYI: As shown below, we moved the citations from the
> > section titles to the corresponding section body text so that
> > the reader is given clickable links.
> >
> > Original:
> > A.1.  Packet Data Convergence Protocol (PDCP) [TS36323]
> >
> >    Each of the Radio Bearers (RB) is associated with one PDCP
> >    entity.
> >
> > Current:
> > A.1.  Packet Data Convergence Protocol (PDCP)
> >
> >    Each of the Radio Bearers (RBs) is associated with one PDCP
> >    entity [TS36323].
> >
> > ...
> > Original:
> > A.2.  Radio Link Protocol (RLC) [TS36322]
> >
> >    RLC is a layer-2 protocol that operates between the UE and
> >    the base station (eNB).
> >
> > Current:
> > A.2.  Radio Link Protocol (RLC)
> >
> >    RLC [TS36322] is a Layer 2 protocol that operates between
> >    the UE and the base station (eNB).
> >
> > ...
> > Original:
> > A.3.  Medium Access Control (MAC) [TR36321]
> >
> >    MAC provides a mapping between the higher layers abstraction called
> >    Logical Channels comprised by the previously described protocols to
> >    the Physical layer channels (transport channels).
> >
> > Current:
> > A.3.  Medium Access Control (MAC)
> >
> >    MAC [TR36321] provides a mapping between the higher layers
> >    abstraction called Logical Channels comprised by the previously
> >    described protocols to the Physical layer channels (transport
> >    channels).
> > -->
> >   [Ana] Agree (current)
> >
> >
> > 21) <!-- [rfced] Does "on top of" mean that the reliability service is
> > physically on top of the lower-layer service, or does this
> > instance of "on top of" mean "in addition to"?
> >
> > Original:
> >    *  Acknowledged Mode (AM).  In addition to the same functions
> >       supported by UM, this mode also adds a moving windows-based
> >       reliability service on top of the lower layer services.
> >
> > Perhaps:
> >    *  Acknowledged Mode (AM)
> >
> >       In addition to the same functions supported by UM, this mode also
> >       adds a moving windows-based reliability service in addition to the
> >       lower-layer services.
> > -->
> >   [Ana] The AM services are physically on top of the lower-layer
> services.
> >
> >
> > 22) <!-- [rfced] We would like to update this sentence to clarify what
> > the acknowledgment reports are called. Also, please clarify if
> > bidirectional communication is required to "exchange" trigger
> > retransmissions (option A) or to "trigger" retransmissions
> > (option B).
> >
> > Original:
> >    It also supports re-segmentation, and it requires bidirectional
> >    communication to exchange acknowledgment reports called RLC Status
> >    Report and the trigger retransmissions.
> >
> > Perhaps:
> > A) It also supports re-segmentation, and it requires bidirectional
> >    communication to exchange acknowledgment reports, called RLC
> >    Status Reports, and trigger retransmissions.
> >
> > or
> >
> > B) It also supports re-segmentation, and it requires bidirectional
> >    communication to exchange acknowledgment reports, called RLC
> >    Status Reports, and to trigger retransmissions.
> > -->
> >
> >  [Ana] The Status Report is used to trigger the retransmission. I agree
> with option B
> >
> > 23) <!-- [rfced] FYI: We updated this sentence as shown below for clarity
> > by enclosing the description of the Logical Channels in
> > parentheses and changing "to" to "and". Please let us know of any
> > objections.
> >
> > Original:
> >    MAC provides a mapping between the higher layers abstraction called
> >    Logical Channels comprised by the previously described protocols to
> >    the Physical layer channels (transport channels).
> >
> > Current:
> >    MAC provides a mapping between the higher layers abstraction
> >    called Logical Channels (which are comprised by the previously
> >    described protocols) and the Physical layer channels (transport
> >    channels).
> > -->
> > [Ana] Agree (current)
> >
> >
> > 24) <!--[rfced] Does "what" refer to the "packets"? If so, may we update
> > "what" to "which ones" for clarity?
> >
> > Original:
> >    Additionally, MAC may multiplex packets from different
> >    Logical Channels and prioritize what to fit into one
> >    Transport Block if there is data and space available
> >    to maximize data transmission efficiency.
> >
> > Perhaps:
> >    Additionally, MAC may multiplex packets from different
> >    Logical Channels and prioritize which ones to fit into
> >    one Transport Block if there is data and space available
> >    to maximize data transmission efficiency.
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 25) <!-- [rfced] Please clarify how the last part of the sentence
> relates to the
> > rest of the sentence. Does "but with the same support..." modify "the
> > overhead"?
> >
> > Original:
> >    In this case, the protocol overhead might be smaller than the
> >    AM case because of the lack of status reporting but with the
> >    same support for segmentation up to 1600 bytes.
> >
> > Perhaps:
> >    In this case, the protocol overhead might be smaller than the
> >    AM case because of the lack of status reporting, but the
> >    overhead would have the same support for segmentation up to
> >    1600 bytes.
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 26) <!-- [rfced] Terminology
> >
> > a) Throughout the text, the following terminology appears to be used
> > inconsistently. Please review these occurrences and let us know if/how
> they
> > may be made consistent.
> >
> >  Hybrid Automatic Repeat Request vs. Hybrid Automatic Repeat reQuest
> >  Non-IP vs. non-IP
> >  Physical Layer vs. physical layer
> >  Radio link vs. Radio Link vs. radio link
> >  RuleID vs. Rule ID
> >  Word vs. word (e.g., L2 Word vs. Layer 2 word)
> >
> > [Ana]
> > Hybrid Automatic Repeat reQuest
> > Non-IP
> > Physical Layer
> > Radio Link
> > RuleID
> > Word =  L2 Word
> >
> >
> >
> >
> > b) "Dev-UE" is inconsistently expanded as "Device - User Equipment"
> > and "Device-User Equipment".  To avoid awkward hyphenation and because
> > "UE" is commonly known as "User Equipment", may we update the
> > expansion to "Device UE"?
> >
> > Original:
> >    Device - User Equipment (Dev-UE)
> >    Device-User Equipment (Dev-UE)
> >
> > Perhaps:
> >    Device UE (Dev-UE)
> > [Ana] Agree Device UE (Dev-UE)
> >
> > c) FYI: We updated the case of following terms as shown below:
> >
> >  Layer 2 (per common use in RFCs)
> >  Static Context Header Compression and fragmentation (SCHC) (per RFC
> 8724)
> > [Ana] Agree
> >
> > d) The Web Portion of the RFC Style Guide
> > (https://www.rfc-editor.org/styleguide/part2/) recommends that
> > once an abbreviation has been introduced, the abbreviated form
> > should be used thereafter. Given this, may we expand the
> > following terms on first use and then use the abbreviation
> > thereafter?
> >
> >  L2 (Layer 2)
> >  TB (Transport Block vs. transport block)
> >  TM (Transparent Mode)
> > [Ana] Yes, please
> >  L2 (Layer 2)
> >  TB (Transport Block)
> >  TM (Transparent Mode)
> >
> > e) The expansion for DRX is missing from the text. Please let us
> > know if this expansion is correct or if you prefer otherwise.
> >
> > Perhaps:
> >    Discontinuous Reception (DRX)
> > -->
> > [Ana] Agree (perhaps)
> >
> >
> > 27) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online
> > Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed.
> >
> > Note that our script did not flag any words in particular, but this
> should
> > still be reviewed as a best practice.
> > -->
> > [Ana] Done
> >
> >
> > Thank you.
> >
> > RFC Editor/st/kc
> >
> >
> > On Apr 7, 2023, at 5:29 PM, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2023/04/07
> >
> > RFC Author(s):
> > --------------
> >
> > Instructions for Completing AUTH48
> >
> > Your document has now entered AUTH48.  Once it has been reviewed and
> > approved by you and all coauthors, it will be published as an RFC.
> > If an author is no longer available, there are several remedies
> > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >
> > You and you coauthors are responsible for engaging other parties
> > (e.g., Contributors or Working Group) as necessary before providing
> > your approval.
> >
> > Planning your review
> > ---------------------
> >
> > Please review the following aspects of your document:
> >
> > *  RFC Editor questions
> >
> >   Please review and resolve any questions raised by the RFC Editor
> >   that have been included in the XML file as comments marked as
> >   follows:
> >
> >   <!-- [rfced] ... -->
> >
> >   These questions will also be sent in a subsequent email.
> >
> > *  Changes submitted by coauthors
> >
> >   Please ensure that you review any changes submitted by your
> >   coauthors.  We assume that if you do not speak up that you
> >   agree to changes submitted by your coauthors.
> >
> > *  Content
> >
> >   Please review the full content of the document, as this cannot
> >   change once the RFC is published.  Please pay particular attention to:
> >   - IANA considerations updates (if applicable)
> >   - contact information
> >   - references
> >
> > *  Copyright notices and legends
> >
> >   Please review the copyright notice and legends as defined in
> >   RFC 5378 and the Trust Legal Provisions
> >   (TLP – https://trustee.ietf.org/license-info/).
> >
> > *  Semantic markup
> >
> >   Please review the markup in the XML file to ensure that elements of
> >   content are correctly tagged.  For example, ensure that <sourcecode>
> >   and <artwork> are set correctly.  See details at
> >   <https://authors.ietf.org/rfcxml-vocabulary>.
> >
> > *  Formatted output
> >
> >   Please review the PDF, HTML, and TXT files to ensure that the
> >   formatted output, as generated from the markup in the XML file, is
> >   reasonable.  Please note that the TXT will have formatting
> >   limitations compared to the PDF and HTML.
> >
> >
> > Submitting changes
> > ------------------
> >
> > To submit changes, please reply to this email using ‘REPLY ALL’ as all
> > the parties CCed on this message need to see your changes. The parties
> > include:
> >
> >   *  your coauthors
> >
> >   *  [e-mail] (the RPC team)
> >
> >   *  other document participants, depending on the stream (e.g.,
> >      IETF Stream participants are your working group chairs, the
> >      responsible ADs, and the document shepherd).
> >
> >   *  [e-mail], which is a new archival mailing list
> >      to preserve AUTH48 conversations; it is not an active discussion
> >      list:
> >
> >     *  More info:
> >
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >
> >     *  The archive itself:
> >        https://mailarchive.ietf.org/arch/browse/auth48archive/
> >
> >     *  Note: If only absolutely necessary, you may temporarily opt out
> >        of the archiving of messages (e.g., to discuss a sensitive
> matter).
> >        If needed, please add a note at the top of the message that you
> >        have dropped the address. When the discussion is concluded,
> >        [e-mail] will be re-added to the CC list and
> >        its addition will be noted at the top of the message.
> >
> > You may submit your changes in one of two ways:
> >
> > An update to the provided XML file
> > — OR —
> > An explicit list of changes in this format
> >
> > Section # (or indicate Global)
> >
> > OLD:
> > old text
> >
> > NEW:
> > new text
> >
> > You do not need to reply with both an updated XML file and an explicit
> > list of changes, as either form is sufficient.
> >
> > We will ask a stream manager to review and approve any changes that seem
> > beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> > and technical changes.  Information about stream managers can be found
> in
> > the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >
> >
> > Approving for publication
> > --------------------------
> >
> > To approve your RFC for publication, please reply to this email stating
> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > as all the parties CCed on this message need to see your approval.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> >   https://www.rfc-editor.org/authors/rfc9391.xml
> >   https://www.rfc-editor.org/authors/rfc9391.html
> >   https://www.rfc-editor.org/authors/rfc9391.pdf
> >   https://www.rfc-editor.org/authors/rfc9391.txt
> >
> > Diff file of the text:
> >   https://www.rfc-editor.org/authors/rfc9391-diff.html
> >   https://www.rfc-editor.org/authors/rfc9391-rfcdiff.html (side by side)
> >
> > Diff of the XML:
> >   https://www.rfc-editor.org/authors/rfc9391-xmldiff1.html
> >
> > The following files are provided to facilitate creation of your own
> > diff files of the XML.
> >
> > Initial XMLv3 created using XMLv2 as input:
> >   https://www.rfc-editor.org/authors/rfc9391.original.v2v3.xml
> >
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >   https://www.rfc-editor.org/authors/rfc9391.form.xml
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >   https://www.rfc-editor.org/auth48/rfc9391
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9391 (draft-ietf-lpwan-schc-over-nbiot-15)
> >
> > Title            : Static Context Header Compression over Narrowband
> Internet of Things
> > Author(s)        : E. Ramos, A. Minaburo
> > WG Chair(s)      : Alexander Pelov, Pascal Thubert
> > Area Director(s) : Erik Kline, Éric Vyncke
> >
> >
> >
>
>