Hi Alissa, On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper <[email protected]> wrote:
> 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. > Data coming from a router can come from many different line-cards and processors. The line-cards that may be providing the data are not going to be supporting the secure transports anyway. A goal is to allow easy distribution of streaming data and event notifications. As for what type of data, as far as I know, currently IPFIX streams telemetry data without integrity much less authorization protection. There are existing deployments that use gRPC now for streaming telemetry data. Regards, Alia > ---------------------------------------------------------------------- > 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? > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
