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

> -----Original Message-----
> From: Netconf <netconf-bounces@ietf.org> On Behalf Of Reshad Rahman
> (rrahman)
> Sent: Monday, October 29, 2018 6:01 PM
> To: Kent Watsen <kwatsen@juniper.net>; netconf@ietf.org
> Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-notif-09.txt
> 
> Hi Kent,
> 
> 
> On 2018-10-29, 2:29 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:
> 
>     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.
> <RR> I'll keep "uri" unless we hear from more people who would like to see it
> changed to location.   I don't feel strongly about this, I got used to "uri" and
> think it's appropriate.
> 
>     > 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.
> <RR> We should have this discussion in the context of SN.

This is covered in SN.  Section 2.4.3:

"Dynamic subscriptions can only be modified via this RPC using a transport session connecting to the subscriber."

and Section 2.4.4:

" Dynamic subscriptions can only be deleted via this RPC using a transport session connecting to the subscriber."

In  -v19, I have also removed the sentence: " If the delete request
   matches a known subscription established on the same transport
   session, then it MUST be deleted; otherwise it MUST be rejected with
   no changes to the publisher."

Eric

>     > 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.
> <RR> The "uri" does not change, that's why the [non-]modified question came
> up. I'm keeping it.
> 
> Regards,
> Reshad.
> 
>     Kent // contributor
> 
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf