Alissa Cooper has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

== Section 3.2 ==

"A non-secure transport can be can be used for publishing telemetry
   data or other operational state that was specifically indicated to
   non-confidential in the data model in the Yang syntax."

What kind of telemetry data is it that is of no potential interest to any
eavesdropper? This is not my area of expertise so I'm having a hard time
conceiving of what that could be. I'm also wondering, since I2RS agents
and clients will have to support secure transports anyway (and RESTCONF
can only be used over a secure transport), why can't they be used for all
transfers, instead of allowing this loophole in the name of telemetry,
which undoubtedly will end up being used or exploited for other data
transfers?

If the argument was that this loophole is needed for backwards
compatibility with insecure deployments of NETCONF or something like that
I think it would make more sense, but my impression from the text is that
those will have to be updated anyway to conform to the requirements in
this document.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In general I agree with Mirja that where other documents already provide
definitions, they should be referenced, not copied or summarized, in this
document. 

== Section 2.1 ==

Using "privacy" as a synonym for "confidentiality" is outmoded, I think,
given current understanding of the many other facets of privacy (see,
e.g., RFC 6793). I would suggest dropping the definition of data privacy
and just using the word confidentiality when that is what you mean.

== Section 2.2 ==

"The I2RS protocol exists as a higher-level protocol which may
      combine other protocols (NETCONF, RESTCONF, IPFIX and others)
      within a specific I2RS client-agent relationship with a specific
      trust for ephemeral configurations, event, tracing, actions, and
      data flow interactions."

Reading the provided definition of "trust," I'm not sure what "with a
specific trust for" means in the sentence above.

"The I2RS architecture document [I-D.ietf-i2rs-architecture]
      defines a secondary identity as the entity of some non-I2RS entity
      (e.g. application) which has requested a particular I2RS client
      perform an operation."
    
Per my comment above, I would suggest just referencing the definition
from the architecture document. The text above is circular ("the entity
of some ... entity") and conflates an identity with an identifier.

== Section 3.1 ==

Agree with Mirja that this section is superfluous.

== Section 3.3 ==

Since the normative recommendation here isn't to be enforced by the
protocol, why is it SHOULD rather than MUST? Same question applies to
SEC-REQ-17.

== Section 3.5 ==

Is the omission of normative language from Sec-REQ-20 purposeful?