Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
draft-irtf-icnrg-nrsarch-considerations-07

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-irtf-icnrg-nrsarch-considerations-07 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
IANA Operations Manager

[Ballot comment]

Minor comments:

- Section 4 says: "When an NRS is included in an ICN architecture, security threats may
increase." I think what's meant is that the attack surface is increased when any new
component (in this case an NRS) is introduced.  Also, "These challenges must be overcome
by taking appropriate security measures into consideration." seems a bit of a useless
thing to say.

- I can think of two security/privacy issues that may be worth a mention but that are not
currently mentioned: 1) some equivalent to QNAME minimisation and 2) introduction of an NRS
might encourage development of a passive DNS equivalent with all the upsides and downsides
of that.

[Ballot comment]
A completely trivial observation: in section 2 you've got an extraneous space in "off- path-cache pointer".
Less trivial: the first bullet item in the security considerations section is a bit vague and could be clearer that you're concerned about authenticity (if I'm reading it correctly).  "Security mechanisms" is not a particularly meaningful phrase.  But I don't think that seriously impacts the quality of the document, which is overall quite good.

[Ballot comment]
This document is ready for publication. The only question I has is why this document and draft-irtf-icnrg-nrs-requirements are two different documents?

One nit: Please spell out FIB.

Also one question out of curiosity: Could DNS (besides its known problems) be used as an NRS or are there particular limitation in DNS that make it infeasible to be used for ICN systems? Maybe you can add some notes to the draft?

This and its companion document https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrs-requirements/ passed ICNRG Last call in January, and has the support of the RG to progress toward publication as an Informational RFC. The two documents have had a long gestation period, and the RG debated multiple times the general importance of name resolution services as a distinct set of capabilities for ICN networks, and exactly what the scope of those services ought to be for different ICN architectures, including CCNx and NDN. While there is no strong consensus on that issue, from the last call comments (only a few) and the sidebar discussions, the chairs assess that on balance these documents provide useful background and a valuable discussion of various tradeoffs and approaches to the subject.

During pre-IRSG review by the IRTF Chair, some questions and issues were raised on the Arch Considerations draft. The authors prepared an updated version addressing these comments and also did an editing pass with the help of the document shepherd  to improve the writing.

We therefore believe this document is ready for IRSG Review and hopefully progression toward publication.

This and its companion document https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrs-requirements/ passed ICNRG Last call in January, and has the support of the RG to progress toward publication as an Informational RFC. The two documents have had a long gestation period, and the RG debated multiple times the general importance of name resolution services as a distinct set of capabilities for ICN networks, and exactly what the scope of those services ought to be for different ICN architectures, including CCNx and NDN. While there is no strong consensus on that issue, from the last call comments (only a few) and the sidebar discussions, the chairs assess that on balance these documents provide useful background and a valuable discussion of various tradeoffs and approaches to the subject.

We therefore believe these are ready for IRSG Review and hopefully progression toward publication.

Request for posting confirmation emailed to previous authors: Ved Kafle , Jungha Hong , icnrg-chairs@ietf.org, Bastiaan Wissingh , irtf-chair@irtf.org, Yong-Geun Hong , Taewan You