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

From: "Reed, Martin J" <[email-masked]>
Date: Wed, 8 Jan 2020 11:40:58 +0000

Hi Milan,

Only just managed to get this popped off the top of my todo list, so thanks for your patience and Happy New Year.

My comments were mainly editorial and these have been addressed. Version 5 looks much better.

Just spotted couple more more minor errors:

In point 4. IP over ICN (IPoICN)
of Section 4.2:

"H2020 project [H2020] provides an architectural framework...” should be
"H2020 project POINT [H2020] provides an architectural framework…”

and later in the same point

“...which is also called as a network attach point (NAP).” should be
“...which is also called a network attachment point (NAP).

Regards,

Martin

Dr. M.J. Reed                                         Room:       1NW.4.18
School of Computer Science and Electronic Engineering
Tel:+44 (0)1206 872479            FAX:+44 (0)1206 872900
University of Essex, Colchester CO4 3SQ, UK
Email [email-masked]<mailto:[email-masked]>
Web: http://csee.essex.ac.uk/staff/mjreed
Doodle meetme: http://doodle.com/martinjreed

On 19 Dec 2019, at 22:11, Milan Stolic (mistolic) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

First of all: Dave, thank you for your feedback.

I wanted to check with Martin if he feels that his concerns were addressed appropriately, and to see what we can do to move the draft to the next stage.

Thank you,
Prakash, Anil and Milan

-----Original Message-----
From: David R. Oran <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 27, 2019 11:05
To: Anil Jangam (anjangam) <[email-masked]<mailto:[email-masked]>>
Cc: Dirk Kutscher <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Milan Stolic (mistolic) <[email-masked]<mailto:[email-masked]>>; Börje Ohlman <borje.ohlman=[email-masked]<mailto:borje.ohlman=[email-masked]>>; Akbar Rahman <[email-masked]<mailto:[email-masked]>>; Prakash Suthar (psuthar) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

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?

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

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.