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

[Colin Perkins <[e-mail]>]

Thanks Vincent, authors,

I’ll start the IRSG final publication ballot now. We can address this, along with any other comments than come in during the ballot.

Colin


> On 21 Apr 2021, at 08:53, Vincent Roca <[e-mail]> wrote:
> 
> Dear authors, everybody,
> 
> Thank you for your response, Jungha.
> 
> I’m okay with the updated I-D.
> I’m just wondering what is meant by « five 9s, or five sigmas » in the following sentence of section 4.3. 
> 
> 	The NRS system may provide a probability (say, five 9s,	
> 	or five sigmas for instance) that a resolution will be satisfied.
> 
> I guess « 99.999% » for the « five 9s », but I don’t understand the notion of sigmas. Sorry.
> This is nota blocking point anyway.
> 
> Cheers,
> 
>   Vincent
> 
> 
>> Le 12 avr. 2021 à 10:13, Jungha Hong <[e-mail] <mailto:[e-mail]>> a écrit :
>> 
>> 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] <mailto:[e-mail]>>
>> To: "Colin Perkins" <[e-mail] <mailto:[e-mail]>>; "The IRSG" <[e-mail] <mailto:[e-mail]>>; "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>; <[e-mail] <mailto:[e-mail]>>;
>> Cc: "Vincent Roca" <[e-mail] <mailto:[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."
>> 
>> 
>>> 
>>> 
>>> 
>>>