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

From: "David R. Oran" <[email-masked]>
Date: Mon, 09 Sep 2019 10:59:17 -0400

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

---

From: <[email-masked]>
Date: Wed, 18 Sep 2019 19:36:07 +0800

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. 

Regards,
Vera

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

On 11 Sep 2019, at 21:05, [email-masked] 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.)

Best,
DaveO.

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

DaveO