CCNinfo: Discovering Content and Network Information in Content-Centric Networks
draft-irtf-icnrg-ccninfo-15

# Internet AD comments for {draft-irtf-icnrg-ccninfo-12}
CC @ekline

## Comments

### S1.1

* "PIT" acronym/initialism is used without prior expansion? (probably not
  required for CCN-knowledgeable folks but might still be helpful)

### S3.1.1

* Consider whether you want to include a reference to RFC 8877 and describe
  this timestamp format's relationship to any text that appears in there.

### S3.2.1.1

* "total size (KB) of the unexpired content objects"

  In which direction should rounding occur, or are all content objects
  1KB-aligned?

### S5.2

* For list item #1: does the router decrement the hoplimit and then compare
  to zero, or compare to zero first and then decrement before forwarding?

* Also for list item #1: I was confused by the description of FHR behaviour
  for non-zero hoplimit values.  The text implied to me that the FHR drops
  the request unless the hoplimit == 0 exactly, which to me seems like it
  only prolongs the time it takes to run a diagnostic info request (because
  the ccninfo has to walk hoplimits upwards until it gets the exact right
  value rather than setting a suitably large guess and having the FHR
  handle it regardless of hoplimit value).

  But I'm probably just misreading the text or simply confused.

### S5.5

* If a HopLimit is decremented to zero for a reply message, does an error
  get sent back to the replying router or is it silently dropped?

  I assume silently dropped.

## Nits

### S1.1

* "it examines own cache" -> "it examines its own cache", perhaps

### S3.2.1.1

* "value of one (i.e., %xFFFFFFFF)" ->
  "value of all ones (i.e., %xFFFFFFFF)", perhaps

### S5.6

* "To avoid routing loop" -> "To avoid routing loops", I think

(Via drafts-eval@iana.org): IESG/Authors/ISE:

IANA has questions about draft-irtf-icnrg-ccninfo-11.

The IANA Considerations section is unclear, but it seems to indicate that the document can't make registrations because the unnamed registry requires Standards Action (RFC 8126).

However, the registries that the document appears to refer to require only RFC publication ("RFC Required") or a document approved by an expert ("Specification Required"):

https://www.iana.org/assignments/ccnx

For example, "Figure 4: Packet Type Namespace" lists three registrations made in the CCNx Packet Types registry by RFC 8609:

%x00        PT_INTEREST
%x01        PT_CONTENT
%x02        PT_RETURN

It then lists two more entries that aren't listed in the CCNx Packet Types registry yet:

%x03        PT_CCNINFO_REQUEST
%x04        PT_CCNINFO_REPLY

The IANA Considerations section doesn't ask us to register those Packet Types, but it could: the registration procedure is "RFC Required," which requires only that this document be published as an RFC.

This is also true for the unregistered entries in the lists in Figure 5 (CCNx Top-Level Types), Figure 8 (CCNx Hop-by-Hop Types), Figure 11 (CCNx Message Types), and possibly others. Why aren't these being registered by this document? Are these meant to be registered by a different document?

Should there be a new registry for the list in Section 3.1? Also, Figure 16 refers to a "CCNinfo Reply Type Namespace," which doesn't appear to exist yet. Should that be created by this document?

(This may not be an exhaustive list of possible registries and registrations.)

If this document is making registrations, each registry and set of new registrations should be listed in the IANA Considerations section. If the document is creating registries, a registration procedure must also be provided (see RFC 8126).

[Ballot comment]
I think it's ready and in fact will be very useful for not only for it's intended audience but for people trying to understand how CCN works.

[Ballot comment]
This is a very clear document. I'd want more solutions for the privacy risks (clearly described) if it were from a WG but from an RG it's ready for publication IMO.

[Ballot comment]
I gave a quick look at the Security Considerations section that seems of good quality. Given that this tool opens the door to a large set of new security and privacy risks, this is clearly required. I hope the SecDir review will go through all of this more carefully than I did.

CCNInfo is one of a suite of tools for the instrumentation and management of ICN networks. it has gone through significant evolution over a number of years, and is deemed ready by the RG participants and chairs as ready for IRSG review and publication as an experimental RFC.

During Last Call, only a few comments were received. These were focused on:
- correctly positioning the work as one of a set of tools (as opposed to the "one and only blessed tool")
- including material describing the nature of the experiments with ICN that such a tool as CCNInfo can support.

Material addressing these is included in the current draft.

As a note, two additional ICN management tools, Ping and Traceroute, are under active development in ICNRG as will be entering Last Call in the near future.