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

["David R. Oran" <[e-mail]>]

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