IETF conflict review for draft-irtf-icnrg-terminology
conflict-review-irtf-icnrg-terminology-00

The following approval message was sent
From: The IESG
To: Internet Research Steering Group ,
    icnrg-chairs@ietf.org,
    Colin Perkins ,
    irtf-chair@irtf.org,
    =?utf-8?q?B=C3=B6rje_Ohlman?= ,
    draft-irtf-icnrg-terminology@ietf.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-irtf-icnrg-terminology-07

The IESG has completed a review of draft-irtf-icnrg-terminology-07 consistent
with RFC5742.

The IESG has no problem with the publication of 'Information-Centric
Networking (ICN): CCNx and NDN Terminology'
as an Informational RFC.

The IESG has concluded that there is no conflict between this document and
IETF work.

The IESG would also like the IRTF to review the comments in the datatracker
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot and
the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-irtf-icnrg-terminology/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-irtf-icnrg-terminology/

The process for such documents is described in RFC 5743

Thank you,

The IESG Secretary

[Ballot comment]
This is the right conflict-review response.

Comments on the document itself:

Section 2

  *Trust*:

      Data authenticity is distinct from data trustworthiness, though
      the two concepts are related.  A packet is authentic if it has a
      valid name-to-content binding.  A packet is trustworthy, i.e., it
      comes from a reputable or trusted origin, if this binding is valid
      in the context of a trust model.  Section 6 discusses this
      further.

I think I see what is intended here, but distinguishing between "valid" and
"valid in the context of a trust model" is a pretty subtle differentiation.
Some more discussion about a given named entity being expected to produce
certain content might help (but then again, might not).

  *Forwarding Plane*:

      The canonical way of implementing packet forwarding in an ICN
      network relies on three data structures that capture a node's
      state: a Forwarding Interest Table (FIB), a Pending Interest
      Table (PIT), and a Content Store (CS).  It also utilizes Interest
      forwarding strategies which takes input from both FIB and
      measurements to make Interest forwarding decisions.  When a node

nit: "take input" to match "strategies" plural.

Section 3.1

  *Data packet Immutability*:

      After a data packet is created, the cryptographic hash binding the
      name to the content ensures that if either the content or the name
      changes, that change will be detected and the packet discarded.

nit: previous discussion referred to the name-to-content binding as a
"signature", not as a "hash".

Section 3.5

  *Nonce*:

      A field of an Interest packet that transiently names an Interest
      instance (instance of Interest for a given name).  Note: the use
      "nonce" as defined here for NDN does not imply semantics that
      satisfy all the properties of a cryptographic nonce as defined in,
      e.g.  [RFC4949].

RFC 4949 does not have a definition for "cryptographic nonce", so I assume
just the regular definition for "nonce" is the intended reference.  The only
required attribute there is "random or non-repeating", with liveness
guarantee and replay protection being only the "usual usage" (i.e., not required).  While I
assume I don't fully understand the nuance of ICNRG nonce usage, my
understanding is that they are intended to be non-repeating, at least within
some time window, and serve to tie specific expressions of interest to data
responses.  That is not exactly the "replay protection" of RFC 4949, though
it is closely related, and I would argue that even the "non-repeating within
a time window" property suffices to keep the ICN usage within the RFC 4949
definition.

Which is a long way of saying that I don't think this much disclaimer is
needed.

Section 6

  While the terms defined in this specification do not in and of
  themselves present new security considerations, the architectures
  which utilize the terms most certainly do.  Readers should look at
  those specifications (e.g.  [RFC8569], [NDN]) where various security
  considerations are addressed in detail.

This is a great formulation; thank you!