[icnrg] Last Call comments on draft-irtf-icnrg-nsarch-considerations-02

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

These comments are with <chair hat off>.

In general, the technical content of this draft is in good shape and in 
my opinion it is mostly ready to to advance. I have both some technical 
and editorial comments below. I think both sets can be resolved without 
requiring a second last call and just incorporated in a revised draft 
prior to sending on for IRSG review.

Technical comments:

- on page three you talk about “sequencing” name resolution request 
queries. It’s not clear what is meant by this, since one would think 
individual queries are independent of one another and don’t need any 
ordering properties. Perhaps you mean the processing of a single query 
through the protocols that manage the distributed nature of the NRS? 
Some clarification is needed here.

- a bit further down, it would be good to disentangle the various forms 
of output from an NRS query, since returning a locator, a off-path-cache 
pointer, or an alias name are all different results that could affect 
what the next action by the NRS client might be. Some more detail would 
help.

- you assume NRS resolvers have caches. This is itself an architectural 
consideration since caches can be wrong and clients of the NRS need a 
way to figure out if they are getting authoritative information or not 
to have a workable retry/fallback strategy. Perhaps re-work this to 
separate out the question of NRS caches.

- on page 4 you use the term “authority domain” which I don’t 
think is generally understood the same way by everybody. Do you actually 
mean “autonomous system”, or something else? Perhaps the 
authoritative domain that owns the name assignment for a portion of a 
namespace?

- on page 5 you assert that name-based routing has to be scalable enough 
to achieve “optimal location” of the requested content in the 
routing table. I think this is not an absolute requirement, as achieving 
optimality if a lot harder than achieving reachability at overhead 
considerably below that incurred by flooding. The key is if using an NRS 
provides better state*rate algorithmic complexity than pure name-based 
routing and under what circumstances.

- the discussion of name registration by forwarder caches needs a bit of 
work. If you only do on-path caching, it is not necessary to involve the 
NRS in forwarder caches. Involving an NRS may be a good idea for 
off-path caching, but alternatives like cooperative caching also exist.

- in the next bullet section you say FIBs tell you if the content name 
exists. No, it only tells you if the routing system considers it 
reachable.

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).

- a couple of sections need to be added and/or filled out: IANA 
considerations, Acknowledgments.

- 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. 
Obviously, ditto for the requirements draft - I’ll be posting comments 
on that once I finish a second pass through it.

[End of comments]

DaveO