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

[Karen Moore <[e-mail]>]

Dear Ana and Edgar,

We have noted your approvals on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9391).

Since the AUTH48 process is now complete, we will move this document forward in the publication process.

Thank you for your time!

RFC Editor/kc


> On Apr 12, 2023, at 4:59 AM, Edgar Ramos <[e-mail]> wrote:
> 
> HI Karen,
> I also approve this RFC for publication
>  
> Br
>  
> Edgar
>  

> On Apr 12, 2023, at 2:30 AM, Ana Minaburo <[e-mail]> wrote:
> 
> 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
> > 
> > 
> > 
>