Re: [icnrg] comments: I-D Action: draft-irtf-icnrg-5gc-icn-00.txt

Thanks for your comments Thomas, other than the editorial ones, i've tried
to respond to the other comments.

On Thu, Oct 10, 2019 at 3:43 PM Jagodits, Thomas <Thomas.Jagodits@hughes.com>
wrote:

> Hi all,
>
>
>
> A few comments on this draft version are as follows:
>
> a.  [Abstract] First sentence should be rewritten: ‘flexibility’ is stated twice, and also change “offers flexibility to introduce new user and control plane function..” to “…allows the introduction of  new user and control plane function…”, etc.
>
> b.       [Abstract] Is 5GLAN the same as LAN in the previous sentence?
>
>                    Ravi > They are used in the same context, as in LAN
services enabled over 5G.

> c.       [sect 1 – page 3] Explain or add reference on how video on demand (VOD) is enabled given the constraints of Digital Rights Management.
>
>                  Ravi > Here, VoD was used in a generalized ICN context
where network caches could be used to opportunistically cache and
dynamically respond to user requests. However, the question of DRM is very
relevant, we will cite appropriate work in this space.

> d.       [sect 1 – page 3] Add reference to substantiate the claim that  “This design fails when service instances are replicated close to radio access network (RAN) instances, requiring new techniques to handle session mobility.”
>
>                Ravi > This was in reference to edge compute  and mobility,
which will require more than just anchor based mobility support, for e.g.
service migration for stateful services to closer edge compute points. Will
check to see if there are solutions within the 3GPP context to address this.

> e.       [sect 2 – page 3] “UPFs can play many role, ….” à “UPFs can play many roles, ….”.
>
> f.        [sect 4.2.1 – page 10] “..authenticating UE's attach request…” ß Does this mean that additional information for naming need to be maintained for the subscriber/UE at the HSS? If that is the case it should be called out.
>
>             Ravi >  We are not suggesting any more authentication to the
UE device itself, but authorizing UE's ICN applications so that it
can leverage the cache/compute resources of the ICN network such as in the
RAN or ICN-DNs at the edge. This can also be seen in the context of  an ICN
network slice for ICN services provisioned by the operator.

> g.       [sect 4.2.2.1] Expand or provide reference on how caching for content distribution is achieved when managing encrypted user traffic (like QUIC).
>
>           Ravi > With ICN we assume some exposure of application context
to be used by the ICN routers, that would allow ICN features of interest
aggregation, forwarding and caching to operate. The data itself can be
encrypted using mechanisms that can vary at the per-UE or content level. If
its per-UE, then it would be a unicast, wherein caching such content should
be avoided.

> h.       [sect 4.2.2] “The interconnection of a UE to an ICN-DN comprises of two segments,..” à “The interconnection of a UE to an ICN-DN comprises two segments,..”
>
> i.         [sect 4.2.3.2 – page 19] It should be possible to dynamically update the described mechanism at the TCL.
>
> j.         [sect 5.1.2 – page 24] SDN is generic and what is described should also be possible without SDN.
>
>       Ravi > This is used as to signify a centralized routing mechanism,
guess we could take a distributed approach too here, but with restricted
efficiency.

>
>
> Regards,
>
> Thomas Jagodits
>
> Hughes Network Systems
>
> E-mail: Thomas.Jagodits@hughes.com
>
> Office: +1 (301) 548-1252
>
>
>
> -----Original Message-----
> From: icnrg [mailto:icnrg-bounces@irtf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Monday, October 07, 2019 3:23 PM
> To: i-d-announce@ietf.org
> Cc: icnrg@irtf.org
> Subject: [icnrg] I-D Action: draft-irtf-icnrg-5gc-icn-00.txt
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>
> This draft is a work item of the Information-Centric Networking RG of the
> IRTF.
>
>
>
>
>
>
>
>         Title           : Enabling ICN in 3GPP's 5G NextGen Core
> Architecture
>
>
>
>         Authors         : Ravi Ravindran
>
>
>
>                           Prakash Suthar
>
>
>
>                           Dirk Trossen
>
>
>
>                           Chonggang Wang
>
>
>
>                           Greg White
>
>
>
>                 Filename        : draft-irtf-icnrg-5gc-icn-00.txt
>
>
>
>                 Pages           : 32
>
>
>
>                 Date            : 2019-10-07
>
>
>
>
>
>
>
> Abstract:
>
>
>
>   The proposed 3GPP's 5G core nextgen architecture (5GC) offers
>
>
>
>   flexibility to introduce new user and control plane function,
>
>
>
>    considering the support for network slicing functions, that allows
>
>
>
>    greater flexibility to handle heterogeneous devices and applications.
>
>
>
>    In this draft, we provide a short description of the proposed 5GC
>
>
>
>    architecture, including recent efforts to provide cellular Local Area
>
>
>
>    Network (LAN) connectivity, followed by extensions to 5GC's control
>
>
>
>    and user plane to support Packet Data Unit (PDU) sessions from
>
>
>
>    Information-Centric Networks (ICN).  In addition, ICN over 5GLAN is
>
>
>
>    also described.
>
>
>
>
>
>
>
>
>
>
>
> The IETF datatracker status page for this draft is:
>
>
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-irtf-icnrg-5gc-icn/__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07nEOgO8C$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-irtf-icnrg-5gc-icn/__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07nEOgO8C$>
>
>
>
>
>
>
>
> There are also htmlized versions available at:
>
>
>
>
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-irtf-icnrg-5gc-icn-00__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07jOWf5xV$
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-irtf-icnrg-5gc-icn-00__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07jOWf5xV$>
>
>
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-5gc-icn-00__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07vVR80PM$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-irtf-icnrg-5gc-icn-00__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07vVR80PM$>
>
>
>
>
>
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
>
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
>
>
>
>
>
>
> Internet-Drafts are also available by anonymous FTP at:
>
>
>
>
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07ouiLWQM$
> <https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07ouiLWQM$>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
> icnrg mailing list
>
>
>
> icnrg@irtf.org
>
>
>
>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07jq6Jcig$
> <https://urldefense.com/v3/__https:/www.irtf.org/mailman/listinfo/icnrg__;!0rLxnc5oh4s!ky4qR5Tl5nAbS1MQyGUC5zgOzwVB4COkEDwZwoOG86Ms0UoB3d94oaLTqJ-07jq6Jcig$>
>
>
>