Skip to main content

RESTCONF Extensions to Support the Network Management Datastore Architecture
RFC 8527

Yes

(Ignas Bagdonas)

No Objection

Alvaro Retana
Warren Kumari
(Ben Campbell)
(Deborah Brungard)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

Warren Kumari No Objection

(Ignas Bagdonas; former steering group member) Yes

Yes (for -04)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2018-09-24 for -04)
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.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2018-09-24 for -04)
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)?

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-09-26 for -04)
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.

(Ben Campbell; former steering group member) No Objection

No Objection (for -04)

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2018-09-25 for -04)
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".

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -04)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -04)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -04)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -04)