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

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

> From: Martin Bjorklund, October 31, 2018 10:32 AM
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > > 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/3WaiWBVlLhj9wBOtuF
> > > > > uxVJ
> > > > > 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.
> 
> Do you want this to be transport-specific?  If so, the SN draft should say that,
> and specific text should go into the transport drafts;

I believe SN should specify the minimum expectation across all transports.  The current SN draft attempts this.
 
> NETCONF should say that it MUST be the same NETCONF session (which of
> course is more restrictive than saying same user name, and also more
> restrictive than same transport session (since you can have multiple NETCONF
> sessions on the same SSH session)).

My preference is the 'MUST' for the same NETCONF session too.  In my last thread response to Kent, I asked if implementers thought it easier to implement with the less restrictive case.  As far as I know, nobody is desiring this less restrictive case.  So the current text should work.
 
> and RESTCONF should say that it MUST be the same RESTCONF user name.

That works for me.

Eric

> 
> /martin
> 
> > > 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