Architectural Considerations of ICN using Name Resolution Service
draft-irtf-icnrg-nrsarch-considerations-06

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