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

Jungha Hong <jhong@etri.re.kr> Mon, 12 April 2021 08:13 UTC

Return-Path: <jhong@etri.re.kr>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6152A3A1167 for <icnrg@ietfa.amsl.com>; Mon, 12 Apr 2021 01:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcPxdDt5FHts for <icnrg@ietfa.amsl.com>; Mon, 12 Apr 2021 01:13:30 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701F63A1168 for <icnrg@irtf.org>; Mon, 12 Apr 2021 01:13:29 -0700 (PDT)
Received: from unknown (HELO send002-relay.gov-dooray.com) (211.180.235.153) by 129.254.9.16 with ESMTP; 12 Apr 2021 17:13:21 +0900
X-Original-SENDERIP: 211.180.235.153
X-Original-MAILFROM: jhong@etri.re.kr
X-Original-RCPTTO: icnrg@irtf.org
Received: from [10.162.225.103] (HELO send001.gov-dooray.com) ([10.162.225.103]) by send002-relay.gov-dooray.com with SMTP id 8ac9715160740126; Mon, 12 Apr 2021 17:13:26 +0900
DKIM-Signature: a=rsa-sha256; b=f/GJuxCmGSRz0UKpxds0izT7kD8s3LUCgaVN2GwQuS+8+BUITPwLgOU7utNvAiDt8lwa9Xcel1 VEC9yP+L9QoSiVTGsZ0MUEo547x+U7S/zF+VGTWQKnQvQ2oLio1tAuvZyGRSD4YdHUUijRtXGZPX xD1DAdMyIMgueM8OXMf+pZ4NQ8wrgACCICIFzepZGpd8vBgX+KDv/Qkd2l8pKbPaxeffs+Ut7HE2 fC2SApR7cn9qdpeCNghctYlxH7V0ijM46S3PSUCbzUyAvshvDqN3Zc81EC5k1IEcb6XtkuxFGB3Z DGVrVlwuj10jMG1oOv8BiQJm3vzl5Q693t9HoZZg==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=uG+eIZo6bVz6R4hP/0SK3cX/94DnXKxAg1o3/I+EizQ=; h=From:To:Subject:Message-ID;
Dooray-Meta-Signature: Vt/9qifDZQ8XLGh0qDUdzY91JQYQO9F8GhBRo/j3sNnTvlZBaKyT5 xh1OfT33evv6s915o7W1VucUCd+W2Cmmzb1Yz6hTpO6WkJGj6mVBaiigzlMafiLUfPLuVCEGghQN +5cTstoN1WoRuXFWogBccBT1l4Wg9FkzJXEZcHLl5cWZGY8UoqFBAVTx1tnfMaAg8wFO6ooJOMpi J0mq/p9PXrTx3ZxUQlQcGfU8IwKGjKg+kjelb3zJouvP7C4v1j5fcTyoTE77LxqKHkeGq0PxWzCT o+YpjeBE//US992N/JK+BlQPWYtw2lGfvrRL/+wfX8e1lJdBk/LqDnQVI2ezvE6gGgAxAE6N86R6 ZYP/wM=
Received: from [129.254.70.83] (HELO 129.254.70.83) ([129.254.70.83]) by send001.gov-dooray.com with SMTP id e4c05bf660740124; Mon, 12 Apr 2021 17:13:24 +0900
From: Jungha Hong <jhong@etri.re.kr>
To: Colin Perkins <csp@csperkins.org>, The IRSG <irsg@irtf.org>, "icnrg-chairs@ietf.org" <icnrg-chairs@ietf.org>, Vincent Roca <vincent.roca@inria.fr>
Message-ID: <mol6npjb1drw.mol6npjbf7od.g1@dooray.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_31852_89065039.1618215202484"
X-Dsn-Request: true
X-Dooray-Agent: mail-api
X-Dooray-Mail-Id: 2985576830803600124
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Cc: icnrg@irtf.org
Sender: jhong@etri.re.kr
Date: Mon, 12 Apr 2021 17:13:23 +0900 (KST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/hDCG1gisMp8C1jrfGv-14Ag5Cnw>
Subject: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-nrs-requirements-04
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2021 08:13:36 -0000

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;vincent.roca@inria.fr&gtr&gt;
To: "Colin Perkins" &lt;csp@csperkins.org&gtg&gt;; "The IRSG" &lt;irsg@irtf.org&gtg&gt;; "icnrg-chairs@ietf.org" &lt;icnrg-chairs@ietf.org&gtg&gt;; &lt;draft-irtf-icnrg-nrs-requirements.authors@ietf.org&gtg&gt;;
Cc: "Vincent Roca" &lt;vincent.roca@inria.fr&gtr&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."