Re: [icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02

<> Wed, 18 September 2019 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0874612021C for <>; Wed, 18 Sep 2019 04:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4vwsj7KL0tef for <>; Wed, 18 Sep 2019 04:36:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E1E17120024 for <>; Wed, 18 Sep 2019 04:36:09 -0700 (PDT)
Received: from dspPC (unknown []) by APP-01 (Coremail) with SMTP id qwCowAAnbOmhFoJdzPnwBw--.30S2; Wed, 18 Sep 2019 19:36:04 +0800 (CST)
From: <>
To: "'David R. Oran'" <>, <>
Cc: =?UTF-8?Q?'B=C3=B6rje_Ohlman'?= <>, "'Dirk Kutscher'" <>
Date: Wed, 18 Sep 2019 19:36:07 +0800
Message-ID: <082301d56e15$463cdca0$d2b695e0$>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0824_01D56E58.547EEF40"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdVuE1u1kLaYR4bhSpuxZ6dLVtprrA==
Content-Language: zh-cn
X-CM-TRANSID: qwCowAAnbOmhFoJdzPnwBw--.30S2
X-Coremail-Antispam: 1UD129KBjvJXoW3GFWDXw13XFyxWrW7ur4fAFb_yoWftF13pF s3KFWrCFn5J34Skw1fZw48uFyrCr95trZxJas5tr9xA398Ww1xKr1fKw45Za4Dur1xJr1j vwsFq3s8Cwn5ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2vj62AExVA0xI801c8C04v26x02cVCv0xWle2I2 62IYc4CY6c8Ij28IcVAaY2xG8wASzI0EjI02j7AqF2xKxwAqx4xG64xvF2IEw4CE5I8CrV C2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE 7xkEbVWUJVW8JwCY02Avz4vEjI4l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67 AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU538n7UUUUU==
X-Originating-IP: []
X-CM-SenderInfo: pol1x0pjkxtqxgvshtffof0/
Archived-At: <>
Subject: Re: [icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Sep 2019 11:36:17 -0000

Thanks Dave for your comments guidelines, 

Here attached is the updated comments and general questions .
There are a few technical comments in section5.1 where we have done considerable research. 
I am open for discussion if this causes confusion. 


发件人: David R. Oran [] 
发送时间: 2019年9月12日 19:52
抄送: Börje Ohlman; Dirk Kutscher
主题: Re: 答复: [icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02

On 11 Sep 2019, at 21:05, wrote:

> Hi Dave,
> How many more reviewers do you normally need in the last call to move 
> this draft to the next stage?
There’s no set number, but the more the better.

> I have put some informal comments together in attached pdf but I can 
> rewrite them in plain email text if that format is required.
> Please just let me know.
I’m really happy to see your participation and willingness to help the group. Yes, please submit the comments to the icnrg list. There’s no particular format required, so your marked up PDF is fine if you find that the best way to send the comments. If you’d prefer to convert to text that’s fine too.

(I copied the other two icnrg chairs so they know what’s up with the progress on RG last call.)


> Regards,
> Vera
> 发件人: David R. Oran []
> 发送时间: 2019年9月9日 22:59
> 收件人: ICNRG
> 主题: [icnrg] Last Call comments on
> draft-irtf-icnrg-nrs-requirements-02
> 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