Subject: [Netconf] WGLC on restconf-notif-08

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Oct 2018 22:10:53 +0000

This message starts a Last Call on draft-ietf-netconf-restconf-notif-08:

  https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-08

This, along with the netconf-notif Last Call, started in a separate 
message, marks the last of the last calls on the yang push suite of
drafts. As explained before, given the size and number of documents,
the chairs decided to break the reviews up into pieces so as to get
focus on each in turn.  We chose to go top-down, starting with 
yang-push and ending with the "notif" drafts.  We plan to submit 
the drafts for publication when they are ready as a collective.  
The goal is to do all this prior to IETF 103.

While it's always nice to receive messages of support, at this time, 
the question isn't so much if the working group supports the work 
than if the document is ready to progress.  The chairs need to see
reviews that indicate thorough end-to-end reading of the text.  Of
course, if there are any objections, these should be brought forward
now as well.

The current version (-13) of this draft was published on Oct 4th 
(today).  The datatracker page for the draft is here:

  https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications.

Thanks,
Kent (and Mahesh)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 13:45:15 +0200 (CEST)

Hi,

I think that this document needs some fixes before it is ready.  Here
are my comments.

o  Title and Abstract

  This document is called:

     RESTCONF Transport for Event Notifications

  but netconf-notif called

     NETCONF Support for Event Notifications

  The titles should probably be aligned.

  ... and note the document that they support is called

     Customized Subscriptions to a Publisher's Event Streams

  It is not obvious that "RESTCONF Transport for Event
  Notifications" relates to "Customized Subscriptions to a Publisher's
  Event Streams".

  Also, the abstracts should probably also be aligned.

o  Section 3.1

  Last sentence:

    A subscriber can then attempt to re-establish.

  Please clarify what this means.  Specifically, the subscriber needs
  to re-send the "establish-subscription" and do a new GET on the new
  URI.  (right?)

o  Section 3.2

   The reference RFC6520 is incorrect, it should be 8040.

o  Section 3.3

  It seems this text starts a itemized list, but it probably
  should not be a list:

   o  In case of error responses to an "establish-subscription" or

o  Section 3.4

  The text says:

   An HTTP GET is then sent on a separate logical connection (b) to the
   URI on the publisher.

  I think that is also ok if the GET is sent on (a) - in the case that
  you don't care about being able to modify the subscription.  This
  should be clarified.

  Also, "modify-subscription" may be sent on some other session.

o  Section 4

   o  take any existing subscription "priority" and copy it into the
      HTTP2 stream priority, and

   What is the 'subscription "priority"'?  Can you add a reference.

   Can you also add a reference to HTTP2 stream priority?

o  Section 4

   o  take any existing subscription "dependency" and map the HTTP2
      stream for the parent subscription into the HTTP2 stream
      dependency.

  (same comments as above wrt. references)

  This text seems to imply that there in fact exists a HTTP2 stream
  for the "parent subscription".  I don't think is necessarily true.

o  Section 5

  In RESTCONF in general, JSON is not mandatory.  I don't think this
  document should change that.

o  Section 5

  OLD:

   A publisher supporting [I-D.ietf-netconf-yang-push] MUST support the
   "operational" datastore as defined by [RFC8342].

  NEW:

   A publisher supporting [I-D.ietf-netconf-yang-push] MUST support the
   operational state datastore defined in [RFC8342].

  ... but why do we specify conformance requirement for YANG push in
  this document?

o  Section 6

  You should refer to Section 6.4 in RFC 8040 instead of RFC 5277.

o  Section 8

  Should the identity "restconf" be derived also from
  "sn:configurable-encoding"?

o  Section 8

  Why is "uri" augmented to "subscription-modified"?   The URI can't
  change dynamically, right?

  Should the leaf "uri" be renamed to "location", to align with 8040?

o  A.1.1

  The example POST is:

   POST /restconf/operations/subscriptions:establish-subscription

  This is not correct, it should be

   POST /restconf/operations/ietf-subscribed-notifications:establish-subscription

  (same for all POSTs in the examples)

o  A.1.1

  The example reply is:

   {
      "id": "22",
      "uri": "/subscriptions/22"
   }

  and then the GET is:

   GET /restconf/operations/subscriptions/22

  This isn't correct.  Perhaps change to:

      "uri": "https://example.com/restconf/subscriptions/22"

 and

   GET /restconf/subscriptions/22

o  A.3

  The example of a subtree filter is not correct:

  OLD:

       "stream-subtree-filter": "/ietf-vrrp:vrrp-protocol-error-event/",

  NEW:

       "stream-subtree-filter": {
         "ietf-vrrp:vrrp-protocol-error-event": {}
        }

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Oct 2018 18:48:39 +0000

Thanks for the review, inline.

On 2018-10-10, 7:45 AM, "Netconf on behalf of Martin Bjorklund" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    o  Title and Abstract
    
      This document is called:

      but netconf-notif called

<RR> Ack.

    
      It is not obvious that "RESTCONF Transport for Event
      Notifications" relates to "Customized Subscriptions to a Publisher's
      Event Streams".
<RR> So you're suggesting "RESTCONF Support for Customized  Subscriptions to a Publisher's Event Streams" (and likewise for NETCONF)?
    
      Also, the abstracts should probably also be aligned.
<RR> The 1st paragraph is identical,  I'll remove the 2nd paragraph of abstract in RESTCONF-notif.    
    
    o  Section 3.1
    
      Last sentence:

      Please clarify what this means.  Specifically, the subscriber needs
      to re-send the "establish-subscription" and do a new GET on the new
      URI.  (right?)
<RR> Will clarify and right.    
    
    o  Section 3.2
    
<RR> Correct.    
    
    o  Section 3.3

<RR> Correct.    
    
    o  Section 3.4
    
      The text says:

      I think that is also ok if the GET is sent on (a) - in the case that
      you don't care about being able to modify the subscription.  This
      should be clarified.
 <RR> Yes that also works, will add some text.
   
      Also, "modify-subscription" may be sent on some other session.
<RR> As long as from same subscriber I assume. Do we care about NAT scenarios?   
    
    o  Section 4

       What is the 'subscription "priority"'?  Can you add a reference.
<RR> Will do, dscp leaf in SN draft.    
       Can you also add a reference to HTTP2 stream priority?
 <RR> Will do, section 5.3 of rfc7540.   
    
    o  Section 4
    
       o  take any existing subscription "dependency" and map the HTTP2
          stream for the parent subscription into the HTTP2 stream
          dependency.
<RR> Will do, dependency leaf in SN draft and section 5.3.1 of rfc7540.       
      (same comments as above wrt. references)
    
      This text seems to imply that there in fact exists a HTTP2 stream
      for the "parent subscription".  I don't think is necessarily true.
<RR>  So just clarify that this applies only when there's an HTTP2 stream for the parent subscription?  
    
    o  Section 5
    
<RR> I agree. 

    o  Section 5
    
      OLD:

      NEW:

    
<RR> I think this is left over from earlier days, so will remove this. Looks like the whole section can be removed.    
    o  Section 6
    
<RR> Ack    
    
    o  Section 8
    
      Should the identity "restconf" be derived also from
      "sn:configurable-encoding"?
<RR> You are correct. And it was there in previous versions which had the http1.1/http2 transport identities.    
    
    o  Section 8
    
      Why is "uri" augmented to "subscription-modified"?   The URI can't
      change dynamically, right?
<RR> It shouldn't change so not needed. 
    
      Should the leaf "uri" be renamed to "location", to align with 8040?
<RR> I don't feel strongly about this one way or the other. Would like to hear from others.    
    
    o  A.1.1
    
      The example POST is:

    
    
<RR> Ack.    
    
    o  A.1.1
    
      The example reply is:

       {
          "id": "22",
    
      and then the GET is:

    
    
     and
    
<RR> Ack.    
    
    o  A.3

      OLD:

      NEW:
    
           "stream-subtree-filter": {
             "ietf-vrrp:vrrp-protocol-error-event": {}
            }
 <RR> Ack. Also s/XPATH/XPath in Figure 16.   
    
Regards,
Reshad.
    
    /martin
    
    _______________________________________________
    Netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Oct 2018 19:19:45 +0000

Inline.

On 2018-10-10, 2:49 PM, "Netconf on behalf of Reshad Rahman (rrahman)" <[email-masked] on behalf of [email-masked]> wrote:

<trimmed>        
        o  Section 8

<RR2> Based on changes made by Eric to SN and netconf-notif, we should take out the identity "restconf".

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Oct 2018 19:57:44 +0000

Inline.

    
    
<Trimmed>
        
        o  Section 3.4
        
          The text says:

          I think that is also ok if the GET is sent on (a) - in the case that
          you don't care about being able to modify the subscription.  This
          should be clarified.
     <RR> Yes that also works, will add some text.
<RR2> That would also prevent the subscriber from deleting the subscription. So I don't think this should be allowed, don't see the benefit.

<RR2>  Why allow for modify-subscription on another session, is this not an unnecessary complication?

Regards,
Reshad.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 09:41:21 +0200 (CEST)

Hi,

Trimming to open issues:

> <RR> So you're suggesting "RESTCONF Support for Customized  Subscriptions to a Publisher's Event Streams" (and likewise for NETCONF)?

This seems a bit excessive.  Maybe  "XXXCONF Support for Customized
Subscriptions to Event Notifications"

Maybe even change the SN title to the simpler

  "Customized Subscriptions to Event Notifications"

> <RR> As long as from same subscriber I assume. Do we care about NAT

There is nothing in SN that says that modify-subscription must be from
the same subscriber.

IMO the idea of restricting some rpcs to "the same transport session"
is unnecessary, and obviously problematic.  I think that the
restriction should be removed from delete-subscription (and then
remove kill-subscription, since it is the same as
delete-subscription).

> <RR>  So just clarify that this applies only when there's an HTTP2 stream for the parent subscription?  

I have no clue.  Why is this copting going on?  Isn't the priority and
dependency thing supposed to work for all types of transport?  If so,
why copy down to HTTP/2?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 09:44:09 +0200 (CEST)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> Inline.
> 
> On 2018-10-10, 2:49 PM, "Netconf on behalf of Reshad Rahman (rrahman)"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     On 2018-10-10, 7:45 AM, "Netconf on behalf of Martin Bjorklund"
>     <[email-masked] on behalf of [email-masked]> wrote:
>     
> <Trimmed>
>         
>         o  Section 3.4
>         
>           The text says:
>         
> <RR2> That would also prevent the subscriber from deleting the
> subscription. So I don't think this should be allowed, don't see the
> benefit.

The subscriber can simply close the connection to terminate.  I
suspect this is what most implementations will do anyway.

> not an unnecessary complication?

See my previous mail.  I think the current restriction is a
complication.  Note that there are no sessions in RESTCONF.  It is
true that the underlying HTTP connection can be kept, but this is just
an optimization.  We can't make the RESTCONF protocol behavior depend
on this.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 12:28:20 +0200 (CEST)

Hi,

In addition to my previous review, I have one more issue.

The document shows examples of how a "stream-xpath-filter" is encoded
in JSON.  But since there is no way to specify XML namespaces and
prefixes in JSON, this doesn't work.  I started a thread in NETMOD
for this
(https://mailarchive.ietf.org/arch/msg/netmod/5qRC1VqO58b7vXbNm3DVednpxtY).

Depending on the outcome, this document and/or
draft-ietf-netconf-subscribed-notification may need updates.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 14:18:22 +0000

Hi,

On 2018-10-11, 3:41 AM, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,
    
    Trimming to open issues:

<RR2> Works for me.

<RR2> Eric?

    
    IMO the idea of restricting some rpcs to "the same transport session"
    is unnecessary, and obviously problematic.
<RR2> Problematic from an implementation view or from a functionality view? Would like to hear from others on this.

    I think that the

    I have no clue.  Why is this copting going on?  Isn't the priority and
    dependency thing supposed to work for all types of transport?  If so,
    why copy down to HTTP/2?
<RR2> Stream dependency and priority are HTTP2 specific, so this explains how to map the subscription Qos properties to HTTP2 properties. 

Regards,
Reshad.

    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 16:30:36 +0200 (CEST)

> <RR2> Stream dependency and priority are HTTP2 specific, so this explains how to map the subscription Qos properties to HTTP2 properties. 

Are you saying that the "dependency" function in SN is not applicable
to all transports?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Oct 2018 14:38:29 +0000

> >     > <RR> So you're suggesting "RESTCONF Support for Customized
> Subscriptions to a Publisher's Event Streams" (and likewise for NETCONF)?
> >

We are not subscribing to Event Notifications, we are subscribing to a publisher's Event Streams in SN.   I don't think the SN title should change.

> > <RR2> Problematic from an implementation view or from a functionality
> view? Would like to hear from others on this.
> >
> >     I think that the
> > <RR2> Stream dependency and priority are HTTP2 specific, so this explains
> how to map the subscription Qos properties to HTTP2 properties.
> 
> Are you saying that the "dependency" function in SN is not applicable to all
> transports?

Dependency and priority are applicable to other transports.   The mapping happens to be very straight-forward with HTTP2.

Eric

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 14:52:14 +0000

Hi,

On 2018-10-11, 3:44 AM, "Martin Bjorklund" <[email-masked]> wrote:

    The subscriber can simply close the connection to terminate.  I
    suspect this is what most implementations will do anyway.
<RR3>  Assuming it's 1 subscription per connection, yes.

<RR3> Current restriction is a complication because the publisher would have extra check?    

Regards,
Reshad.

    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 17:07:33 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> We are not subscribing to Event Notifications, we are subscribing to
> a publisher's Event Streams in SN.

But SN is more than just subscriptions to streams.  It provides the
basics for other types of events than streams, such as YP.  And the
word "publisher's" is not really needed in the doc title, IMO.

> I don't think the SN title
> should change. 

Can you suggest titles for all three documents that makes it clear
that they belong together?

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 15:27:34 +0000

On 2018-10-11, 10:30 AM, "Martin Bjorklund" <[email-masked]> wrote:

    Are you saying that the "dependency" function in SN is not applicable
    to all transports?
What I'm saying is that there's a direct "mapping" of how to do this in HTTP2. For other transports, it is implementation specific.

Regards,
Reshad.
    
    /martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 15:38:29 +0000

Hi,

Since this is an existing issue (not caused by the -notif drafts), if the outcome is slow can we just remove this example to be able to advance those docs?

Regards,
Reshad.

On 2018-10-11, 6:28 AM, "Netconf on behalf of Martin Bjorklund" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    

    /martin

---

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

Cutting this part of the thread to one topic

>     There is nothing in SN that says that modify-subscription must be from

Up until  SN -v13, the text ensured the subscriber was the only one able to make any changes.  The current text -v17 does not have this constraint, and does allow an operator to modify a subscription in-flight.  Personally I don't like this flexibility.  I think it opens a security hole.   If other people have security configuration concerns with this flexibility (i.e., a new non-administrative subscriber might have permissions enabling them to make changes to a subscription), we should return the constraint to SN.  This re-introduced text would mirror that which exists for delete subscription.  I.e., "Dynamic subscriptions can only be modified via this RPC using a transport session connecting to the subscriber."

>     remove kill-subscription, since it is the same as

Some of the first comments received on SN were to segment RPC permissions for 'delete-subscription' and 'kill-subscription'.  Many have seen this differentiation as worthwhile.  

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 25 Oct 2018 00:07:51 +0000

> Since this is an existing issue (not caused by the -notif drafts),
> if the outcome is slow can we just remove this example to be able
> to advance those docs?

It appears that the outcome is slow.  Any objection to removing the
example so the Last Call can close?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Oct 2018 08:58:20 +0200 (CEST)

> example so the Last Call can close?

Yes, I object to that.  I think we need to address the issue, rather
than pretending it isn't an issue.  If we can't figure out what an
example looks like, how is an implementor supposed to get this right?

IMO SN should adopt the solution proposed by Juergen, and the example
updated.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 25 Oct 2018 13:11:46 +0000

Hi,

By Juergen's proposal are you referring to new xpath/ypath definition for context-independent encoding in 6991bis? And SN should wait for 6991bis? If so, why not go with Martin's alternative A?

What do we do about existing drafts/RFCs which use yang:xpath1.0? I don't know how many there are (only one which comes to mind is schema-mount).

FYI, looks like this issue was brought up a few years ago.
https://www.ietf.org/mail-archive/web/netmod/current/msg12906.html

Regards,
Reshad.

On 2018-10-25, 2:58 AM, "Martin Bjorklund" <[email-masked]> wrote:

    

    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Oct 2018 15:29:45 +0200 (CEST)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> Hi,
> 
> By Juergen's proposal are you referring to new xpath/ypath definition
> for context-independent encoding in 6991bis? And SN should wait for
> 6991bis?

No I meant that SN would adopt Juergen's proposal.  This can be done
today.

/martin

> If so, why not go with Martin's alternative A?
> 
> What do we do about existing drafts/RFCs which use yang:xpath1.0? I
> don't know how many there are (only one which comes to mind is
> schema-mount).
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 25 Oct 2018 13:32:34 +0000

> From: Martin Bjorklund,  October 25, 2018 9:30 AM
> 
> No I meant that SN would adopt Juergen's proposal.  This can be done today.

This works for me.   Can you provide a proposal for the desired YANG object text?  

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Oct 2018 15:49:44 +0200 (CEST)

> This works for me.   Can you provide a proposal for the desired YANG

Perhaps:

OLD:

              o  The set of namespace declarations are those in scope on
                 the 'stream-xpath-filter' leaf element.

NEW:

              o  The set of namespace declarations is the set of prefix
                 and namespace pairs for all YANG modules implemented
                 by the server, where the prefix is the YANG module
                 name and the namespace is as defined by the
                 "namespace" statement in the YANG module.

                 If the leaf is encoded in XML, all namespace
                 declarations in scope on the 'stream-xpath-filter'
                 leaf element are added to the set of namespace
                 declarations.  If a prefix found in the XML is
                 already present in the set of namespace declarations,
                 the namespace in the XML is used.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 25 Oct 2018 14:20:21 +0000

> From: Martin Bjorklund, October 25, 2018 9:50 AM
> 
> > > > By Juergen's proposal are you referring to new xpath/ypath
> > > > definition for context-independent encoding in 6991bis? And SN
> > > > should wait for 6991bis?
> > >

This works for me.   Thanks!

Eric

> > > > What do we do about existing drafts/RFCs which use yang:xpath1.0?
> > > > I don't know how many there are (only one which comes to mind is
> > > > schema-mount).
> > > >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 25 Oct 2018 18:34:51 +0000

Thanks Martin. So this is using the module name instead of using the module prefix? 

Regards,
Reshad.

On 2018-10-25, 9:29 AM, "Martin Bjorklund" <[email-masked]> wrote:

    /martin