RESTCONF Extensions to Support the Network Management Datastore Architecture
draft-ietf-netconf-nmda-restconf-05

Thanks to everyone who worked on this mechanism. 

I agree with Alexey's general point that implementors could benefit from
guidance regarding the "with-defaults" values, as the current mechanism
requires a potentially cumbersome process of probing for support of
desired functionality.

Beyond that, I have only a handful of minor comments.

---------------------------------------------------------------------------

§3.1:

>  The <datastore> path component is encoded as an "identity" according
>  to the JSON encoding rules for identities, defined in Section 4 of
>  [RFC7951].

I don't find anything in section 4 of RFC 7951 that indicates encoding for an
"identity." Should this text say "identityref" instead? And if that's the
intention, it seems that pointing to section 6.8 would be more direct than
pointing to section 4.

---------------------------------------------------------------------------

§5:

>  This documents extends the RESTCONF protocol by introducing new
>  datastore resources.  The lowest RESTCONF layer is HTTPS, and the
>  mandatory-to-implement secure transport is TLS [RFC5246].

Unless this mechanism relies on some behavior that is different between TLS 1.2
and TLS 1.3, please update this reference to RFC 8446.

Nit: "This document extends..."
                   ^

>  The security constraints for the base RESTCONF protocol (see
>  Section 12 of [RFC8040] apply to the new RESTCONF datastore resources
>  defined in this document.

Nit: Missing a closing parenthesis.

In Section 3.2.1:

   Servers are not required to support all values in the "with-defaults"
   query parameter on the operational state datastore.  If a request is
   made using a value that is not supported, then the error handling
   behavior is as described in ([RFC8040], Section 4.8.9).

This seems to be pointless, considering that the server already advertises support for the "with-defaults" capability. Can you maybe elaborate on which values are hard to implement (and thus likely not to be implemented)?

Please apply the changes resulting from the Gen-ART review: either removing or clarifying the text about 'ds-ephemeral', adding clarifying text about GET, and adding the missing ')' in Section 5.

The RFC 8040 security considerations are probably adequate for the new datastores.

I noticed the same issue with "identity" that Adam did, though my tentative conclusion
was that these are the more generic "identifier".