Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
draft-irtf-icnrg-nrsarch-considerations-07
Note: This ballot was opened for revision 06 and is now closed.
Ballot question: "Is this draft ready for publication in the IRTF stream?"
Colin Perkins
(was No Objection)
Yes
Melinda Shore
Yes
Comment
(2021-07-16 for -06)
Sent
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.
Jane Coffin
No Objection
Mirja Kühlewind
No Objection
Comment
(2021-07-16 for -06)
Sent
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?
Stephen Farrell
No Objection
Comment
(2021-07-26 for -06)
Sent
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.