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

Hi Dave,

Thank you for your constructive feedback. We held another review where we addressed your and Martin’s comments. Our technical writer is reviewing the latest version as you suggested. We will have a final corrected version uploaded before the IETF-106 cut-off time.

Thanks,
Milan

From: icnrg <icnrg-bounces@irtf.org> On Behalf Of David R. Oran
Sent: Sunday, October 27, 2019 10:28
To: icnrg@irtf.org
Subject: [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<mailto:icnrg@irtf.org>
https://www.irtf.org/mailman/listinfo/icnrg

DaveO