Subject: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 08 Jul 2021 14:45:18 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-nmda-diff-09: No Objection

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/

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

Thanks to Alexey Melnikov for the secdir review.

I'm not experienced enough with YANG to know whether or how problematic
it is that the "anydata subtree-filter" node contents are described by
reference to the NETCONF specification, which has a particular (XML)
representation of YANG data and does not give a clear presentation of
the abstract YANG structure/semantics to be used.  Is it possible to use
the filter-spec choice option when, for example, RESTCONF is used with
JSON encoding?

Section 4

   o  report-origin: When set, this parameter indicates that origin
      metadata should be included as part of RPC output.  When this
      parameter is omitted, origin metadata in comparisons that involve
      <operational> is by default omitted.

Why is it important to complicate the semantics of this parameter with a
dependence on the datastore?  It seems like it would be simpler to get
this effect by having clients specify report-origin when the target is
not <operational>.  Note that changing the semantics would require text
changes in subsequent parts of the document for consistency.  (If
retaining the current semantics, please clarify whether "comparisons
that involve <operational>" applies when operational is source, target,
or either.)

Section 9

In addition to noting that the "compare" RPC is sensitive and should be
restricted to authorized parties, I suggest to reiterate that the
"compare" operation should not provide a mechanism to work around access
control on other nodes -- that is, a result should only be returned if
the requestor would be allowed to access both the "source" and "target"
trees independently of the RPC.  In particular, even a "no-matches"
output should not be returned, as that might provide a way to determine
the structure of the datastore even without accessing it.

We might also incorporate by reference the security considerations for
subtree filtering (RFC 6241) and xpath filtering (RFC 6991).

NITS

Section 1

   an unusually long time to do so.  This can be the case due to certain
   conditions not being met, certain parts of the configuration not
   propagating because considered inactive, resource dependencies not
   being resolved, or even implementation errors in corner conditions.

"because considered inactive" seems like an incomplete clause; maybe
"because they are considered inactive"?

Section 4

   o  differences: This parameter contains the list of differences.
      Those differences are encoded per YANG-Patch data model defined in

s/YANG-Patch/the YANG-Patch/
I'd also consider s/per/according to/, since this is not exactly a
logic-driven deduction but rather more of a new requirement.

Section 6

   for the management of interfaces defined in [RFC8343].  The excerpt
   of the data model whose instantiation is the basis of the comparison
   is as follows:

I feel like this phrasing is a little misleading, as not only is the
following snippet only a subset of the nodes contained within "container
interfaces" but the descriptions have been greatly abbreviated as well.
Perhaps we could say something about "for the purposes of understanding
the subsequent example, the following subset of the [RFC8343] data model
is provided".

   Accept: application/yang-d

(I believe this truncated header field was already noted by another
reviewer.)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Jul 2021 15:42:30 -0700

> https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/

There is not a standard specification for subtree filtering using JSON
encoding
instead of XML. RESTCONF has its own somewhat compatible filtering
mechanism.
It would require a new NETCONF work item to officially expand subtree
filtering
to support JSON.  (Unofficially, there is RFC for JSON encoding of YANG
data and an
implementation could map the RFC 6241 text to JSON).

> that involve <operational>" applies when operational is source, target,
IMO NMDA is way too complicated, so I cannot argue with that complaint.
The origin attribute only applies to the <operational> datastore.
I think it is not allowed to appear elsewhere.

Section 9
> the structure of the datastore even without accessing it.

Fortunately the access control model (NACM) is per server and not per
datastore
so the same access rules apply to all datastores. I agree the no-access
subtrees
should be silently skipped, the same way that GET operations are treated in
NACM.

> (I believe this truncated header field was already noted by another

Andy

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Jul 2021 11:27:48 -0700

Hi Andy,

> implementation could map the RFC 6241 text to JSON).

Okay, this sounds a little familiar now that you mention it.

Should we mention in a comment of some form that this filtering mechanism
is currently only usable with the XML encoding?

> I think it is not allowed to appear elsewhere.

Ah, I see what you are saying now (on second read): the "origin" being
reported is the origin attribute of the data in the datastore being
compared, but only the <operational> datastore will every have that
attribute available.  The text here would be a lot more clear if it
reminded the reader that the origin attribute has such a limited scope,
perhaps:

o report-origin: data in the <operational> datastore has an associated
  "origin" attribute that indicates the origin of the reported value.  When
  set, this parameter indicates that the origin metadata should be included
  as part of the RPC output.  It has no effect when the target datastore is
  anything other than <operational>.  When this parameter is omitted, the
  origin metadata is omitted from the RPC output.

> should be silently skipped, the same way that GET operations are treated in

Ah, okay.  (I think Roman may have mentioned a similar concern about
no-access subtrees, too.)

Thanks,

Ben