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

["David R. Oran" <[e-mail]>]

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.