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

From: [email-masked]
Date: Fri, 19 Oct 2018 14:27:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Dynamic subscription to YANG Events and Datastores over RESTCONF
        Authors         : Eric Voit
                          Reshad Rahman
                          Einar Nilsen-Nygaard
                          Alexander Clemm
                          Andy Bierman
	Filename        : draft-ietf-netconf-restconf-notif-09.txt
	Pages           : 25
	Date            : 2018-10-19

Abstract:
   This document provides a RESTCONF binding to the dynamic subscription
   capability of both subscribed notifications and YANG-Push.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-09
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-notif-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-notif-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sat, 20 Oct 2018 20:00:10 +0000

Hi,

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

Regards,
Reshad.

On 2018-10-19, 5:27 PM, "Netconf on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

    
    _______________________________________________
    Netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Oct 2018 18:29:33 +0000

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.

>       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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Oct 2018 22:38:49 +0100 (CET)

Hi,

> I resist the idea that node names need to be consistent across modules.

I agree.  In this case I would have used the existing name, instead of
inventing a new name.

Not important though.

>   - an authorized administrator can modify/kill any client's subscription.

I agree that tying it to the username (RESTCONF or NETCONF or others)
makes sense.  But note that this can be done with NACM rules.  It
doesn't have to be built into the spec.  The details should go into the
SN draft.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 29 Oct 2018 22:00:31 +0000

Hi Kent,

On 2018-10-29, 2:29 PM, "Kent Watsen" <[email-masked]> wrote:

    Hi Reshad,

    
    
    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. 

    
    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.    

<RR> The "uri" does not change, that's why the [non-]modified question came up. I'm keeping it.

Regards,
Reshad.    
    
    Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 30 Oct 2018 11:30:23 +0000

> -----Original Message-----
> From: Netconf <[email-masked]> On Behalf Of Reshad Rahman
> (rrahman)
> Sent: Monday, October 29, 2018 6:01 PM
> To: Kent Watsen <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-notif-09.txt
> 
> Hi Kent,
> 
> 
> <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.
> 

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 30 Oct 2018 21:13:38 +0000

Kent/Martin, for 2) do you want additional text in the -notif drafts or is the SN text below enough?

Regards,
Reshad.

On 2018-10-30, 7:30 AM, "Eric Voit (evoit)" <[email-masked]> wrote:

    

    and Section 2.4.4:

    
    Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Oct 2018 11:42:04 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> "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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 31 Oct 2018 11:13:56 +0000

> thing we can use is the user name.

Agreed, and I wonder if we shouldn't apply the same treatment to
netconf-notif, which currently says:

   For a dynamic subscription, any "modify-subscription", "delete-
   subscription", or "resynch-subscription" RPCs MUST be sent using the
   same NETCONF session upon which the referenced subscription was
   established.

   [BTW, there's a typo, in both the notif drafts, the RPC is 
    called "resync-subscription" in the yang-push draft]

Admittedly, NETCONF has sessions, but maybe being consistent would
be good.

And note that this bleeds into subscribed-notifications as well.  
For instance:

   In Section 2.4.3:
   .................Dynamic subscriptions can only be modified via
   this RPC using a transport session connecting to the subscriber.

   In Section 2.4.4:
   .........................................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.

   In Section 2.4.5: (maybe just s/transport session/client/?)
   The "kill-subscription" operation permits an operator to end a
   dynamic subscription which is not associated with the transport
   session used for the RPC.

And in YANG-push, in the description statement for the RPC:

       This RPC can only be invoked on the same session on which the
       subscription is currently active.  In case of an error, a
       resync-subscription-error is sent as part of an error
       response.";

There may be other instances as well.

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 31 Oct 2018 13:21:21 +0000

> From: Martin Bjorklund, October 31, 2018 6:42 AM
> 
> Hi,
> 
> 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:
> 

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

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 31 Oct 2018 14:00:04 +0000

> From: Kent Watsen, October 31, 2018 7:14 AM

> Agreed, and I wonder if we shouldn't apply the same treatment to netconf-
> notif, which currently says:
> 

If it makes implementation easier, we could convert this to:

"For a dynamic subscription, any "modify-subscription", "delete-subscription", or "resynch-subscription" RPCs MUST be sent either using the same NETCONF session upon which the referenced subscription was established, or a different NETCONF session which uses identical security credentials as the referenced subscription."

I am good either way.
 
>     called "resync-subscription" in the yang-push draft]

Updated

> Admittedly, NETCONF has sessions, but maybe being consistent would be
> good.
>

I think 'subscriber' is sufficient here.  I could make it 'subscriber identity or security credentials' like in my last response to Martin, but that seems more confusing to me at this point in the document.
 
>    with no changes to the publisher.

This is the text which is removed in -v19 as per the descriptions earlier in this thread.

>        resync-subscription-error is sent as part of an error

Alex  can you tweak this text to:

This RPC can only be invoked on the same session, or a session using the same security credentials as the targeted subscription.  In case of an error, a resync-subscription-error is sent as part of an error response.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Oct 2018 15:31:40 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > > > <RR> I'll keep "uri" unless we hear from more people who would like to
> > > > see
> > it
> > > >       - 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.
> > separate
> 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;

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

and RESTCONF should say that it MUST be the same RESTCONF user name.

/martin

> > "modify-
> > > " Dynamic subscriptions can only be deleted via this RPC using a
> > > transport
> > > >     > 3- Take uri out of subscription-modified. It was pointed out to me
> > > >     > that
> > > >     > SN draft says the following:
> > > >     >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 31 Oct 2018 15:07:44 +0000

> From: Martin Bjorklund, October 31, 2018 10:32 AM
> 
> > > > > <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.
> > > > >
> > > > > https://mailarchive.ietf.org/arch/msg/netconf/3WaiWBVlLhj9wBOtuF
> > > > > uxVJ
> > > > > kfsig
> > > > >
> > > > >     RESTCONF doesn't have connections, per se, but sometimes
> > > > > drafts refer
> > > to
> > > 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?
> > >
> 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.
 
> 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

> > > subscription", like it does for "delete-subscription".  So maybe
> > > change the "description" of the leaf "id" to:
> > >