Hi Russ,
Thanks for the review, please see inline ...
On 28/06/2018 20:47, Russ Housley wrote:
Reviewer: Russ Housley
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-netconf-nmda-restconf-04
Reviewer: Russ Housley
Review Date: 2018-06-28
IETF LC End Date: 2018-07-09
IESG Telechat date: unknown
Summary: Ready
Major Concerns:
None.
Minor Concerns:
The last paragraph of Section 3.1 says:
If a server implements the example datastore "ds-ephemeral" in the
module "example-ds-ephemeral", it would implement the resource
{+restconf}/ds/example-ds-ephemeral:ds-ephemeral.
It is unclear to me why this datastore is not included in the bullets
at the beginning of the section. Obviously, it is optional to
implement, but so are two of the datastores that are included in
the list.
So the difference is that:
"operational", "running" and "intended" are all defined by RFC 8342,
and we expect these datastores to be actually implemented.
"ds-ephermeral" is just an example of a new configuration datastore that
hasn't yet been defined anywhere yet. It could for example, be defined
by something like I2RS in future to handle dynamic configuration, or
perhaps a vendor would define their own dynamic datastore.
The last bullet of Section 3.2 says that [RFC8040], Section 3.5.4,
paragraph 3 does not apply when interacting with any resource under
{+restconf}/ds. The referenced paragraph says:
If the target of a GET method is a data node that represents a leaf
or leaf-list that has a default value and the leaf or leaf-list has
not been instantiated yet, the server MUST return the default value
or values that are in use by the server. In this case, the server
MUST ignore its "basic-mode", described in Section 4.8.9, and return
the default value.
I suspect that this paragraph does not apply because the leaf and
leaf-list will always be instantiated. A sentence to say one way or
the other would be useful to the implementer.
The aim here is to remove the above CLR that is in RFC 8040.
I.e. for NMDA datastores (including <running>), don't treat the GET
method for leaf/leaf-list any differently than the GET method on any
other data node, and respect both the clients request of whether default
values should be returned, and also the servers properties (as to
whether it always returns defaults).
As you say, this particularly helps for the operational state datastore,
which handle default values in a different way. But it also helps with
the configuration datastores, since it allows a client to easily
determine whether a particular leaf has actually been configured just by
querying for it. With the rule as stated in RFC 8040 you cannot so
easily find out, because you would have to make the query on the parent
data node instead, and check whether the child data node in question has
been included in the response.
Finally, we felt that it is easier to fix this in NMDA in a backwards
compatible way that only applies to the new datastore specific paths,
rather than making a breaking change to the behavior of the /data path
described in RFC 8040 that could cause inconsistencies between existing
implementations.
Nits:
There is a missing ')' in the last paragraph of Section 5.
Thanks, I'll fix this.
Thanks,
Rob
_______________________________________________
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
