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

From: Jungha Hong <[email-masked]>
Date: Mon, 12 Apr 2021 17:13:23 +0900 (KST)

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.&nbsp;We tried to address your comments as much as possible.&nbsp;
(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" &lt;[email-masked]&gt;
To: "Colin Perkins" &lt;[email-masked]&gt;; "The IRSG" &lt;[email-masked]&gt;; "[email-masked]" &lt;[email-masked]&gt;; &lt;[email-masked]&gt;;
Cc: "Vincent Roca" &lt;[email-masked]&gt;;
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&nbsp;draft-irtf-icnrg-nrs-requirements-04.
It’s globally clear/well written. I have a few comments though.
Hope it will be useful.

Regards, &nbsp; 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")
&nbsp; &nbsp; &nbsp; &nbsp; The current text of section 4.3 is pretty strong and uses a "must" (in lowercase letters however):
&nbsp; &nbsp; &nbsp; &nbsp; "An NRS must ensure that the name resolution would be successful if the name matching content exists in the network."
&nbsp; &nbsp; &nbsp; &nbsp; There's a contradiction with section 4.1 about resolution response time, especially if we consider the delay-sensitive scenarios mentioned in 4.1.
&nbsp; &nbsp; &nbsp; &nbsp; At a minimum the sentence should be nuanced.
&nbsp; &nbsp; &nbsp; &nbsp; 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
&nbsp; &nbsp; &nbsp; &nbsp; The current "Security considerations" section is not satisfying IMHO.
&nbsp; &nbsp; &nbsp; &nbsp; Security/privacy is key to any name resolution service: it's the case of DNS, it's the case here also.
&nbsp; &nbsp; &nbsp; &nbsp; 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.
&nbsp; &nbsp; &nbsp; &nbsp; 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). 

&nbsp; &nbsp; &nbsp; &nbsp; Otherwise, a few comments for current section 7:
&nbsp; &nbsp; &nbsp; &nbsp; - 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).
&nbsp; &nbsp; &nbsp; &nbsp; - The term "accessibility" is awkward, it's about access control and strongly related to 7.2 authentication and 7.3 confidentiality.
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This is why gathering this under "C(onfidentiality)" could help reduce redundancy.
&nbsp; &nbsp; &nbsp; &nbsp; - Integrity (of the NRS system, the databases used, the names, etc.) is omitted.
&nbsp; &nbsp; &nbsp; &nbsp; - Resiliency is part of availability.

&nbsp; &nbsp; &nbsp; &nbsp; 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 &nbsp;complete rewrite.

Other points:

** About use of RFC2119 keywords.
&nbsp; &nbsp; &nbsp; &nbsp; [RFC2119] is listed, but there is no reference to it (no section about the compliance to RFC2119 in particular).
&nbsp; &nbsp; &nbsp; &nbsp; 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):
&nbsp; &nbsp; &nbsp; &nbsp; 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."
&nbsp; &nbsp; &nbsp; &nbsp; I understand the NRS chooses which route to take for the consumer’s request.
&nbsp; &nbsp; &nbsp; &nbsp; 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:
&nbsp; &nbsp; &nbsp; &nbsp; I find the item "o &nbsp;Update message overhead:" a bit obscur. I understand the need for an update, but not the impacts on the two NRS.
&nbsp; &nbsp; &nbsp; &nbsp; For instance, this is the first place where "name resolution overlay" is mentioned.
&nbsp; &nbsp; &nbsp; &nbsp; 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):
&nbsp; &nbsp; &nbsp; &nbsp; "to help a consumer to reach a specific piece of information (or named data objects)"
&nbsp; &nbsp; &nbsp; &nbsp; I suggest to use singular for coherency: "(or name data object)"

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

---

From: Vincent Roca <[email-masked]>
Date: Wed, 21 Apr 2021 09:53:25 +0200

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 <[email-masked]> a écrit :
> 
> Dear Vincent,
> 
> 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>)
> 
> From: "Vincent Roca" <[email-masked]>
> To: "Colin Perkins" <[email-masked]>; "The IRSG" <[email-masked]>; "[email-masked]" <[email-masked]>; <[email-masked]>;
> Cc: "Vincent Roca" <[email-masked]>;
> Below is my review of draft-irtf-icnrg-nrs-requirements-04.
> Regards,   Vincent
>         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?
> 
>         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).
> 
>         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.
> 
> Hopefully, it will be OK since you are not asking for a  complete rewrite.
> 
> Other points:
> 
>         [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?
> 
>         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.
> 
>         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.
> 
>         "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)"
> 
> 
>         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."
> 
> 
>> 
>> 
>> 
>> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Apr 2021 14:14:45 +0100

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 <[email-masked]> wrote:
> 
> Dear authors, everybody,
> 
>> Le 12 avr. 2021 à 10:13, Jungha Hong <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Dear Vincent,
>> 
>> From: "Vincent Roca" <[email-masked] <mailto:[email-masked]>>
>> To: "Colin Perkins" <[email-masked] <mailto:[email-masked]>>; "The IRSG" <[email-masked] <mailto:[email-masked]>>; "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>>;
>> Cc: "Vincent Roca" <[email-masked] <mailto:[email-masked]>>;

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 21 Apr 2021 16:36:31 +0000

Hi Vincent,

First, merci beaucoup for the super quick and kind response. It’s greatly appreciated.

Regarding your comment, here’s what the 5 sigmas refer to:
https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule#:~:text=In%20the%20social%20sciences%2C%20a,to%20qualify%20as%20a%20discovery.
However, since it is not clear, and since 5 9s is usually what network operators use, we can just remove that mention.
“The NRS system may provide a probability (say, five 9s) that a resolution will be satisfied.”

Best regards,

C.

From: icnrg <[email-masked]> On Behalf Of Vincent Roca
Sent: Wednesday, April 21, 2021 12:53 AM
To: Jungha Hong <[email-masked]>
Cc: Vincent Roca <[email-masked]>; [email-masked]; [email-masked]; Colin Perkins <[email-masked]>; The IRSG <[email-masked]>
Subject: Re: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-nrs-requirements-04

Dear authors, everybody,

Cheers,

  Vincent

Le 12 avr. 2021 à 10:13, Jungha Hong <[email-masked]<mailto:[email-masked]>> a écrit :

Dear Vincent,

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-irtf-icnrg-nrs-requirements-05&data=04%7C01%7Ccedric.westphal%40futurewei.com%7C80b6ef4ae598482fa8c708d9049a967a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637545884289674074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vzx7gX6ZKEBVX6ofKXexAVGIOEQy7UEU1a5lfVCBnsw%3D&reserved=0>)

Thanks,
Jungha Hong

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

Regards,   Vincent

——

Main points:

        - It's common to use the CIA triad to structure such security discussions (https://en.wikipedia.org/wiki/Information_security#Key_concepts<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInformation_security%23Key_concepts&data=04%7C01%7Ccedric.westphal%40futurewei.com%7C80b6ef4ae598482fa8c708d9049a967a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637545884289684062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GYv80lijq3JjcWOiAoIggFQPifgbr8X9htIXFm9iijw%3D&reserved=0>).

Other points:

** Section 2 (intro):

** Section 2.4:

Typos, minor comments:

** Section 2 (intro):