[icnrg] [irsg] IRSG review request draft-irtf-icnrg-nrs-requirements-04

[Jungha Hong <[e-mail]>]

Dear Vincent,

Thanks a lot for taking the time to review this document.
First of all, I am sorry that it has been quite a long time to address your comments.

The revised document, draft-irtf-icnrg-nrs-requirements-05 has been submitted. We tried to address your comments as much as possible. 
(https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-nrs-requirements-05 https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-nrs-requirements-05)

Please find our responses explained in-line below and let us know if anything is unclear.

Thanks,
Jungha Hong


-----Original Message-----
From: "Vincent Roca" <[e-mail]>
To: "Colin Perkins" <[e-mail]>; "The IRSG" <[e-mail]>; "[e-mail]" <[e-mail]>; <[e-mail]>;
Cc: "Vincent Roca" <[e-mail]>;
Sent: 2020-10-23 (금) 19:41:05 (UTC+09:00)
Subject: Re: [irsg] IRSG review request draft-irtf-icnrg-nrs-requirements-04

Hello Colin, IRSG members and authors,

Below is my review of draft-irtf-icnrg-nrs-requirements-04.
It’s globally clear/well written. I have a few comments though.
Hope it will be useful.

Regards,   Vincent

——
This document is globally well written and well documented (many references to research documents and architectural proposals).
Parts of it are perhaps a bit hard to understand for a newcomer like me, but I guess it provides valuable content for a more informed reader.


Main points:

** Which guarantee? (section 4.3 "Resolution guarantee")
        The current text of section 4.3 is pretty strong and uses a "must" (in lowercase letters however):
        "An NRS must ensure that the name resolution would be successful if the name matching content exists in the network."
        There's a contradiction with section 4.1 about resolution response time, especially if we consider the delay-sensitive scenarios mentioned in 4.1.
        At a minimum the sentence should be nuanced.
        But it also raises key questions that are mostly ignored in the current document: is a strong guarantee feasible and is it desirable?

[Editor’s response and revision]
We updated the text there to make it more nuanced. We also added the idea of a probabilistic guarantee (as opposed to a MUST guarantee). 

** Security and privacy considerations
        The current "Security considerations" section is not satisfying IMHO.
        Security/privacy is key to any name resolution service: it's the case of DNS, it's the case here also.
        Although it's common to have a separate section in I-D/RFCs, it also suggests that it's a side consideration. It shouldn't.
        Since this is a design I-D, security/privacy should be part of the Design considerations section, and the new « 7. Security Considerations » section could refer to it and just provide additional content (e.g., (D)DoS protection).

[Editor’s response and revision]
We moved the Security consideration into Section 4.9 Security and privacy and put a pointer to Section 4.9 in Section 7. We changed the headings to comply with the Confidentiality/Integrity/Availability framework (CIA triad). 

        Otherwise, a few comments for current section 7:
        - It's common to use the CIA triad to structure such security discussions (https://en.wikipedia.org/wiki/Information_security#Key_concepts https://en.wikipedia.org/wiki/Information_security#Key_concepts).
        - The term "accessibility" is awkward, it's about access control and strongly related to 7.2 authentication and 7.3 confidentiality.
          This is why gathering this under "C(onfidentiality)" could help reduce redundancy.
        - Integrity (of the NRS system, the databases used, the names, etc.) is omitted.
        - Resiliency is part of availability.

        I guess privacy should also be part of the Design Considerations. There are overlaps with CIA, but it's broader.

[Editor’s response and revision]
We added the word Privacy in the confidentiality section. 

I’m not sure how far it should go (I don’t ask for a complete rewrite), it should at least mentioned, and perhaps a review published somewhere could be referenced?

[Editor’s response and revision]
Hopefully, it will be OK since you are not asking for a  complete rewrite.

Other points:

** About use of RFC2119 keywords.
        [RFC2119] is listed, but there is no reference to it (no section about the compliance to RFC2119 in particular).
        Is it intended or just an oversight?

[Editor’s response and revision]
We added a sentence pointing to RFC2119 at the beginning of section 4. (but with some weasel words as we’re doing considerations, not requirements). 

** Section 2 (intro):
        In sentence: "The consumer provides an NRS with a persistent name and the NRS returns a name or locator that can reach a current instance of the requested object."
        I understand the NRS chooses which route to take for the consumer’s request.
        I'm not sure it is the intention since 1st sentence of section 2.1 mentions "to return the locators" (plural), and suggests there’s a choice that is to be taken by the consumer between alternative locations.

[Editor’s response and revision]
We added some plural in Section 2 intro to be consistent with Section 2.1.

** Section 2.4:
        I find the item "o  Update message overhead:" a bit obscur. I understand the need for an update, but not the impacts on the two NRS.
        For instance, this is the first place where "name resolution overlay" is mentioned.
        More generally, although the previous parts was relatively easy to follow, section 2.4 is more obscur for a newcommer.

[Editor’s response and revision]
We replaced “name resolution overlay” with “system” and mentioned that it could be an overlay. 


Typos, minor comments:

[Editor’s response and revision]
All done.

** Section 2 (intro):
        "to help a consumer to reach a specific piece of information (or named data objects)"
        I suggest to use singular for coherency: "(or name data object)"


** Section 3.1, 1st paragraph.
        I suggest adding "or" instead of "," since they are opposed, as is already done for the last part of the sentence:
        "...which can be flat or hierarchical, and human readable or non-readable."