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

[Martin Bjorklund <[e-mail]>]

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/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."

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.

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."

(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