[icnrg] RG Last call comments on the ICN in LTE, 4G document

These are my RG Last Call comments on draft-irtf-icnrg-icn-lte-4g, all 
with <Chair Hat Off>. My apologies for the lateness of these comments; 
hopefully they won’t contribute to any delay in progressing the work. 
I have a two general comments, and a few detailed comments. These are:

##General Comments:##

- The technical content seems sound and from that perspective I believe 
the work should be progressed to IRSG Review and toward eventual 
publication. Note that my assessment is of someone with limited grasp of 
the complexities of LTE networks, and hence there may be errors lurking 
in here. I expect the cellular mobile knowledgeable ICNRG participants 
will also have reviewed the draft and are comfortable with its 
correctness. In other words, don’t rely on my assessment here.

- On the negative side, the writing is very uneven and contains a 
plethora of English grammar and usage errors. The document needs a copy 
editing pass from a native English speaker with technical documentation 
skills. While we could perhaps have the current version progress as-is 
for the IRSG review and wait for this to be done by the RFC production 
center, it would be better to not saddle the IRSG with slogging through 
the text as it now stands, given that the technical material is dense 
and the document quite long at 37 pages. My recommendation is to find a 
volunteer to do this if the authors do not feel comfortable doing this 
themselves.

##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.

- 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?

- 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.

- 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.

- 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?

- 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.

- 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.

- 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.

- 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.

[End of comments]

On 19 Sep 2019, at 22:28, Börje Ohlman wrote:

> 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

> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO