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

[Andy Bierman <[e-mail]>]

On Wed, Oct 6, 2021 at 7:47 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> 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.”
>
>

I have never seen text like the above paragraph in an RFC for a YANG module
before.
IMO it sets a bad precedent and should be removed.  The info reported in
this YANG module
is not critical to the operation of YANG Push.  I am curious why this
requirement is here at all,
let alone a MUST requirement.

Every other YANG monitoring module is expected to be retrievable from a
server
that advertises conformance to that module, without any requirements placed
on the vendor's WEB site contents (as if that is interoperable anyways).
I do not see any reason this YANG module needs additional requirements.


Andy




> (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”?
>
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>