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

["Anil Jangam (anjangam)" <[e-mail]>]

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