Subject: [Netconf] Shepherd review of draft-ietf-netconf-nmda-restconf

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 11 Mar 2018 22:45:23 -0700

I have reviewed -03 version of draft-ietf-netconf-nmda-restconf. 

The document is well written, and is easy to read, but has issues which should be addressed before the document is sent to IESG.

Nits.

Abstract:

s/REF Editor/RFC Editor/

1.0 Introduction:

The first comma in this sentence seems to be misplaced. 

“supported in each datastore and, finally,” ??

2. Datastore and YANG Library Requirements

Can we consolidate the RFC Editor instructions in one place, instead of splitting them between here and Abstract.

Detailed comments:

Introduction:

The document states:

"This document updates [RFC8040 <https://tools.ietf.org/html/rfc8040>] in order to enable RESTCONF clients to discover which datastores are supported by the RESTCONF server, as well as determine which modules are supported in each datastore and, finally, to interact with all the datastores supported by the NMDA. Specifically, the update introduces new datastore resources, adds a new query parameter, and requires the usage of [I-D.ietf-netconf-rfc7895bis <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-03.html#ref-I-D.ietf-netconf-rfc7895bis>] by RESTCONF servers implementing the NMDA."

Questions:

1) How does this draft enable RESTCONF clients to discover which datastores are supported? 

Is it the definition of the new datastores resource? If so, can that be made explicit, by saying something like this in Section 3.1

OLD:
This document defines a set of new resources representing datastores
as defined in [I-D.ietf-netmod-revised-datastores <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-03.html#ref-I-D.ietf-netmod-revised-datastores>].

NEW:
This document defines a set of new resources representing datastores
as defined in [I-D.ietf-netmod-revised-datastores <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-03.html#ref-I-D.ietf-netmod-revised-datastores>]. This resource 
can be used to discover the datastores that are supported by the server.

On the question of discovery of datastores itself, would the clients use the HEAD or GET methods to query what datastores are supported? If so, an example would be nice. Specifically, something that explains what response and errors to expect if the datastore is supported, and what response and errors to expect if the queried datastore is not supported. 

2) How does the draft help determine which modules are supported by each datastore?

I went looking for text in the draft that talks about module discovery under each datastore, but did not find any. Am I missing something?

3) The part of the sentence “to interact with all the datastores supported by the NMDA” seems incomplete.

What interaction are we referring to? Is it the protocol operations on the datastore? Is it the query parameters on the datastores?

Section 3.2.1

What happens if the capability is not announced, but a “with-defaults” query is issued? 

Finally, what are the implications of explicit discovery of datastores supported by a RESTCONF server? For example, if the above “with-defaults” query is issued with the “content” query parameter set to “nonconfig", default values from which datastore are returned?

Also, if the query parameter “content” is not present, RFC 8040 says that the default value is “all”. Does “all” include operational datastore data nodes, with or without the new capability? In other words, do we need to redefine “all”?

Thanks.

Mahesh Jethanandani
[email-masked]