Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-notif-09.txt

[Kent Watsen <[e-mail]>]

Hi Reshad,

> Most of the comments received during WGLC (from Kent, Martin and
> Qin) have been addressed. Those not addressed are:
>
> 1- s/uri/location/ (to use same term as in RFC8040), I'm fine with
>   this change but would like to hear from WG.


I resist the idea that node names need to be consistent across modules.
Yes, there exists some meta-conventions (e.g., the "enabled" leaf) that
are unfortunately with us at the moment.

Modules should firstly use whatever name makes most sense for their
own purpose.  If it doesn't matter, then picking a value consistent
with another module is okay, but I wouldn't spend more than five 
minutes searching for it.

FWIW, the zerotouch draft has an inet:uri node called "download-uri".
I don't know if it's a better name within the ZTP context, but it 
made sense to me at the time and no one questioned it.



> 2- Allowing modify/delete subscription from a different connection. There
>  was a discussion between Martin and Eric on this topic:
> https://mailarchive.ietf.org/arch/msg/netconf/3WaiWBVlLhj9wBOtuFuxVJkfsig

RESTCONF doesn't have connections, per se, but sometimes drafts refer to
the underlying TLS connection.

Regardless, the general goals (for NETCONF too, I would think) could be:
  - a client (i.e., a RESTCONF username) can always modify/delete/resynch
    their own subscriptions.
  - an authorized administrator can modify/kill any client's subscription.


> 3- Take uri out of subscription-modified. It was pointed out to me that
> SN draft says the following:
>
>       For completeness, this subscription state change notification
>       includes both modified and non-modified aspects of a subscription.

I'm unsure how the [non-]modified matters to this question, but it seems
that "uri" may not be *needed* as there is already an "id" node that
achieves the similar ability to identify the subscription.  That said,
I'm okay with the "uri" field being present, even if it's only mildly
helpful, so long as there is no concern for the message size or the 
publisher's ability to populate the value.


Kent // contributor