> On Jun 29, 2018, at 7:01 AM, Robert Wilton <[email protected]> wrote:
>
> 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.
Perhaps something like this:
If a server implements other datastores, such as the example
datastore "ds-ephemeral" in the module "example-ds-ephemeral",
the server would implement the resource {+restconf}/ds/example-
ds-ephemeral:ds-ephemeral.
>
>
>>
>> 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).
Saying the above in the would help me.
> 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.
Backwards compatibility is a good thing.
Russ
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
