[icnrg] Comments on CCNinfo

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

Here are my comments on the current CCNinfo draft (-01). They are all 
with <Chair Hat off>.

However, with <Chair Hat on>, I’d like the ICNRG participants to give 
this draft serious attention cycles soon, as it appears fairly mature, 
has been implemented, and constitutes our first comprehensive tool for 
managing CCNx-based networks. It would be good if we could move this 
forward quickly.

**General Comments**

***Positioning***
After a fairly close reading my view is that there is minimal overlap in 
functionality and likely usage between CCinfo and our other proposed 
tools, ICN Ping and ICN Traceroute. It therefore makes sense to advance 
all three of these and sort out later how they are best used either 
separately or together.

***Overall Design***
The design is reasonable, and while one might quibble with some of the 
choices (e.g. use of hop-by-hop header fields rather than separate CCNx 
data objects for the report contents), it hangs together well, at least 
as far as I can see. It integrates with the forwarding architecture of 
CCNx rather than being implemented as a separate application on top, 
which brings some delicate tradeoffs in how forwarders work. The changes 
do seem manageable though, and should not adversely affect a fast 
forwarding path since the Request and Reply messages are demultiplexed 
though being carried in custom CCNx packet types, meaning they can be 
punted to a slow path at low overhead as needed.

***Security Approach***
The overall approach to security, while probably workable, is glaringly 
non-ICN like in design. It uses policy and access control machinery 
rather than data-oriented security. I’d really like to revisit this 
and seriously consider a different design that secures the report blocks 
using encryption, and avoids signed Request messages (which have all the 
problematic aspects of signed Interests). An alternative design would:
	* Sign and encrypt individual report blocks using keys owned by the 
individual forwarders
	* Prepend each report block with the CCNx Name of the forwarder that 
generated it, or even better name each report block explicitly.
	* Use the same methods to fetch the signing and encryption keys as is 
used for regular content
	* Employ schematized trust to represent the policy.

***Terminology***
There’s some inconsistent use of terminology that ought to get cleaned 
up.
	* Sometimes the draft talks about “routers” and sometimes about 
“forwarders” In almost all cases I suspect “forwarder” is the 
right term to use.
	* both ccnxsemantics and ccnxmessages take care to clearly separate the 
*packet* from the *message*. These are muddled together here and while 
there are double lines in the figures delineating the boundary, the 
draft needs to be a lot clearer about which TLVs apply at the packet 
level (and hence in hop-by-hop headers) and those in the Request/Reply 
messages and hence in the message part of the whole packet. Describing 
the operation in those terms would also make for a more understandable 
specification.
	* some fields like HopLimit and ReturnCode are defined in ccnxmessages. 
The draft gives the impression you are redefining them here - be clear 
that these are handled identically for all ccnx packets and CCNinfo 
packets/messages are not special in this way.

***Identifying Forwarders/Routers***
I think it’s a mistake to define node identifiers as a separate 
protocol element that needs assignment via a non-ICN namespace. These 
should be handled as CCNx names, specifically:
	* a Name for the forwarder itself whose prefix is:
	* a Name prefix for each of the management data objects that can be 
returned in a CCInfo report block.


***Registries***
The draft contains registry assignments that are associated with 
ccnxmessages and not the current draft. This needs adjustment to:
	* Refer to the corresponding registry in ccnxmessages rather than 
repeating them here
	* Suggest values for the new assignments, but do so via an IANA actions 
section - again mirroring how thing are laid out in ccnxmessages.


**Detailed comments**

I didn’t do a really comprehensive proof reading, but here are some 
things I noted:

Page8:
	* s/forwards back to the node/forwards back toward the node/

Page 18:
	* Object size seems too small to cover the entire size of a cache, 
which could easily be terabytes in size if the forwarder supports a 
backing store. I suggest scaling this number in KB or MB since smaller 
granularity seems of limited utility. It’s also unclear if this is 
just unexpired objects or all objects. Further, it also seems unclear if 
this is a count of everything under the prefix supplied by the user or 
everything (the two are the same if the user asks for “/“)
	* It’s not clear if these numbers, especially the counters, are 
supposed to survive reboots. If not, you need to report uptime, or 
better absolute time of last reboot to be able to post-process data in a 
management application.
	* Some of the numbers, like total received interests, can be 
difficult/expensive to provide in a distributed forwarder design, or one 
that just shards the PIT and CS. It’s probably worth pointing this out 
somewhere.

Page 22:
	* I’m kind of at a loss to figure out how a forwarder in general 
knows whether it’s a “first hop” forwarder and why this matters. 
Some more explanation might help.

DaveO