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

[[e-mail]]

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


2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->


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?

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


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


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


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


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


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


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


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


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


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


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


14) <!--[rfced] Is "Transparent Mode transmission mode" correct, or should
it be "Transparent Mode transmission" (i.e., remove "mode" to
avoid redundancy)?

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


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


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


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


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


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


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


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


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


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


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


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


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)

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)

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)

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)

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


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


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