Subject: [Netconf] Alissa Cooper's No Objection on draft-ietf-netconf-restconf-17: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 12 Oct 2016 06:16:39 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-netconf-restconf-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this.

(1)
I'm curious how the WG settled on using Server-Sent Events. My
understanding is that the SSE framework is somewhat brittle when used on
its own and there can be problems when there are intermediaries in the
path. Did the WG consider other options (e.g., H2 server push or long
polling)?

(2)
I know the jukebox module is just an example, but it actually made me
wonder if there would ever be cause for the server to return a 451 status
code in response to a POST or GET request rather than a 401 or 403.
Obviously there is no analog in the netconf status codes and the use for
this would be pretty atypical, but figured I would mention this thought
since it occurred to me.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Oct 2016 09:59:03 -0700

> https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/

The new notification subscriptions work in NETCONF WG will address some
issues with SSE.
We were trying not to reinvent notification delivery and this seemed to be
the
most deployed standard approach when the decision was made. H2 server push
will be supported in the new work.

> this would be pretty atypical, but figured I would mention this thought

The table in sec. 7 for error-tag 'access-denied' lists status codes 401
and 403.
The way to block access in RESTCONF is to configure NACM rules.
(Other methods would not be visible to the RESTCONF server.)
In this case a 403 error is returned.  NACM does not record why a rule
is configured (e.g., legal vs. operational).

Andy

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 13 Oct 2016 08:41:00 -0400

Thanks for the explanations.
Alissa

> On Oct 12, 2016, at 12:59 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Wed, Oct 12, 2016 at 6:16 AM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ <https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/>
> 
> 
> 
> The new notification subscriptions work in NETCONF WG will address some issues with SSE.
> We were trying not to reinvent notification delivery and this seemed to be the
> The table in sec. 7 for error-tag 'access-denied' lists status codes 401 and 403.