[netconf] Roman Danyliw's Discuss on draft-ietf-netconf-notification-capabilities-18: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-notification-capabilities-18: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/



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

The text contains contradictions on how to handle implementation-time use case
that might use the YANG file format.

(a) Section 2. “The file MUST be available already at implementation time,
retrievable in a way that does not depend on a live network node.  E.g.,
download from product website.”

(b) Section 2. “The YANG modules specified in this document define a schema for
data that is designed to be accessed via network management protocols such as
NETCONF [RFC6241] or RESTCONF [RFC8040].  … The Network Configuration Access
Control Model (NACM) [RFC8341] provides the means to restrict access for
particular NETCONF or RESTCONF users”

(c) Section 2.  “When that data is in file format, data should be protected
against modification or unauthorized access using normal file handling
mechanisms.”

(a) – (c) cannot all be satisfied at the same time.  (b) seems to only apply to
the run-time use cases.  (a) and (b) seem to apply to the implementation time
use cases.  Please make this clearer.

Per (c), it might be clearer to keep this text, but also noting that using the
YANG file format inherits all of the security considerations of
draft-ietf-netmod-yang-instance-file-format which has additional considerations
about read protections; and distinguishes between data at rest and in motion.


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

Thank you to Barry Lieba for the SECDIR review.

** Section 6.  I’m surprised by the statement that “The data in these modules
is not security sensitive” given that the specific YANG module that might be
annotated is unknown.  Would it be possible for an attacker to glean any
topology information by reviewing the notification properties of module?  Could
they poll this interface to inform real-time targeting since Section 1 notes
that “capabilities might change during run-time”?