Re: [icnrg] [irsg] IRSG review request draft-irtf-icnrg-nrs-requirements-04
Vincent Roca <vincent.roca@inria.fr> Wed, 21 April 2021 07:53 UTC
Return-Path: <vincent.roca@inria.fr>
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 DD80B3A19BA; Wed, 21 Apr 2021 00:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 Bt8N1bD0T2WZ; Wed, 21 Apr 2021 00:53:30 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFC73A19BD; Wed, 21 Apr 2021 00:53:28 -0700 (PDT)
IronPort-HdrOrdr: A9a23:EHFU1KyUIx8rhAoH2FuhKrPw571zdoIgy1knxilNYDZSddGVkN3roe8S0gX6hC1UdHYrn92BP6foewK/ybde544NMbC+GDT3oWfAFu9fxKbr3jGIIU3D38FH06MISdkcNPTVLXxXyfn3+xO5FdFI+ra62YSln/3XwXsobQwCUcBdxjx0AAqaDUF6LTMubfFSKLOn+sFFqzC8EE56Uu2HABA+MtT+mw==
X-IronPort-AV: E=Sophos;i="5.82,238,1613430000"; d="scan'208,217";a="504260646"
Received: from clt-128-93-176-102.vpn.inria.fr ([128.93.176.102]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2021 09:53:25 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9A1D005-38F7-4C38-BAEF-8FB995C157F9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Vincent Roca <vincent.roca@inria.fr>
X-Priority: Normal
In-Reply-To: <mol6npjb1drw.mol6npjbf7od.g1@dooray.com>
Date: Wed, 21 Apr 2021 09:53:25 +0200
Cc: Vincent Roca <vincent.roca@inria.fr>, Colin Perkins <csp@csperkins.org>, The IRSG <irsg@irtf.org>, "icnrg-chairs@ietf.org" <icnrg-chairs@ietf.org>, icnrg@irtf.org
Message-Id: <45CE934E-4C9D-417E-A97B-0B69FC8DAB1D@inria.fr>
References: <mol6npjb1drw.mol6npjbf7od.g1@dooray.com>
To: Jungha Hong <jhong@etri.re.kr>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/yjBOJYej3Iln02abKkLoSZTh_KY>
Subject: Re: [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: Wed, 21 Apr 2021 07:53:36 -0000
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 <jhong@etri.re.kr> 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" <vincent.roca@inria.fr> > To: "Colin Perkins" <csp@csperkins.org>; "The IRSG" <irsg@irtf.org>; "icnrg-chairs@ietf.org" <icnrg-chairs@ietf.org>; <draft-irtf-icnrg-nrs-requirements.authors@ietf.org>; > Cc: "Vincent Roca" <vincent.roca@inria.fr>; > 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." > > >> >> >> >> > >
- [icnrg] [irsg] IRSG review request draft-irtf-icn… Jungha Hong
- Re: [icnrg] [irsg] IRSG review request draft-irtf… Vincent Roca
- Re: [icnrg] [irsg] IRSG review request draft-irtf… Colin Perkins
- Re: [icnrg] [irsg] IRSG review request draft-irtf… Cedric Westphal