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

Jungha Hong <> Mon, 18 November 2019 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D5A4120071 for <>; Sun, 17 Nov 2019 16:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9NQB94xCsd83 for <>; Sun, 17 Nov 2019 16:14:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 434F112000F for <>; Sun, 17 Nov 2019 16:14:57 -0800 (PST)
Received: from unknown (HELO ( by with ESMTP; 18 Nov 2019 09:14:51 +0900
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 18 Nov 2019 09:14:51 +0900
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Mon, 18 Nov 2019 09:14:51 +0900
From: Jungha Hong <>
To: "" <>, "" <>
Thread-Topic: [icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02
Thread-Index: AdVuE1u1kLaYR4bhSpuxZ6dLVtprrAvkSsC8
Date: Mon, 18 Nov 2019 00:14:51 +0000
Message-ID: <>
References: <082301d56e15$463cdca0$d2b695e0$>
In-Reply-To: <082301d56e15$463cdca0$d2b695e0$>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach: yes
x-new-displayname: SnVuZ2hhIEhvbmc=
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_004_F8EFC212DF9A004DA18AA8FB011E4233BB944F88SMTP1etriinfo_"
MIME-Version: 1.0
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: Mon, 18 Nov 2019 00:15:02 -0000

Dear Vera,

Thank you for reviewing the document.

I attached a file with my response to your all comments.

Please let me know if anything is unclear.

BTW, I am sorry for my late response.



보낸 사람 : "" <>
보낸 날짜 : 2019-09-18 20:36:38 ( +09:00 )
받는 사람 : 'David R. Oran' <>, <>
참조 : 'Börje Ohlman' <>, 'Dirk Kutscher' <>
제목 : Re: [icnrg] Last Call comments on draft-irtf-icnrg-nrs-requirements-02

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 .


> 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