Subject: Re: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

From: "Milan Stolic (mistolic)" <[email-masked]>
Date: Mon, 4 Nov 2019 19:14:42 +0000

Hello ICNRG team,

We have submitted a revision of our Native Deployment of ICN in LTE, 4G Mobile Networks draft. It addresses comments received in the past few months from Luca, Akbar, Martin and Dave. The latest draft can be found here<https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/>. We would like to take this opportunity and thank the team for their feedback, and to ask for the next steps related to the RG last call.

Thank you,
Milan

From: icnrg <[email-masked]> On Behalf Of Akbar Rahman
Sent: Tuesday, September 24, 2019 13:03
To: Börje Ohlman <borje.ohlman=[email-masked]>; [email-masked]
Subject: Re: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

I support progressing the document as we have had several rounds of reviews, and also general RG interest in the draft.

I recommend publishing it as Informational as it is not a pure protocol draft but also covers other aspects such as architecture, configuration and open issues.

Best Regards,

Akbar

From: icnrg <[email-masked]<mailto:[email-masked]>> On Behalf Of Börje Ohlman
Sent: Thursday, September 19, 2019 10:29 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

Dear ICNRG’ers,

The draft Native Deployment of ICN in LTE, 4G Mobile Networks has now been reviewed, see mailing list for details, and the comments has been addressed by the authors in the new -04 version of the draft.
We as chairs, now think the document is ready for the RG last call. Please let us now if you agree with this or if you have further comments on the draft. Please also let us know if you support that we should publish this document.

We also would like your comments on whether you think this document is best published as an Experimental or Informational RFC?

You can find the document at:
https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g

Given the upcoming ICN conference and ICNRG Interim meeting, as noted above, the last call closes on Sunday, October 6th, 2019.

Hope to see you in Macao.

Your Chairs,
Börje, Dave and Dirk
[Banner]

[Banner][Banner]
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: "Milan Stolic (mistolic)" <[email-masked]>
Date: Mon, 4 Nov 2019 19:28:48 +0000

In addition to the below, as suggested by Dave, we have applied formatting and grammar corrections with help of a native speaker.

Thanks,
Milan

From: Milan Stolic (mistolic)
Sent: Monday, November 4, 2019 13:15
To: Akbar Rahman <[email-masked]>; Börje Ohlman <borje.ohlman=[email-masked]>; [email-masked]
Cc: Prakash Suthar (psuthar) <[email-masked]>; Anil Jangam (anjangam) ([email-masked]) <[email-masked]>
Subject: RE: RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

Hello ICNRG team,

Thank you,
Milan

From: icnrg <[email-masked]<mailto:[email-masked]>> On Behalf Of Akbar Rahman
Sent: Tuesday, September 24, 2019 13:03
To: Börje Ohlman <borje.ohlman=[email-masked]<mailto:borje.ohlman=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

Best Regards,

Akbar

Dear ICNRG’ers,

Your Chairs,
Börje, Dave and Dirk
[Banner]

[Banner][Banner]

---

From: "Dirk Kutscher" <[email-masked]>
Date: Sun, 17 Nov 2019 04:37:22 +0100

Thanks, Milan and co-authors.

Martin and Dave, could you have a look at the 05 version of this draft 
and check whether it addresses your comments?

Thanks,
Dirk

On 4 Nov 2019, at 20:28, Milan Stolic (mistolic) wrote:

> In addition to the below, as suggested by Dave, we have applied 
> formatting and grammar corrections with help of a native speaker.
>
> Thanks,
> Milan
>
> To: Akbar Rahman <[email-masked]>; Börje Ohlman 
> <borje.ohlman=[email-masked]>; [email-masked]
> Cc: Prakash Suthar (psuthar) <[email-masked]>; Anil Jangam 
> (anjangam) ([email-masked]) <[email-masked]>
> We have submitted a revision of our Native Deployment of ICN in LTE, 
> 4G Mobile Networks draft. It addresses comments received in the past 
> few months from Luca, Akbar, Martin and Dave. The latest draft can be 
> found 
> here<https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/>. 
> We would like to take this opportunity and thank the team for their 
> feedback, and to ask for the next steps related to the RG last call.
>
> Thank you,
> Milan
>
> To: Börje Ohlman 
> <borje.ohlman=[email-masked]<mailto:borje.ohlman=[email-masked]>>; 
> [email-masked]<mailto:[email-masked]>
> I support progressing the document as we have had several rounds of 
> reviews, and also general RG interest in the draft.
>
> I recommend publishing it as Informational as it is not a pure 
> protocol draft but also covers other aspects such as architecture, 
> configuration and open issues.
>
>
> Best Regards,
>
>
> Akbar
>
> The draft Native Deployment of ICN in LTE, 4G Mobile Networks has now 
> been reviewed, see mailing list for details, and the comments has been 
> addressed by the authors in the new -04 version of the draft.
> We as chairs, now think the document is ready for the RG last call. 
> Please let us now if you agree with this or if you have further 
> comments on the draft. Please also let us know if you support that we 
> should publish this document.
>
> We also would like your comments on whether you think this document is 
> best published as an Experimental or Informational RFC?
>
> Given the upcoming ICN conference and ICNRG Interim meeting, as noted 
> above, the last call closes on Sunday, October 6th, 2019.
>
> This e-mail is intended only for the use of the individual or entity 
> to which it is addressed, and may contain information that is 
> privileged, confidential and/or otherwise protected from disclosure to 
> anyone other than its intended recipient. Unintended transmission 
> shall not constitute waiver of any privilege or confidentiality 
> obligation. If you received this communication in error, please do not 
> review, copy or distribute it, notify me immediately by email, and 
> delete the original message and any attachments. Unless expressly 
> stated in this e-mail, nothing in this message or any attachment 
> should be construed as a digital or electronic signature.

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 17 Nov 2019 16:25:07 +0800

On 17 Nov 2019, at 11:37, Dirk Kutscher wrote:

> Martin and Dave, could you have a look at the 05 version of this draft and check whether it addresses your comments?
>
I went looking for an email that responded to my individual comments but didn’t find one. Did I miss it? I was hoping to not have to do an entire additional careful read-through to figure out if my individual comments were addressed and how.

If I didn’t miss anything I’ll go ahead and read -05 through from top to bottom, but it may take me a while to find the time.

DaveO

---

From: "Anil Jangam (anjangam)" <[email-masked]>
Date: Sun, 17 Nov 2019 19:07:51 +0000

Hello Dave,

We did incorporate your review comments. I provide below exact changes we made for each of your comments. Hope this helps.

Detailed comments:

•          On the top of page 10, you say “However, a common limitation of these research efforts is that they focus on faster routing of Interest request towards the content rather than the quality of experience based on actual content delivery. For that to happen, QoS should be implemented and enforced on the Data packet path.” I don’t know what this is doing here. It isn’t terribly helpful to just invoke QoS. It’s also not appropriate to bring QoE into this, as QoE is an application layer concept. Lastly, there is current research on QoS for ICN, so the statement isn’t all that accurate.

[AJ] We reworded it as – “focus of these research efforts is on faster routing of Interest requests towards the content rather than content delivery.”

•          On page 11, you say “The mapping of CoS to DSCP takes place at layer 2/3 switching and routing elements.” Isn’t it the opposite - the DSCP is mapped to the COS rather than vice versa?

[AJ]  [A close up of a device  Description automatically generated]

•          On page 13, I’m not sure what you are trying to say with “The content matching tuple uniquely identifies the correlation between an Interest and data packet.” I don’t think correlation is the right word. Please re-work to say something to the effect that the Interest is matched against the named date subject to the tuple referred to above.

[AJ]  

•          A bit further down, while a detail and maybe not worth mentioning, some loops are in fact suppressed through Interest aggregation only loops that look like Interest retransmissions coming in through the same ingress interface as an earlier Interest produce persistent looping that has to be caught with the hop limit.

[AJ] We removed the concerning statement from the text. See below.

[AJ]   [A close up of a device  Description automatically generated]

•          On page 14, I’m not sure what you mean by “signed key”? In any event the actual key is not usually in the data packet; only a key-id or key locator.

•          on page 17, what do you mean by “stored in the ICN node”? Is this producers, repos, caches, or all of the above?

[AJ] To address this, we added this – “stored in the ICN node (such as repos, caches)”

•          On page 19, you assert the “main advantage of ICN is in caching and reusing content”. I would disagree with this statement, and it isn’t necessary to your argument that the work needed to convert LTE signaling protocols to ICN might be a bad use of engineering and design effort.

[AJ] To address this we paraphrased it as – “One of the advantages of ICN is in the caching and reusing of the content”

•          On page 21, it might be worth toning down the assertion that providing a transport-level API that is comment for IP and ICN would result in no impact on application programmers. While that might be true in a literal sense, if you don’t give application programmers access to the richness of ICN semantics (e.g. hierarchical names, trust schemas based on those names, etc.) arguably much of the benefit of introducing ICN in the first place is lost.

[AJ] To address this toning down, we paraphrased it as – “Our proposal is to provide an Application Programming Interface (API) to the application developers so they can choose either ICN or IP transport for exchanging the traffic with the network”. We removed the wording “no impact on ..”

•          On page 26, some requirements language is creeping in - you say “eNodeB shall be upgraded…”. There may be other instances of this, so I’d recommend a scrub to get rid of things that smack of requirements language.

[AJ] We paraphrased it as – “eNodeB can be upgraded to support three different types of transport”

•          On page 29, in the proposed test scenarios you say “EPC: Cisco evolved Pack Core…”. I’d scrub this since one would not want a test deployment specification to require a particular vendor’s LTE implementation.

[AJ] We reworded it to remove mention of Cisco – “EPC: Evolved Packet Core in a single instance (such as vPC-SI).”

Thank you,

/anil.

    DaveO

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 27 Nov 2019 12:05:06 -0500

I went through the -05 (finally - sorry for the delay), and the writing 
is substantially improved. There are still a number of grammar glitches 
an infelicitous wordings, but it probably would not be helpful to 
request another pass at this point. If this gets positive reception from 
the IRSG reviewers, the remaining editorial corrections can be made 
during RFC editor processing.

In terms of the responses to my comments, I’m not 100% happy, but 
I’d again rather this got IRSG review with a new set of eyes than 
holding things up. See below for the few places I think my comments 
might have not been adequately addressed. I snipped out the ones that we 
are on the same page for.

So, let’s pass this on to the next stage of IRSG review as long as 
Martin is also happy.
DaveO.

On 17 Nov 2019, at 14:07, Anil Jangam (anjangam) wrote:

> •          On the top of page 10, you say “However, a common 
> limitation of these research efforts is that they focus on faster 
> routing of Interest request towards the content rather than the 
> quality of experience based on actual content delivery. For that to 
> happen, QoS should be implemented and enforced on the Data packet 
> path.” I don’t know what this is doing here. It isn’t terribly 
> helpful to just invoke QoS. It’s also not appropriate to bring QoE 
> into this, as QoE is an application layer concept. Lastly, there is 
> current research on QoS for ICN, so the statement isn’t all that 
> accurate.
>
> [AJ] We reworded it as – “focus of these research efforts is on 
> faster routing of Interest requests towards the content rather than 
> content delivery.”
>
This isn’t an improvement, I don’t think. QoS is about unfair 
allocation of resources, which applies equally to routing of requests 
and delivery of content. There is active research spanning the whole 
range of designs and machinery. I can provide citations if you want.

>
>
> •          On page 14, I’m not sure what you mean by “signed 
> key”? In any event the actual key is not usually in the data packet; 
> only a key-id or key locator.
>
I no longer see the offending text, but since the page numbers have 
changed I don’t have the context to know whether the underlying 
comment is still valid and there’s no specific response in the email 
to this comment.

> •          on page 17, what do you mean by “stored in the ICN 
> node”? Is this producers, repos, caches, or all of the above?
>
Hmmm, there’s more going on here than I noticed the first time around. 
The text still confusing me is the qualifier “in the tunnel path” 
since if you do ICN there is no longer a tunnel path. In any event, now 
that at my request you mention repositories (and you should probably 
spell that out rather than using the shorter “repos”) the text is 
now wrong since repositories don’t have to be on-path to the producer 
and can be separately expressed in the routing.