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

[Ana Minaburo <[e-mail]>]

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