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

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!