Re: [auth48] AUTH48: RFC-to-be 9269 <draft-irtf-icnrg-icn-lte-4g-12> for your review

[Reuben Esparza <[e-mail]>]

Hi Authors,


Anil, thank you for your reply and updated XML file.


We notice that two instances of "mobile gateways (SGW/PGW)” remain lowercased while the majority are uppercased.

Similarly, we still see "SGW, PGW" vs. "(SWG, PGW)" vs. "SGW/PGW” throughout the document. 
 
Please let us know if this was intentional or if any updates are needed (i.e., would inserting “and” between “SWG" and “PGW” be beneficial)?


Once we receive a response along with your final approval, along with that of Prakash, Milan, Dirk, and Ravi, we’ll be able to continue with the publication process for this document.


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 you may have.  We will await approvals from each author 
prior to moving forward in the publication process.

A diff file highlighting only the AUTH48 updates is available at:

https://www.rfc-editor.org/authors/rfc9269-auth48diff.html


The text, XML, and comprehensive diff files are available at:

https://www.rfc-editor.org/authors/rfc9269.txt
https://www.rfc-editor.org/authors/rfc9269.pdf
https://www.rfc-editor.org/authors/rfc9269.html
https://www.rfc-editor.org/authors/rfc9269.xml
https://www.rfc-editor.org/authors/rfc9269-diff.html

Note that it may be necessary for you to refresh your browser to access the most recent version.  

The AUTH48 status page for this document is available here:

https://www.rfc-editor.org/auth48/rfc9269

Thank you.

RFC Editor/re



> On Aug 12, 2022, at 4:35 PM, Anil Jangam (anjangam) <[e-mail]> wrote:
> 
> Hello Reuben. 
>  
> We have reviewed and updated the changes as per your updates/suggestions/options/ask. Please see attached the updated .xml file.
>  
> We have left unchanged the comment related to the ‘inclusive language’. The word native/natively is sort of very core to the work proposed in this document. I am providing some similar references which uses these two words. Hope this helps. 
> 	• https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
> 		• In the absence of native SCTP support in operating systems, it is possible to tunnel SCTP over UDP,[21] as well as to map TCP API calls to SCTP calls so existing applications can use SCTP without modification.[22]
> 	• https://news.thomasnet.com/fullstory/wireless-protocol-stack-runs-natively-on-clinux-553238
> 		• DECT and CAT-iq protocol software stack that runs natively under the royalty-free µClinux operating system
> 		• "With native support for our mature DECT stack under the industry-standard µClinux operating system
>  
> Please let us know of any additional feedback.
>  
> /anil.
>  
>  
>  
> Reuben Esparza [e-mail] 8/11/22, 9:50 AM
>  
> Hi authors,
> 
> Anil, this is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process.
> 
> 
> Please let us know if we can be of assistance as you begin the AUTH48 review process.
> 
> The AUTH48 status page for this document is available here:
> 
> https://www.rfc-editor.org/auth48/rfc9269
> 
> AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48.
> 
> We look forward to hearing from you at your earliest convenience.
> 
> Thank you.
> 
> RFC Editor/re
> 
> 
> > On Jul 22, 2022, at 2:53 PM, Anil Jangam (anjangam) <anjangam=[e-mail]> wrote:
> > 
> > Hi, RFC Editors, 
> >  
> > Thank you much for your feedback. I hereby confirm the receipt of this email.
> > I am out (OOO) for next week and will reply (will provide an updated .xml file) with the changes suggested.
> >  
> > Thank you. 
> > Anil Jangam. 
> >  
> > [e-mail] [e-mail] 7/22/22, 2:26 PM
> >  
> > Authors,
> > 
> > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> > 
> > 1) <!-- [rfced] Please note that the title has been updated as follows. "ICN"
> > has been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). 
> > Please review.
> >        
> > Original:
> >    Experimental Scenarios of ICN Integration in 4G Mobile Networks
> > 
> > Updated:
> >    Experimental Scenarios of Information-Centric Networking (ICN)
> >    Integration in 4G Mobile Networks
> > -->
> > 
> > 
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search. -->
> > 
> > 
> > 3) <!--[rfced] In Section 2, would you like to alphabetize the 3GPP
> > Terminology and Concepts list? Most of the list is in order, but
> > some terms are out of order.
> > -->
> > 
> > 
> > 4) <!-- [rfced] FYI: We've expanded "GGSN, PGW" in the following
> > sentence. Please let us know if "a Gateway GPRS Support Node
> > (GGSN) or Packet Data Network Gateway (PGW)" is correct or if 
> > "and" should be used instead of "or".
> > 
> > Original:
> >    In addition to identifying a PDN, an APN may also be used to define 
> >    the type of service, QoS, and other logical entities inside GGSN, PGW.
> > 
> > Current:
> >    In addition to identifying a PDN, an APN may also be used to define
> >    the type of service, QoS, and other logical entities inside a Gateway GPRS   
> >    Support Node (GGSN) or a Packet Data Network Gateway (PGW).
> > -->
> > 
> > 
> > 5) <!--[rfced] Would it benefit the reader to add a citation for the 3GPP
> > document here? If so, please let us know which citation should be
> > included.
> > 
> > Original:
> >   Home Subscriber Server:  The Home Subscriber Server (HSS) is a
> >       database for a given subscriber and was introduced in 
> >       3GPP Release 5.
> > -->
> > 
> > 
> > 6) <!-- [rfced] FYI: We've updated the following sentence for clarity.
> > Please let us know if this changes the intended meaning.
> > 
> > Original:
> >    This section provide a high-level overview of typical 4G mobile
> >    network architecture and their key functions related to a possibility of 
> >    using of ICN technology.
> > 
> > Updated:
> >    This section provides a high-level overview of typical 4G mobile
> >    network architecture and the key functions related to the possibility of 
> >    its use with ICN technology.
> > -->
> > 
> > 
> > 7) <!-- [rfced] FYI: Note that we have removed "interface" after "SGi" as
> > the "i" already refers to interface. One example:
> > 
> > Original:
> >    To ease the burden on the bandwidth of the SGi interface, caching is
> >    introduced in a similar manner...
> > 
> > Current:
> >    To ease the burden on the bandwidth of the Service Gateway interface
> >    (SGi), caching is introduced in a similar manner...
> > -->
> > 
> > 
> > 8) <!--[rfced] The following sentence does not parse.  Please let us know
> > if the suggested update is agreeable or if you prefer otherwise.
> > 
> > Original:
> >    Data transport using ICN is different to IP-based transport by
> >    introducing uniquely named-data as a core design principle.
> > 
> > Perhaps:
> >    Data transport using ICN is different than IP-based transport as
> >    it introduces uniquely named data as a core design principle.
> > -->
> > 
> > 
> > 9) <!-- [rfced] In the following sentence, is "protocol architecture"
> > intended (option A) or are "protocols" and "architecture"
> > intended separately (option B)? Also, we rephrased the last part
> > of the sentence for clarity; please review.
> > 
> > Original:
> >    To understand the suitability of ICN for mobile networks, we will
> >    discuss the ICN framework by describing its protocols architecture and
> >    different types of messages to then consider how we can use this in mobile
> >    networks for delivering content more efficiently.
> > 
> > Perhaps:
> > A) To understand the suitability of ICN for mobile networks, we will
> >    discuss the ICN framework by describing its protocol architecture and
> >    different types of messages; this will be helpful when considering how 
> >    to use ICN in mobile networks to deliver content more efficiently.
> > 
> > or
> > 
> > B) To understand the suitability of ICN for mobile networks, we will
> >    discuss the ICN framework by describing its protocols, architecture, and
> >    different types of messages; this will be helpful when considering how 
> >    to use ICN in mobile networks to deliver content more efficiently.
> > -->
> > 
> > 
> > 10) <!-- [rfced] In the following sentence, should "enables flexible network" be
> > "enables flexible networking" (option A) or should "enables the use of a 
> > flexible network" be used instead (option B)?
> > 
> > Original:
> >    The evolution of the existing mobile packet core using Control and
> >    User Plane Separation (CUPS) [TS23.714] enables flexible network and
> >    operations by distributed deployment and the independent scaling of control
> >    plane and user-plane functions - while not affecting the functionality of
> >    existing nodes subject to this split.
> > 
> > Perhaps:
> > A) The evolution of the existing mobile packet core using Control and
> >    User Plane Separation (CUPS) [TS23.714] enables flexible networking 
> >    and operations by distributed deployment and the independent scaling 
> >    of control plane and user-plane functions while not affecting the 
> >    functionality of existing nodes subject to this split.
> > 
> > Or 
> > 
> > B) The evolution of the existing mobile packet core using Control and
> >    User Plane Separation (CUPS) [TS23.714] enables the use of flexible 
> >    networks and operations by distributed deployment and the independent 
> >    scaling of control plane and user-plane functions while not affecting
> >    the functionality of existing nodes subject to this split.
> > -->
> > 
> > 
> > 11) <!--[rfced] May we remove the second mention of "transport" to reduce
> > redundancy? Please let us know if that still retains the intended
> > meaning.
> > 
> > Original:
> >    Combined with the existing IP function, the ICN function provides
> >    support for either native ICN and/or the dual transport (ICN/IP)
> >    transport functionality. 
> > 
> > Perhaps:
> >    Combined with the existing IP function, the ICN function provides
> >    support for native ICN and/or dual transport (ICN/IP) functionality. 
> > -->
> > 
> > 
> > 12) <!--[rfced] In order to keep "(IWF)" with its expansion, we would
> > like to remove it from the parentheses. Please let us know if
> > rephrasing as "(and Border Gateway)" is agreeable or if you
> > prefer otherwise.
> > 
> > Original:
> >    IPoICN however, will require an inter-working
> >    function (IWF / Border Gateway) to translate 
> >    various transport primitives. 
> > 
> > Perhaps:
> >    IPoICN, however, will require an interworking
> >    function (IWF) (and Border Gateway) to translate 
> >    various transport primitives. 
> > -->
> > 
> > 
> > 13) <!-- [rfced] FYI: We've capitalized "create session" in the
> > following sentence to match usage per reference [TS23.401], which uses
> > "Create Session Request" and "Create Session Response". Please let us
> > know if this is not preferred.
> > 
> > Original:
> >    MME forwards mobile terminal authentication to HSS, so HSS must be
> >    able to authenticate an ICN-capable mobile terminal and authorize create
> >    session [TS23.401].
> > 
> > Updated:
> >    MME forwards mobile terminal authentication to HSS, so HSS must be
> >    able to authenticate an ICN-capable mobile terminal and authorize Create
> >    Session [TS23.401].
> > -->
> > 
> > 
> > 14) <!--[rfced] We updated this sentence as follows as we assume that the
> > mobility management's access is agnostic and transparent to the
> > end device; if this update is not correct, please let us know.
> > 
> > Original:
> >    Mobility management at layer-3 level makes it access agnostic and
> >    transparent to the end device or the application.
> > 
> > Perhaps:
> >    Mobility management at the Layer 3 level makes its access agnostic
> >    and transparent to the end device or the application.
> > -->
> > 
> > 
> > 15) <!--[rfced] In Figure 5, should "BS(eNodeB)" have a space in between
> > (e.g., "BS (eNodeB)", or is it correct as is?
> > -->
> > 
> > 
> > 16) <!-- [rfced] Note that we've replaced interjectory commas in the following
> > sentence with parentheses to avoid too many sequential commas. Please let us
> > know if this is not preferred.
> > 
> > Original:
> >    The common API will provide a 'connection' abstraction for this HTTP
> >    mode of operation, returning the response over said connection abstraction,
> >    akin to the TCP socket interface, while implementing a reliable transport
> >    connection semantic over the ICN from the mobile terminal to the receiving
> >    mobile terminal or the PGW.
> > 
> > Updated:
> >    The common API will provide a "connection" abstraction for this HTTP
> >    mode of operation, returning the response over said connection abstraction
> >    (akin to the TCP socket interface) while implementing a reliable transport
> >    connection semantic over the ICN from the mobile terminal to the receiving
> >    mobile terminal or the PGW.
> > -->
> > 
> > 
> > 17) <!-- [rfced] FYI: In the following sentence, we hyphenated "forward to core" as we
> > believe it was intended to be attributive to a noun. Please let us know if this is not
> > the case.
> > 
> > Original:
> >    The mobile terminal encapsulates a user data transport request into
> >    PDCP layer and sends the information on the air interface to eNodeB, which in
> >    turn receives the information and, using PDCP [TS36.323], de-encapsulates the
> >    air-interface messages and converts them to forward to core mobile gateways
> >    (SGW, PGW).
> > 
> > Updated:
> >    The mobile terminal encapsulates a user data transport request into the
> >    PDCP layer and sends the information on the air interface to the eNodeB, which
> >    in turn receives the information and, using PDCP [TS36.323], de-encapsulates
> >    the air-interface messages and converts them to forward-to-core mobile gateways
> >    (SGW, PGW).
> > -->
> > 
> > 
> > 18) <!-- [rfced] Was "Entire" intended to be capitalized in the following sentence?
> > 
> > Original:
> >   The Entire functionality is managed using IP address(es) for MT.
> > -->       
> > 
> > 
> > 19) <!--[rfced] Please clarify. Are the ICN attributes inserted "as"
> > additional functionality "for" the IP stack (option A) or inserted 
> > "for" additional functionality "with" the IP stack (option B)?
> > 
> > Original:
> >    Insert ICN attributes in the session management layer as
> >    additional functionality with IP stack.
> > 
> > Perhaps:
> > A) Insert ICN attributes in the session management layer as
> >    additional functionality for the IP stack.
> > 
> > or
> > 
> > B) Insert ICN attributes in the session management layer for
> >    additional functionality with the IP stack.
> > -->
> > 
> > 
> > 20) <!-- [rfced] For clarity, we have updated the sentence as shown below;
> > please let us know if any updates are needed.
> > 
> > Original:
> >    SUB: ICN simulated client (using ndnSIM), a client application on
> >    workstation requesting content.
> > 
> > Current:
> >    SUB: An ICN-simulated client (using ndnSIM) - a client application on
> >       a workstation requesting content.
> > -->
> > 
> > 
> > 21) <!--[rfced] Should "5GOpenCore" perhaps be "Open5GCore" per the reference?
> > 
> > Original:
> >    EPC:  Evolved Packet Core in a single instance (such as 5GOpenCore
> >          [Open5GCore]).
> > 
> > Perhaps:
> >    EPC:  Evolved Packet Core in a single instance (such as Open5GCore
> >          [Open5GCore]).
> > -->
> > 
> > 
> > 22) <!-- [rfced] In the following sentence, does ICN emulate code (option A)
> > or is the code itself ICN emulating (option B)?
> > 
> > Original:
> >    For the purpose of this testing, ICN emulating code can be inserted
> >    in the test code in EMU to emulate ICN-capable eNodeB.
> > 
> > Perhaps:
> > A) For the purpose of this testing, an ICN emulating code can be inserted
> >    in the test code in EMU to emulate an ICN-capable eNodeB.
> > 
> > or
> > 
> > B) For the purpose of this testing, ICN-emulating code can be inserted
> >    in the test code in EMU to emulate an ICN-capable eNodeB.
> > -->
> > 
> > 
> > 23) <!-- [rfced] FYI: We have added an "empty" IANA section to this
> > document per guidance in RFC 8126
> > <https://datatracker.ietf.org/doc/html/rfc8126#section-9.1>.
> > -->
> > 
> > 
> > 24) <!--[rfced] Is the intended meaning "first interests or first k
> > interests"? If so, we suggest adding a comma after "k" as follows.
> > 
> > Original:
> >    *  Delay for the first, or first k interests on edge routers (timing
> >       attack)
> > 
> > Perhaps:
> >    *  Delay for the first, or first k, interests on edge routers (timing
> >       attack)
> > -->
> > 
> > 
> > 25) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the April 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >  [TS25.323]   3GPP, "Packet Data Convergence Protocol (PDCP)
> >               specification", 3GPP TS 25.323 3.10.0, 18 September 2002,
> >               <http://www.3gpp.org/ftp/Specs/html-info/25323.htm>.
> > 
> > Perhaps:
> >  [TS25.323]   3GPP, "Packet Data Convergence Protocol (PDCP)
> >               specification", 3GPP TS 25.323 17.0.0, April 2022,
> >               <https://www.3gpp.org/ftp/Specs/html-info/25323.htm>.
> > -->     
> > 
> > 
> > 26) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Please note that the December 2005 version only has 451 pages, so
> > an update is needed to the text below. Whether you decide to use
> > the most recent or the older version, please confirm which pages 
> > to reference for the figure and table.
> > 
> > Current:
> >    5. PCO IE as described in [TS24.008] (see Figure 10.5.136 on page
> >       598 and Table 10.5.154 on page 599) provides details for 
> >       different fields.
> > 
> > REFERENCE ENTRY
> > 
> > Original:
> >  [TS24.008]   3GPP, "Mobile radio interface Layer 3 specification; Core
> >               network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 15
> >               December 2005,
> >               <http://www.3gpp.org/ftp/Specs/html-info/24008.htm>.
> > 
> > Perhaps:
> >  [TS24.008]   3GPP, "Mobile radio interface Layer 3 specification; Core
> >               network protocols; Stage 3", 3GPP TS 24.008 17.7.0,
> >               June 2022,
> >               <https://www.3gpp.org/ftp/Specs/html-info/24008.htm>.
> > -->
> > 
> > 
> > 27) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the July 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >   [TS36.323]  3GPP, "Evolved Universal Terrestrial Radio Access
> >               (E-UTRA); Packet Data Convergence Protocol (PDCP)
> >               specification", 3GPP TS 36.323 10.2.0, 3 January 2013,
> >               <http://www.3gpp.org/ftp/Specs/html-info/36323.htm>.
> > 
> > Perhaps:
> >   [TS36.323]  3GPP, "Evolved Universal Terrestrial Radio Access
> >               (E-UTRA); Packet Data Convergence Protocol (PDCP)
> >               specification", 3GPP TS 36.323 17.1.0, July 2022,
> >               <https://www.3gpp.org/ftp/Specs/html-info/36323.htm>.
> > -->     
> > 
> > 
> > 28) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >   [TS29.274]  3GPP, "3GPP Evolved Packet System (EPS); Evolved General
> >               Packet Radio Service (GPRS) Tunneling Protocol for Control
> >               plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 25 June
> >               2013, <http://www.3gpp.org/ftp/Specs/html-info/29274.htm>.
> > 
> > Perhaps:
> >   [TS29.274]  3GPP, "3GPP Evolved Packet System (EPS); Evolved General
> >               Packet Radio Service (GPRS) Tunnelling Protocol for
> >               Control plane (GTPv2-C); Stage 3", 3GPP
> >               TS 29.274 17.6.0, June 2022,
> >               <https://www.3gpp.org/ftp/Specs/html-info/29274.htm>.
> > -->
> > 
> > 
> > 29) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >   [TS29.281]  3GPP, "General Packet Radio System (GPRS) Tunneling
> >               Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 26
> >               September 2011,
> >               <http://www.3gpp.org/ftp/Specs/html-info/29281.htm>.
> > 
> > Perhaps:
> >    [TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
> >               Protocol User Plane (GTPv1-U)", 3GPP TS 29.281
> >               17.3.0, June 2022,
> >               <https://www.3gpp.org/ftp/Specs/html-info/29281.htm>.
> > -->
> > 
> > 
> > 30) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the December 2021 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >    [TS23.203] 3GPP, "Policy and charging control architecture", 3GPP
> >               TS 23.203 10.9.0, 12 September 2013,
> >               <http://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
> > 
> > Perhaps:
> >    [TS23.203] 3GPP, "Policy and charging control architecture", 3GPP
> >               TS 23.203 17.2.0, December 2021,
> >               <http://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
> > -->
> > 
> > 
> > 31) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >   [TS23.401]  3GPP, "General Packet Radio Service (GPRS) enhancements
> >               for Evolved Universal Terrestrial Radio Access Network
> >               (E-UTRAN) access", 3GPP TS 23.401 10.10.0, 7 March 2013,
> >               <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
> > 
> > Perhaps:
> >   [TS23.401]  3GPP, "General Packet Radio Service (GPRS) enhancements
> >               for Evolved Universal Terrestrial Radio Access Network
> >               (E-UTRAN) access", 3GPP TS 23.401 17.5.0, June 2022,
> >               <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
> > -->
> > 
> > 
> > 32) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >  [TS23.501]   3GPP, "System Architecture for the 5G System", 3GPP
> >               TS 23.501 15.2.0, 15 June 2018,
> >               <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
> > 
> > Perhaps:
> >  [TS23.501]   3GPP, "System architecture for the 5G System (5GS)",
> >               3GPP TS 23.501 17.5.0, June 2022,
> >               <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
> > -->
> > 
> > 
> > 33) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >    [TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling
> >               Protocol (GTP) across the Gn and Gp interface", 3GPP
> >               TS 29.060 3.19.0, 24 March 2004,
> >               <http://www.3gpp.org/ftp/Specs/html-info/29060.htm>.
> > 
> > Perhaps:
> >    [TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling
> >               Protocol (GTP) across the Gn and Gp interface", 3GPP
> >               TS 29.060 17.3.0, June 2022,
> >               <http://www.3gpp.org/ftp/Specs/html-info/29060.htm>.
> > -->
> > 
> > 
> > 34) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the June 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >   [TS33.310]  3GPP, "Network Domain Security (NDS); Authentication
> >               Framework (AF)", 3GPP TS 33.310 10.7.0, 21 December 2012,
> >               <http://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
> > 
> > Perhaps:
> >   [TS33.310]  3GPP, "Network Domain Security (NDS); Authentication
> >               Framework (AF)", 3GPP TS 33.310 17.3.0, June 2022,
> >               <http://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
> > -->     
> > 
> > 
> > 35) <!--[rfced] There is a more current version of this reference. Please
> > let us know if you would like to point to the March 2022 version
> > or if you would like to keep it as is.
> > 
> > Original:
> >  [TS33.320]   3GPP, "Security of Home Node B (HNB) / Home evolved Node B
> >               (HeNB)", 3GPP TS 33.320 10.5.0, 29 June 2012,
> >               <http://www.3gpp.org/ftp/Specs/html-info/33320.htm>.
> > 
> > Perhaps:
> >  [TS33.320]   3GPP, "Security of Home Node B (HNB) / Home evolved Node B
> >               (HeNB)", 3GPP TS 33.320 17.0.0, March 2022,
> >               <http://www.3gpp.org/ftp/Specs/html-info/33320.htm>.
> > -->
> > 
> > 
> > 36) <!--[rfced] FYI: draft-ravi-icnrg-5gc-icn-04 was replaced by
> > draft-irtf-icnrg-5gc-icn. The reference entry reflects this 
> > change.
> > 
> > Original:
> >    [ICN5G]    Ravindran, R., suthar, P., Trossen, D., and G. White,
> >               "Enabling ICN in 3GPP's 5G NextGen Core Architecture",
> >               Work in Progress, Internet-Draft, draft-ravi-icnrg-5gc-
> >               icn-04, 10 January 2021,
> >               <https://www.ietf.org/id/draft-irtf-icnrg-5gc-icn-04.txt>.
> > 
> > Current:
> >    [ICN5G]    Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
> >               White, "Enabling ICN in 3GPP's 5G NextGen Core
> >               Architecture", Work in Progress, Internet-Draft, draft-
> >               irtf-icnrg-5gc-icn-04, January 2021,
> >               <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
> >               5gc-icn-04>.
> > -->         
> > 
> > 
> > 37) <!--[rfced] For this reference, we believe the intention is to point to
> > https://www.nsnam.org/docs/models/html/lte-design.html#epc-model (option A) 
> > and not
> > https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf (option B). 
> > We updated the entry per option A; please let us know if you prefer 
> > otherwise.
> > 
> > Original:
> >    [NS3EPC]   Baldo, N., "The ns-3 EPC module",  NS3 EPC Model,
> >               <https://www.nsnam.org/docs/models/html/lte-
> >               design.html#epc-model>.
> > 
> > Current:
> > A) [NS3EPC]   ns-3, "The EPC Model", July 2022,
> >               <https://www.nsnam.org/docs/models/html/lte-
> >               design.html#epc-model>.
> > or
> > 
> > Alternate:
> > B) [NS3EPC]   Baldo, N., "The ns-3 LTE module by the LENA project", 
> >               <https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf>.
> > -->
> > 
> > 
> > 38) <!--[rfced] For this reference, we believe the intention is to point to
> > https://www.nsnam.org/docs/models/html/lte-design.html#lte-model (not
> > https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf).
> > We updated the entry accordingly; please let us know if you prefer 
> > otherwise.
> > 
> > Original:
> >    [NS3LTE]   Baldo, N., "The ns-3 LTE module",  NS3 LTE Model,
> >               <https://www.nsnam.org/docs/models/html/lte-
> >               design.html#lte-model>.
> > 
> > Current:
> >    [NS3EPC]   ns-3, "The LTE Model", July 2022,
> >               <https://www.nsnam.org/docs/models/html/lte-design.html#lte-model>.
> > -->
> > 
> > 
> > 39) <!-- [rfced] 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.  
> > 
> >  eNodeB vs. the (or an) eNodeB
> >      [Note: we added an article before this term throughout the text 
> >      for consistency and readability; if you prefer otherwise, 
> >      please let us know]
> > 
> >  Mobile Gateway vs. Mobile gateway vs. mobile gateway
> > 
> >  Radio Access Network vs. radio access network
> > 
> >  SGW, PGW vs. (SWG, PGW) vs. SGW/PGW
> >      [Note: should parentheses be added to any of these instances, 
> >      or should "and" be added (e.g., "SWG and PWG")?]
> > -->
> > 
> > 
> > 40) <!-- [rfced] Please clarify if the following acronyms have been
> > expanded correctly in the text (or indicate which option).
> > 
> > CDN: Content Delivery Network or content data network?
> > 
> > IMSI: International Mobile Subscriber Identity
> > 
> > NAS:  Network Access Server
> > 
> > PCRF: Policy and Charging Rule Function
> > 
> > PWG:  Packet Data Network Gateway 
> >         [Note: In Section 2, we changed 1 instance of 
> >         "PDN-GW" to "PWG" for consistency; please let 
> >         us know of any objections]
> > 
> > USIM: Universal Mobile Telecommunications System Subscriber 
> >       Identity Module
> > -->
> > 
> > 
> > 41) <!-- [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.  
> > 
> > For example, please consider whether "native" and "natively" should be updated.
> > -->
> > 
> > 
> > Thank you.
> > 
> > RFC Editor/re/kc
> > 
> > 
> > On Jul 22, 2022, at 2:20 PM, [e-mail] wrote:
> > 
> > *****IMPORTANT*****
> > 
> > Updated 2022/07/22
> > 
> > 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/rfc9269.xml
> >   https://www.rfc-editor.org/authors/rfc9269.html
> >   https://www.rfc-editor.org/authors/rfc9269.pdf
> >   https://www.rfc-editor.org/authors/rfc9269.txt
> > 
> > Diff file of the text:
> >   https://www.rfc-editor.org/authors/rfc9269-diff.html
> >   https://www.rfc-editor.org/authors/rfc9269-rfcdiff.html (side by side)
> > 
> > Diff of the XML: 
> >   https://www.rfc-editor.org/authors/rfc9269-xmldiff1.html
> > 
> > XMLv3 file that is a best effort to capture v3-related format updates 
> > only: 
> >   https://www.rfc-editor.org/authors/rfc9269.form.xml
> > 
> > 
> > Tracking progress
> > -----------------
> > 
> > The details of the AUTH48 status of your document are here:
> >   https://www.rfc-editor.org/auth48/rfc9269
> > 
> > Please let us know if you have any questions.  
> > 
> > Thank you for your cooperation,
> > 
> > RFC Editor
> > 
> > --------------------------------------
> > RFC9269 (draft-irtf-icnrg-icn-lte-4g-12)
> > 
> > Title            : Experimental Scenarios of ICN Integration in 4G Mobile Networks
> > Author(s)        : P. Suthar, M. Stolic, A. Jangam, Ed., D. Trossen, R. Ravindran
> > WG Chair(s)      : 
> > Area Director(s) : 
> > 
> 
> 
> 
> 
> 
> 
> 
> <rfc9269.xml>