[icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02
"David R. Oran" <daveoran@orandom.net> Mon, 09 September 2019 14:59 UTC
Return-Path: <daveoran@orandom.net>
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 B131B12022D for <icnrg@ietfa.amsl.com>; Mon, 9 Sep 2019 07:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 fBk2Wjnlos25 for <icnrg@ietfa.amsl.com>; Mon, 9 Sep 2019 07:59:25 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (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 1B5DA12008B for <icnrg@irtf.org>; Mon, 9 Sep 2019 07:59:25 -0700 (PDT)
Received: from [192.168.2.1] ([IPv6:2601:184:4081:19c1:558:b085:4473:2cc5]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id x89ExHC4025473 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <icnrg@irtf.org>; Mon, 9 Sep 2019 07:59:19 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Mon, 09 Sep 2019 10:59:17 -0400
X-Mailer: MailMate (1.12.5r5649)
Message-ID: <C14EAB0C-BF29-4878-B4A5-D3C3CD3EBAC8@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_61A6C4C1-8C51-4B1F-9237-0435BAB8E3EF_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/69GPK0IO25YJDFcrCWjTpUXPP40>
Subject: [icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02
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, 09 Sep 2019 14:59:28 -0000
These comments are with <chair hat off>. The technical content of this draft is in decent shape and in my opinion it is close to ready to advance. I have both technical and editorial comments below. The technical comments may require a second last call as the changes may alter some of the requirements. The chairs should make this assessment after gathering all the last call comments. Technical comments: - The use of the term “content discovery” to refer to the forwarding of Interests toward producers (or the equivalent procedure for architectures other than CCNx/NDN) is unfortunate, as we would like to use this term to refer to the refinement process of figuring out which content object(s) you want to retrieve as opposed to the actual retrieval. The terminology document (which should be referenced - I didn’t see it in the list), while formally only defining “Interest packet” as the term of art for CCNx and NDN, suggests “information request” as a general synonym. I suggest we switch to either that or “content request”. - The first part of section 3 needs some work. For example, it talks about reaching a “host”, which is sure to be confusing in the context of ICN. What you reach are “information objects which represent a particular host and live only on that host”. There is also some RFC2119-like language (e.g. lowercase “shall”) that needs to get eliminated. Third, locators don’t “represent” a current instance of the requested object, they “can reach” a current instance. Saying “represent” has the implication of some authoritative relationship or “binding” to the actual object. - The second bullet of 3.4 overstates the characteristics of explicit name resolution. It can’t “guarantee” resolution of any content name in any absolute sense. This should be toned down with some qualification: “The explicit name resolution approach, if designed and deployed with sufficient robustness, can offer at least weak guarantees that resolution will succeed for any content name in the network…”. - In the third bullet of 3.4, what do you mean by “locally-maintained name-based routing tables”? Static routes? I don’t think that’s what you’re trying to say. - In the fourth bullet (top of page 6) you end by saying “optionally breadcrumbs for reverse routing…” I don’t think this is part of name resolution, optional or not. It’s part of the low-level packet forwarding machinery in NDN and CCNx. - In the first paragraph of 4.1, which is talking about heterogeneous name types, there’s this peculiar sentence “ICN requires uniqueness and persistency of the name of data object to ensure the reachability of the object within a certain scope and with proper authentication and trust management.” I’m not sure what you’re trying to say, particularly around authentication and trust. Perhaps this belongs elsewhere? Or if it does belong here, what are the implications on the requirements for an NRS? - In the second paragraph, you say “trust provenance”. Trust and provenance are separate concepts. Provenance is knowing the origin of something (including what it may have been derived from). Trust is what sort of belief you have in the provenance assertions. - A bit further along, you mention “any type of content name”, mentioning only flat and hierarchical. There is also attribute based, and perhaps others. - In the second paragraph of 4.2, you claim “publisher mobility in ICN is complicated”. Maybe yes, maybe no. What might be better is to say that “producer mobility does not emerge naturally from the ICN forwarding model as does consumer mobility”. - A bit further down you talk about an “authority domain”, which isn’t a well-defined term in this context (and even if so it more likely means “the authority responsible for name assignment”, not what you say here). I think you actually mean “autonomous system” and if that’s not what you intend please try again? - In the discussion of off-path caching in 4.4, there’s an assertion that this capability is “essential” for an AS to avoid costly inter-AS traffic. How do you reach this conclusion? Where does on-path caching fail to reduce inter-AS traffic, especially if the caches are present in the entry border routers of the AS? - At the end of section 4.5, you assert that the consumer needs to resolve proper name and hashes through “an outside system” like NRS, and then the very next paragraph contradicts this by discussing how Manifests solve at least part of the problem. - Section 5.4 on fairness needs some work. In the absence of any QoS feature in the overall ICN architecture, achieving fairness of service in the NRS is probably a good goal, although you need to be a bit more specific about what those properties should be. Per request delay? Something else? More importantly, once one considers QoS generally for ICN (e.g. as proposed in draft-oran-icnrg-qosarch), explicit unfairness needs to be introduced into the design of the NRS as well. - Under scalability, the utility of the requirements are pretty minimal in the absence of any quantification. For example, what constitutes a “very large content catalog”? 10**9? 10**12? - A bit further down, you say it’s desirable that addition of a new server have “limited impact” on the other NRS servers. I think you mean “limited negative impact”, as its possible and desirable that adding a server might have *positive* impact on the other servers, either by reducing their request load, or allowing them to store fewer mapping entries. - In section 5.6 on management, it would be really helpful to talk about measurement as well as management. - The section on accessibility under security considerations (7.1) talks about access control but fails to distinguish between encryption-based techniques using control of keys versus a reference monitor that uses client authentication to control the propagation of the mappings. A bit further down you imply that producer authentication could be optional. I don’t see how that flies under even minimal threat models. Editorial comments: - As a general comment, the draft needs a considerable amount of editing for English language usage, grammar, etc. before it’s ready to go for IRSG review. If the authors agree, I would be willing to take this on and produce a cleaned-up version once we have resolution of the technical comments (both those above and those of other ICNRG reviewers). - It would be helpful to have in the introduction a cross-explanation of what is in this document versus what is in the NRS requirements draft. I mentioned this also for the considerations draft. - All instances of “CCN” should be changed to “CCNx”. - Given that this document is not intended to be normative, we need a scrub of RFC2119 requirements statements like “shall”, even if lower case. - In section 3.2, name resolution does not in general “determine” the routing path for the data - perhaps a better word would be “derives”? - in 3.3, you say “few of the nodes in the architecture perform name resolution”. That isn’t quite right as the architecture is abstract not concrete. Perhaps just say “few of the nodes in the ICN network…” - On page 7 in the description of Mobility First, you say “self-certifying function”, when I think you mean “self-certifying properties”. - on page 11, when you say “file” I think you mean “object”. - a bit further down s/be very greatly/vary greatly/. [End of comments] DaveO
- [icnrg] Last Call comments on draft-irtf-icnrg-nr… David R. Oran
- Re: [icnrg] Last Call comments on draft-irtf-icnr… liyinghua
- Re: [icnrg] Last Call comments on draft-irtf-icnr… Jungha Hong
- Re: [icnrg] Last Call comments on draft-irtf-icnr… Thomas C. Schmidt