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

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, October 31, 2018 6:42 AM
> 
> Hi,
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Netconf <[e-mail]> On Behalf Of Reshad Rahman
> > > (rrahman)
> > > Sent: Monday, October 29, 2018 6:01 PM
> > > To: Kent Watsen <[e-mail]>; [e-mail]
> > > Subject: Re: [Netconf] I-D Action:
> > > draft-ietf-netconf-restconf-notif-09.txt
> > >
> > > Hi Kent,
> > >
> > >
> > > On 2018-10-29, 2:29 PM, "Kent Watsen" <[e-mail]> 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/3WaiWBVlLhj9wBOtuFuxVJ
> > > kfsig
> > >
> > >     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."
> 
> I don't understand what this means.  Or maybe I don't understand how
> it is supposed to be implemented.   I think the text says that
> modify-subscription only can be done by the same client that sent the
> establish-subscription.  But what is "the same client"?  If I have two separate
> management systems, that connect with the same user name to a device, is
> that the same client?
> 
> Since we don't have a "client id" in our protocols, the best/only thing we can
> use is the user name.

Agree.  That was how this should be embodied for RESTCONF.  For NETCONF, as the modify and delete RPCs can only be passed over the same NETCONF session as the establish (see Section 5 of NETCONF-Notif), an implementation will already enforce this without extra effort.
 
> Also, I think the details should go into the YANG definition of "modify-
> subscription", like it does for "delete-subscription".  So maybe change the
> "description" of the leaf "id" to:
> 
>        "Identifier of the subscription that is to be modified.
> 
>         Only subscriptions that were created using
>         'establish-subscription' with the user name as this RPC
>         can be modified with this RPC."

'User name' has its own issues.  How about 'subscriber identity or security credentials'?

Eric

> (and modify the description for "delete-subscription" in a similar
> way)
> 
> 
> 
> /martin
> 
> 
> 
> 
> 
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf