Subject: [Netconf] two-week review of drafts related to notifications and subscriptions

From: Kent Watsen <[email-masked]>
Date: Wed, 4 Oct 2017 21:24:57 +0000

We’d like to direct the WG attention to the set of drafts related to notifications and subscriptions, with the goal of getting a pulse on if the WG thinks they are ready to progress now.
 
To enable you get an overview and to see how the documents relate to each other, this draft is a good place to start:  https://tools.ietf.org/html/draft-voit-netconf-subscription-and-notif-overview-00.
 
The drafts related to this review are:
   -  draft-ietf-netconf-subscribed-notifications
   -  draft-ietf-netconf-yang-push
   -  draft-ietf-netconf-netconf-event-notifications
   -  draft-ietf-netconf-restconf-notif
   -  draft-ietf-netconf-notification-messages
 
While this is not an official WGLC, we will issue one if the response is positive. Please provide comments within two weeks.
 
Thanks,
Mahesh and Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 Oct 2017 22:54:55 +0000

Thanks Kent for kicking off this review!   Some thoughts in-line...

> From: Kent Watsen, Wednesday, October 4, 2017 5:25 PM
> 
> We’d like to direct the WG attention to the set of drafts related to notifications
> and subscriptions, with the goal of getting a pulse on if the WG thinks they are
> ready to progress now.
> 
> To enable you get an overview and to see how the documents relate to each
> other, this draft is a good place to start:  https://tools.ietf.org/html/draft-voit-
> netconf-subscription-and-notif-overview-00.
> 

The three drafts above should be in fairly good shape.  It would be great to get comments on any and all aspect of these documents.

>    -  draft-ietf-netconf-notification-messages

'notification-messages' is just recently adopted, and there are multiple open questions listed in the appendix.  I don't think this should be read with an eye toward WGLC.  But it can safely be read for solution elements, approaches, and gaps.

>    -  draft-ietf-netconf-restconf-notif

Even though restconf-notif has been around for a while, I don't think it is ready for a fine-toothed comb at this point.  There are several reasons for this:
a) There is not an easily accessible Notification element for encoding in JSON until notification-messages draft solidifies.  (And RESTCONF has market affinity with JSON.)
b) Capability discovery is much easier for configured subscriptions over HTTP2 once notification-messages is available. 
c) There are no implementations which have validated the approach.  

As an author, I have *not* cleaned up examples in restconf-notif yet because these examples will change based on the result of work on the notification-messages draft.  That said this document is also readable for solution elements and approaches.

Thanks,
Eric

> 
> While this is not an official WGLC, we will issue one if the response is positive.
> Please provide comments within two weeks.
> 
> Thanks,
> Mahesh and Kent
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 11 Oct 2017 02:39:41 +0000

I agree with Eric, and support the following three documents to go to LC.
-  draft-ietf-netconf-subscribed-notifications
-  draft-ietf-netconf-yang-push
-  draft-ietf-netconf-netconf-event-notifications

We also have implementations on these.
We had a successful Hackathon during the 99 meeting. A collector can subscribe data from network which consists of Cisco and Huawei devices in remote labs.

Regards,
Tianran

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit
> (evoit)
> Sent: Thursday, October 05, 2017 6:55 AM
> To: Kent Watsen
> Cc: [email-masked]
> Subject: Re: [Netconf] two-week review of drafts related to notifications
> and subscriptions
> 
> > We’d like to direct the WG attention to the set of drafts related to
> > notifications and subscriptions, with the goal of getting a pulse on
> > if the WG thinks they are ready to progress now.
> >
> > To enable you get an overview and to see how the documents relate to
> > each other, this draft is a good place to start:
> > https://tools.ietf.org/html/draft-voit-
> The three drafts above should be in fairly good shape.  It would be great
> to get comments on any and all aspect of these documents.
> 
> 'notification-messages' is just recently adopted, and there are multiple
> open questions listed in the appendix.  I don't think this should be read
> with an eye toward WGLC.  But it can safely be read for solution elements,
> approaches, and gaps.
> 
> Even though restconf-notif has been around for a while, I don't think it
> is ready for a fine-toothed comb at this point.  There are several reasons
> for this:
> a) There is not an easily accessible Notification element for encoding in
> JSON until notification-messages draft solidifies.  (And RESTCONF has
> market affinity with JSON.)
> b) Capability discovery is much easier for configured subscriptions over
> HTTP2 once notification-messages is available.
> As an author, I have *not* cleaned up examples in restconf-notif yet because
> these examples will change based on the result of work on the
> notification-messages draft.  That said this document is also readable for
> solution elements and approaches.
> 
> Thanks,
> Eric
> 
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Oct 2017 09:10:25 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> https://tools.ietf.org/html/draft-voit-netconf-subscription-and-notif-overview-00. 
>  

After Eric's reply, I think the list is:

Here are my comments on these documents:

draft-ietf-netconf-netconf-event-notifications-05
-------------------------------------------------

As I have written before, this document has very little normative
text.  In fact, it almost only consists of XML examples of the
definitons in draft-ietf-netconf-subscribed-notifications-05.

The normative text can be summarized as:

   A NETCONF server implementation supporting [subscribe] must support
   dynamic subscriptions and the "NETCONF" notification event stream.

   A NETCONF server implementation supporting [yang-push] must support
   the "running" datastore.

The latter is not really needed; all NETCONF servers must support
running.

BTW, *none* of the example XML snippets are valid according to the
data model in draft-ietf-netconf-subscribed-notifications-05.

I suggest this document is removed.

draft-ietf-netconf-subscribed-notifications-05
----------------------------------------------

A general comment is that this document is quite hard to read.  The
terminology is not used consistently, and often new terms are used
without explanation.

As an example, section 4.1 describes the "stream" input parameter to
"establish-subscription" as:

   o  A stream which identifies the domain of events against which the
      subscription is applied.

This sounds complicated, what is a "domain of events"?  Isn't the
parameter simply the name of a stream?

I suggest the text is cleaned up wrt. terminology.  Below I also
suggest to remove some text that is not really needed, to make the
document easier to read.

The relationship to RFC 5277 is not clear.  This document provides a
conflicting definition of streams.  Is this new definition supposed to
replace the old one, or are both supposed to co-exist?  The stream
mechanism in RFC 5277 works, is implemented in many systems, and is
used quite a lot in real operations.  I object to replacing it with
something new.  Specifically, the stream name should continue to be a
string, not an identity, in order to contine to support dynamically
created streams.

General stylistic suggestion: don't use angle brackets for YANG
definitions.  For example, don't write:

  <subscription-result>

but instead:

  "subscription-result".

o  Section 1

  What is a "subscription control plane operations binding"?

  In general, are dynamic subscriptions for NETCONF only?  This needs
  to be clarified.

o  Section 1.1

    o  multiple subscriptions on a single transport session

  How is this achieved?  As far as I can see, this is not specified.

    o  negotiation of subscription parameters

  There is no negotiation going on.  The RPC succeeds or fails.  I
  suggest this is removed.

    o  promise theory based interaction model

  Why is this listed here?  I suggest this is removed.

o  Section 2.1

  The document adds a stream called SYSLOG, which:

   mirrors the
   discrete set entries which are concurrently being placed into a
   device's local Syslog

  I don't understand what this means, and it is not clear how the
  syslog messages are to be transported in XML or JSON.

  I suggest this stream is removed.

o  Section 2.2

  The first paragraph is difficult to parse.

o  Section 3

  The data model should use a NMDA-style single tree.

o  establish-subscription

  The input parameters to this operation are weird:

   +---x establish-subscription
    |  +---w input
    |  |  +---w encoding?            encoding
    |  |  +---w (target)
    |  |  |  +--:(stream)
    |  |  |     +---w (event-filter)?
    |  |  |     |  +--:(by-reference)
    |  |  |     |  |  +---w event-filter-ref     event-filter-ref
    |  |  |     |  +--:(within-subscription)
    |  |  |     |     +---w (filter-spec)?
    |  |  |     |        +--:(subtree-filter)
    |  |  |     |        |  +---w subtree-filter?      <anydata>
    |  |  |     |        +--:(xpath-filter)
    |  |  |     |           +---w xpath-filter?        yang:xpath1.0
    |  |  |     +---w stream               stream
    |  |  |     +---w replay-start-time?   yang:date-and-time {replay}?
    |  |  +---w stop-time?           yang:date-and-time

  Note how the "stream" name is not even mandatory, it is down in a
  case.  I assume this is not intentional?

o  4.1

    Optionally,
    the <subscription-result> MAY include one or more hints on
    alternative input parameters and value which would have resulted in
    an accepted subscription.

  I think these hints have been removed, so this sentence should also
  be removed.

o  4.1.1

    The presence of a replay-start-time within an <establish-
    subscription> RPC is the way a replay may be been requested.

  This sentence looks a bit odd.

    The provided start time MUST be earlier than the current time.

  I know that this text is also present in RFC 5277, but I think it
  needs to be changed.  Which current time?  Probably the server's,
  but how would a client know that?  This is a problem that we faced
  when implementing 5277.   I think we should remove this
  requirement, since it doesn't add any value anyway.

    If
    the start time points earlier than the maintained history of
    Publisher's event buffer, then the subscription MUST be rejected.

  This sentence is also odd.  Also, why is this restriction added?
  RFC 5277 says:

         If the <startTime> specified is
         earlier than the log can support, the replay will begin with
         the earliest available notification.

  which allows a client to replay the entire history by specifying an
  early time.  I think we should stick to the old behavior.  (Then you
  can also remove the "history-unavailable" identity).

    Not all streams will support replay.  Those that do MUST include the
    <replay-supported> flag.

  The last sentence lacks context.  What <replay-supported> flag?  I
  think you mean "replay-support" leaf in the "/streams" list.

o  4.2

    The <delete-subscription> operation permits canceling an existing
    subscription previously established on that transport session.  If
    the publisher accepts the request, it immediately stops sending
    events for the subscription.

  I think we should add "After a successful reply has been sent, the
  server MUST NOT send any more notifications for this subscription.".

  (same language for "modify-subscription")

o  4.4

    The <kill-subscription> operation permits an operator to end any
    dynamic subscription.  A publisher MUST terminate any dynamic
    subscription identified within a properly authenticated RPC
    request.

  What does the last sentence mean?  I suggest you clarify.

  How is a client supposed to know which subscription-id to use?

o  5.

    o  One or more receiver IP addresses (and corresponding ports)
       intended as the destination for push updates for each
       subscription.  In addition, the transport protocol for each
       destination MAY be defined.

  Is seems odd that the transport protocol MAY be defined.

  I see what you mean, since "protocol" has a default value, it
  doesn't have to be explicitly configured.  But it is still
  defined...  I would actually suggest that the default value is
  removed, and "protocol" made mandatory.  Or, to also solve the issue
  that Tim Jenkins reported, make the "protocol" leaf part of the key.

o  5.1

  This section contains some obvious and redundant text and examples,
  but misses to explain some important concepts.  First of all, the
  first paragraph doesn't really say anything and can be removed.
  Second, the example shows how to do an edit-config; this is not very
  interesting, so I think it should be removed as well.

  But I think it instead should explain what is supposed to happen
  during and after the call home.  The fact that these subscriptions
  relies on call home is currently hidden at the end of a single
  sentence.   This should be made much clearer, and the call flow
  explained.  Once the call home has been made for NETCONF, are
  "notification" elements just started to be sent?    How are
  notifications sent over a RESTCONF call home - the server can't just
  send a HTTP repsonse, right?

  Will the server buffer notifications during call home setup?

  What happens if a transport session goes down?  Will the server
  immediately try to re-establish?  What if that fails?  What happens
  if the call home setup due to authentication issues, will it still
  try to re-establish?

o  7.

    Once a subscription has been set up, the publisher streams
    asynchronously push subscribed content via notification messages per
    the terms of the subscription.

  What is "asynchronously push subscribed content"?

  Please reword.

     This notification message MAY be encoded as one-way notification
     element of [RFC5277], Section 4.

   Ok, I think I know what you mean; you want this spec to use 5277
   for now, but when we define a new notification message, that one
   should be used instead.  But the current text with MAY is too lax,
   imo. I think it should be a MUST, and when the new notification
   message document is published, it can update this document.

   Or maybe you meant that the format of the messages might vary?  If
   so, I suggest that we specify that the messages are encoded in a
   transport-protocol specific manner.  For NETCONF and RESTCONF over
   XML it MUST be ... (5277).   Etc.

    These drawbacks, along with other useful common headers and the
    ability to bundle multiple event notifications together is being
    explored within [I-D.notification-messages].  When this draft is
    supported, it will be possible to support the encoding of YANG
    modeled notification messages with JSON via [RFC7951].

  JSON is already supported for notifcations over RESTCONF, so the
  last sentence should be removed.

o  9.2

    Capabilities are advertised in messages sent by each peer during
    session establishment [RFC6241].  Publishers supporting the RPCs and
    Notifications in this document MUST advertise the capability
    "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications:1.0".  In
    addition support for optional features: json, configured-
    subscriptions, and replay MAY also be advertised.

  I don't think a new protocol capability is needed; the normal YANG
  module advertisment is enough.  This normal module advertisment also
  has the benefit of being protocol neutral; if you want to use
  protocol capabilities, you need to register one per protocol with
  IANA.

    If a publisher supports this specification but not [RFC5277], the
    publisher MUST support the one-way notification element of [RFC5277]
    Section 4 or [I-D.notification-messages].

  I think this MUST makes I-D.notification-messages a normative
  reference, which probably is not what you want.

o  10 - module meta data

     module ietf-subscribed-notifications {
     ...

     description
       "Contains a conceptual YANG specification for subscribing to events
       and receiving matching content within notification messages.";

  s/conceptual YANG/YANG/

     revision 2017-10-02 {
       description
         "Filtering and stream structures updated, replay a feature.";

  Change to: "Initial revision."

o  10 - encoding

  I don't think the "encoding" leaf is done correctly.  Each
  subscription has an encoding, but the same subscription may serve
  receivers with different protocols.   But since NETCONF doesnsn't
  use JSON, this isn't really feasible.   Maybe the "encoding" should
  be moved down to the "receiver" list?

o  10 - features

    feature configured-subscriptions {
      description
        "This feature indicates that management plane configuration
         of subscription is supported.";
    }

  s/management plane //

    feature replay {
      description
        "This feature indicates that historical event replay is
        supported.  With replay, it is possible for past events to be
        will be streamed in chronological order.";

  s/will be//

o  10 - extension

     extension subscription-state-notif {

  I think you should spell out notification; i.e., use
  subscription-state-notification.

       description
         "This statement applies only to notifications. It indicates that
          the notification is a subscription state notification. Therefore
          it does not participate in a regular event stream and does not
          need to be specifically subscribed to in order to receive
          notifications.";

  I suggest you write:  "This statement can only occur as a
  substatement to the 'notification' statement."  Or something along
  that line.

o  10 - Identities for subscription results

  You define identities for 'ok' and 'error'.  I think Andy already
  pointed out that errors are reported in the protocol; in NETCONF
  using <rpc-error> and in RESTCONF by using an approprioate HTTP
  error code.

o  10 - Identities for subscription stream status

  Should subscription status really be identities?   Shouldn't these
  values correspond to the state machine in section 2.3?  If so, does
  that mean that the state machine is extensible?  I think this just
  adds complexity, and that using an enumeration is better.

o  10 - Identities for transports

  Shouldn't RESTCONF be present?

  You define an identity for 'http2', but there is no reference and no
  details about this transport.

  BTW, terminology issue, you use the terms "transport",  "protocol",
  and "transport protocol" for the same thing.  I suggest you pick
  one.

o  10 - filter-id

  Why is "filter-id" an integer?  Since filters are configured, using
  a string as identifier is preferable.  Then the operator can give
  the filters meaningful names, instead of trying to remeber if it was
  filter 5 or 7 that filters for bgp-related notifications.

o  10 - subscription id

  Same issue as for filter id; I think the subscription-id should also
  be a string.

o  Terminology issue:

  In general, sometimes you are using the term "event" when you mean
  "notification".  Sometimes you also use "notification event", which
  is unclear.

o  10 - /filters/event-filter

  For consistency: s/event-filter/filter/

  also fix event-filter-ref, and maybe others.

o  10 - filters

  I think you should copy section 5 from RFC 5277, but change it to
  use YANG, since eventually RFC 5277 will be obsoleted.

      anydata subtree-filter {
        description

  OLD:

          "Event stream evaluation criteria encoded in a syntax of a
           supported type of an RFC 6241, Section 6 filter.  When
           applied against an event stream and there is a non-empty or
           positive result, the event is passed along.";

  NEW:

          "Event stream evaluation criteria encoded in the syntax of
           a subtree filter as defined in RFC 6241, Section 6.

           The subtree filter is applied to the contents of the
           notification message, i.e., the top-level element is the
           element representing the notification's name.

           If the subtree filter returns a non-empty node set, the
           filter matches the notifcation, and the notification is
           sent to the receivers.";

        reference "RFC 6241, Section 6.";
      }
      leaf xpath-filter {
        type yang:xpath1.0;
        description

OLD:

          "Event stream evaluation criteria encoded in a syntax of xpath
          1.0  When applied against an event stream and there is a
          non-empty or positive result, the event is passed along.";

NEW:

          "Event stream evaluation criteria encoded in the syntax of
           an XPath 1.0 expression.

           The result of the XPath expression is converted to a
           boolean value using the standard XPath 1.0 rules.  If the
           boolean value is 'true', the filter matches the
           notification, and the notification is sent to the
           receivers.

           The XPath expression is evaluated in the following context:

             o  The set of namespace declarations are those in scope on
                the leaf element where this type is used.

             o  The set of variable bindings is empty.

             o  The function library is the core function library, and
                the XPath functions defined in section 10 in RFC 7950.

             o  The context node is the root node in the data tree.";

        reference
          "http://www.w3.org/TR/1999/REC-xpath-19991116
           RFC 7950, Section 10.";
      }

    grouping event-filter-elements {
      description
        "This grouping defines the base for filters for notification
         events.";
      choice filter-spec {
        description
          "The content filter specification for this request.";

  I think you should add some text that explains that this is a choice
  so that other filters can added via augmentation.  Such a filter
  must explain how it is evaluated and how its result is interpreted.

o  10 - typedef egressing-from

  This typedef is not used, and should be removed.
  (some descriptions in this grouping are not very clear, but it
  doesn't matter if it is removed.)

o  10 - grouping notification-origin-info

  Here's an example of when the langauge can be tightened a bit.  The
  descriptions in this grouping uses the terms "origin", "sender
  source", "egress interface", "push source" for what I *think* is the
  same thing.

    grouping notification-origin-info {
      description
        "Defines the sender source from which notifications for a
         configured subscription are sent.";
      choice notification-origin {
        description
          "Identifies the egress interface on the Publisher from which
           notifications will or are being sent.";
        case interface-originated {
          description
            "When the push source is out of an interface on the
             Publisher established via static configuration.";
          leaf source-interface {
            type if:interface-ref;
            description
              "References the interface for notifications.";
          }
        }
        case address-originated {
          description
            "When the push source is out of an IP address on the
             Publisher established via static configuration.";
          leaf source-vrf {
            type string;
            description
              "Network instance name for the VRF.  This could also have
              been a leafref to draft-ietf-rtgwg-ni-model, but that model
              is not complete, and might not be implemented on a box.";

  I think that you really need to use a reference to the NI model.
  Alternatively remove this case for now, and add it later.

          leaf source-address {
            type inet:ip-address-no-zone;
            description
              "The source address for the notifications.  If a source VRF
              exists, but this object doesn't, a default address for the
              VRF can be used.";

  "a default address for the VRF can be used."  - Please rephrase.  I
  think you mean something like "the publisher is free to pick a
  suitable source address".

draft-ietf-netconf-yang-push-10
-------------------------------

I haven't had time to review this one yet.

/martin

---

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Fri, 13 Oct 2017 10:08:13 +0000

Hi all,

  I believe that the documents are useful and would like to see them go to Last Call.  And we have had a successful yang-push show-case on IETF99 Hackathon.
  
  But I have some comments want to confirm:
  
draft-ietf-netconf-subscribed-notifications-05.txt
1.these two identity not in the same protocol stack level
[netconf] <=>  [restconf]
[ssh]     <=>  [http2]
identity netconf {
    base transport;
    description
      "Netconf notifications as a transport.";
  }
  identity http2 {   
    base transport;
    description
      "HTTP2 notifications as a transport";
  }
2.subscription-id is assigned by client or by server？
  In “establish-subscription” rpc, the subscription-id  is the output parameter, 
  but in "subscription-config", it is key, that's mean assigned by client, if assigned by client, how to ensure different client configuration does not conflict?
3.notification subscription-started // suggest to specify only configed subscription support this notification
4.subscription-modified/subscription-policy
 it's suggested to add some description to specify should reply the new subscription information.

draft-ietf-netconf-yang-push-10
1.import ietf-datastores  // ietf-datastores is still draft, whether it will impact the lastcall of this draft?
2.identity custom-datastore
//what's the scenario about this datastore should be explained by description.
3.In "typedef change-type ", given 7 ietms as "create/delete/insert/merge/move/replace/remove", 
but, as we know, other client such as CLI may change the datastore, and the operation of cli can not map to these 7 items.
so, whether can define it from the data result view? I think "create/delete/modify " is enough, since it is to guide the client to update it's local datastore.
4.uses selection-filter-objects; //suggest to move the grouping definition "selection-filter-objects" before use it, :)
5.The yang module does not reference NMDA guide, should check it.

draft-ietf-netconf-netconf-event-notifications-05.txt
1. "severity" is defined in which RFC? whether need add to some draft?
2. in section 3.3.1.4.  Subscription Negotiation, some error:

      <netconf:rpc message-id="101"
         xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
         <establish-subscription
               xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
            <datastore>running</datastore>
            <event-filter-type>
              subtree</event-filter-type> //walker comments: here is subtree
            <event-filter-contents
                  xmlns:ex="http://example.com/sample-data/1.0">
                  select="/ex:foo" /> //walker comments: but here is "xpath"
            <dampening-period>10</dampening-period>
            <encoding>encode-xml</encoding>
         </establish-subscription>
      </netconf:rpc>
      
3. In section 3.2.1.  Usage Example
<event-filter-type>subtree-event-filter</event-filter-type> //walker comments: the enum value not same as pre example in section 3.3.1.4, where is "subtree"
         <event-filter-contents
           xmlns:ex="http://example.com/sample-data/1.0">
           select="/ex:foo" />
4. in section 3.4.1.  Establishing a Configured Subscription
 <rpc message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         //walker: here should have a Parameter of <config>, which defined by RFC6241
         <subscription-config
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
                 
5. in section 3.4.1.  Establishing a Configured Subscription
walker: here not comply RFC6241, it should be <rpc-error>, it here add attributes, should augment to standard <rpc-reply> output.
   <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <subscription-result
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
       error-insufficient-resources
     </subscription-result>
   </rpc-reply> 
   
6. in section 3.4.4.1.  Message Flow Example
in sample message id is 1922, but in Message Flow is 22, it is suggested to keep same.

7. In section 3.1.  Event Stream Discovery
stream is not defined in yang-push namspace:

   <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <data>
       <streams
          xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
         <stream>
           <stream>NETCONF</stream>
           <description>The NETCONF mandatory event stream</description>
         </stream>
         <stream>

draft-ietf-netconf-restconf-notif-03

1.[sn],   walker: it's better to give the full draft name.
2. in section 3.2.  Subscription Multiplexing
 a Receiver might consider performing a GET to validate the current state of a Publisher.
 walker: it's better to list the states here.
 
3.Should the publisher not support the requested subscription, it may reply:
it is a little difficult to understand this sentence, whether "should" change to "if" will be better? :)

4. in [sn] 
 typedef subscription-id {
    type uint32;
    description
      "A type for subscription identifiers.";
  }

    <subscription-id xmlns="urn:ietf:params:xml:ns:restconf:
            datastore-push:1.0">
              my-sub  //walker: but in this draft the type should be string?
     </subscription-id>

5.in section 4.2.  Event Notification over HTTP2. The example is a little sample, whether can define it refrence http 1.1's examples?

draft-ietf-netconf-notification-messages-02
1. whether "signature " is mandatory?

> From: Netconf [mailto:[email-masked]] On Behalf Of Kent 
> Watsen
> Sent: Wednesday, October 04, 2017 2:25 PM
> To: [email-masked]
> Subject: [Netconf] two-week review of drafts related to notifications 
> and subscriptions
> 
> https://tools.ietf.org/html/draft-
> voit-netconf-subscription-and-notif-overview-00.
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 13 Oct 2017 20:40:56 +0000

Thanks Walker for the review.  Some thoughts in-line...

> From: Zhengguangying (Walker), October 13, 2017 6:08 AM
> 
> Hi all,
> 
>   I believe that the documents are useful and would like to see them go to Last
> Call.  And we have had a successful yang-push show-case on IETF99 Hackathon.
> 
> 1.these two identity not in the same protocol stack level [netconf] <=>
> [restconf]
> [ssh]     <=>  [http2]
> identity netconf {
>     base transport;
>     description

The use of NETCONF and HTTP2 is intentional.  The mail goal is to of this was to identify the allowed transport protocol to use for transferring the subscribed content messages with configured subscriptions.  
i.e., 
    +--rw subscription-config {configured-subscriptions}?
       +--rw subscription*
          +--rw receivers
             +--rw receiver* 
                +--rw protocol?   transport-protocol   <-- this could be NETCONF or HTTP2

Restconf is never used as an encapsulation for subscribed content.  So that shouldn't appear in this list.  

However HTTP1.1 should be added as an identity, because HTTP1.1 is allowed to be seen in the read-only tree.

    +--rw subscriptions
       +--rw subscription*
          +--rw receivers
             +--rw receiver* 
                +--rw protocol?   transport-protocol   <-- this could be NETCONF, HTTP2, HTTP11

>   but in "subscription-config", it is key, that's mean assigned by client, if
> assigned by client, how to ensure different client configuration does not
> conflict?

This is done via implementation separation.  See paragraph 1 of Section 11.1.

> 3.notification subscription-started // suggest to specify only configed
> subscription support this notification 4.subscription-modified/subscription-
> policy

It shouldn't impact last call.   But it could delay when it becomes an RFC.

> //what's the scenario about this datastore should be explained by description.

I will add more text on this.  One reason might be that an existing datastore might expose more information that can easily be filtered via an allowable xpath.   A custom datastore could act as a pre-filter to allow a vendor to reduce the domain of YANG objects, and more easily make a selection.   It will be up to the vendor to create their own identities which would use custom-datastore as a parent.

> 3.In "typedef change-type ", given 7 ietms as
> "create/delete/insert/merge/move/replace/remove",
> but, as we know, other client such as CLI may change the datastore, and the
> operation of cli can not map to these 7 items.
> so, whether can define it from the data result view? I think
> "create/delete/modify " is enough, since it is to guide the client to update it's
> local datastore.

The Publisher originates the change-types.   As a result, if you can accomplish everything you need with those three, there is zero reason to add the others.  You implementation will be fully compliant.

> 4.uses selection-filter-objects; //suggest to move the grouping definition
> "selection-filter-objects" before use it, :)

Can do.

> 5.The yang module does not reference NMDA guide, should check it.

We expect the NMDA police might ask for a conversion of the model to become compliant.  As this model was in existence long before NMDA, and because the model doesn't really get key benefits of NMDA, we are hopiong to be allowed to retain the current structure.  But if we must change, we will.

> 1. "severity" is defined in which RFC? whether need add to some draft?

That is just an example filter expression. 

>          </establish-subscription>

Yes this needs to be fixed

> <event-filter-type>subtree-event-filter</event-filter-type> //walker comments:
> the enum value not same as pre example in section 3.3.1.4, where is "subtree"

Yes, it looks like all should be: subtree-event-filter

>          //walker: here should have a Parameter of <config>, which defined by

This makes sense

> walker: here not comply RFC6241, it should be <rpc-error>, it here add
> attributes, should augment to standard <rpc-reply> output.

Agree.   I will send out the error-code to RPC mappings we did from last January in the next few days.   If people desire, we could include this as an appendix in one of the drafts.

> in sample message id is 1922, but in Message Flow is 22, it is suggested to keep

Agree

>            <description>The NETCONF mandatory event stream</description>

Agree
 
> 1.[sn],   walker: it's better to give the full draft name.

For historical reasons, it would be hard to change now.

>  walker: it's better to list the states here.

This might be a language translation issue.  State-entangled just means data values are inter-dependent.  Current state means we do a "get" to resolve the yang tree where it might be unclear to the receiver.

> it is a little difficult to understand this sentence, whether "should" change to

Yes

>               my-sub  //walker: but in this draft the type should be string?

Yes, this should be a number.

>      </subscription-id>
> 
> 5.in section 4.2.  Event Notification over HTTP2. The example is a little sample,
> whether can define it refrence http 1.1's examples?

This is a good idea.   It just hasn't been done yet as we are trying to close out the first three documents first.  We will get to this document for sure.   In my opinion more changes are needed before we do a deep review

> 1. whether "signature " is mandatory?

Not mandatory

Eric

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 13 Oct 2017 21:27:19 +0000

Not sure if I already responded:

As coauthor, I second Eric's comments that 
-  draft-ietf-netconf-subscribed-notifications
-  draft-ietf-netconf-yang-push
-  draft-ietf-netconf-netconf-event-notifications

should go to WGLC at this point.  This will flesh out what final issues need to be taken care of.  As mentioned by others, there are already implementations of this and we should bring this cycle to a closure.  

I do believe the list should include netconf-netconf-event-notifications, even if there are some aspects requiring fixing and could be shortened as pointed out by Martin.  This supports the concept of keeping the transport binding separate from subscription control (and message header contents) to separate concerns, which is a key aspect as also determined when the WG adopted the work.  

The remaining two drafts should be targeted once the WGLC of the first three is finished.  

--- Alex

> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Subject: [Netconf] two-week review of drafts related to notifications and
> subscriptions
> 
> notifications and subscriptions, with the goal of getting a pulse on if the WG
> thinks they are ready to progress now.
> 
> other, this draft is a good place to start:  https://tools.ietf.org/html/draft-

---

From: Robert Wilton <[email-masked]>
Date: Wed, 18 Oct 2017 18:15:24 +0100

Hi,

I've not had a chance to review all of these drafts yet, but I did look 
at both: draft-voit-netconf-subscription-and-notif-overview-00 and 
draft-ietf-netconf-notification-messages.

My high level comments are below:

It is unclear to me whether the plan is to publish 
subscription-and-notif-overview or not?  Having an overview document 
that binds the technologies together could be quite useful (in fact some 
of the background, and definitions could move to an overview draft, but 
I think that this intro draft could do with further work before going to 
WG LC.

The other question I had was relating to the ordering of this work. I 
understand the strong desire the get this work completed, but I do 
wonder whether the drafts would all be able to sit together more 
coherently if the work on draft-ietf-netconf-notification-messages was 
completed first, then the other drafts could presumably more cleanly 
depend on the new notification message format.

Regarding the notification message format itself: I wasn't quite sure if 
there needs to be a split between a bundled and unbundled message, in 
that it seems that having a single message format might be easier, e.g. 
by always using the bundled message format.

But then I was also questioning that if the messages are being streamed 
(e.g. over TCP) then possibly you don't want to include all of the 
header information, in that it is presumably desirable to keep the 
streamed messages as compact as possible.  I think that there is 
probably a bit of the bigger picture that I'm still missing.

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Oct 2017 19:13:18 +0000

Hi Robert,

Thanks for the review.  Some thoughts in-line...

> From: Robert Wilton, October 18, 2017 1:15 PM
> 
> Hi,
> 
> I've not had a chance to review all of these drafts yet, but I did look at both:
> draft-voit-netconf-subscription-and-notif-overview-00 and draft-ietf-netconf-
> notification-messages.
> 
> It is unclear to me whether the plan is to publish subscription-and-notif-
> overview or not?  Having an overview document that binds the technologies
> together could be quite useful (in fact some of the background, and definitions
> could move to an overview draft, but I think that this intro draft could do with
> further work before going to WG LC.

I have not been thinking of progressing this overview document into a WG draft.  The main reason is that several highly placed members of the IETF have expressed that they don't want to see a proliferation of generalized architecture context documents.  With Kent's assistance, I have been trying to straddle this line.

> understand the strong desire the get this work completed, but I do wonder
> whether the drafts would all be able to sit together more coherently if the
> work on draft-ietf-netconf-notification-messages was completed first, then the
> other drafts could presumably more cleanly depend on the new notification
> message format.

There is still a lot of longer-term work which needs to be done on notification-messages.  Once the format stabilizes, we will be going through each header object to determine its proper articulation.  Objects like signature are about to get contributions on this doc.  Items like attestation of the contents of the messages (as well as alignment with attestation of information returned from a GET) could also take some time.

And there are short term drivers which suggest we should close on some form of yang-push over NETCONF at least.  For example, at the last IETF, there was already some inter-vendor work at the Hackathon looking at interoperability.  Also there exist several open source implementations of a Subscriber client.  My hope is we just close now on that context, and let the rest await the availability of notification-messages.

> Regarding the notification message format itself: I wasn't quite sure if there
> needs to be a split between a bundled and unbundled message, in that it
> seems that having a single message format might be easier, e.g.
> But then I was also questioning that if the messages are being streamed (e.g.
> over TCP) then possibly you don't want to include all of the header
> information, in that it is presumably desirable to keep the streamed messages
> as compact as possible.  I think that there is probably a bit of the bigger picture
> that I'm still missing.

Yes, going to one message can be done.  But as you point out It adds overhead especially to smaller high frequency messages.  The other complexity with bundled messages is the publisher needs to determine exactly what should be placed in each bundle.  This might not seem to be an issue, but what if some elements of the bundle need to be signed, and others do not.   What should be the behavior?

In the end, if the IoT guys don't have an issue with efficiency (where this seems to matter most), we could collapse to one.  (it is discussions like this which need to stew for a while before we can close on notification-messages.)

Eric
 
> > While this is not an official WGLC, we will issue one if the response is
> positive. Please provide comments within two weeks.
> >
> > Thanks,
> > Mahesh and Kent
> >
> >

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 18 Oct 2017 20:35:52 +0000

Hi Rob,

Thanks for your response!  Two quick comments to add on to Eric's:

Regarding ordering of the work: IMHO, we shouldn't serialize this work but try to advance subscribed-notifications, yang-push, and netconf-notifications at the same time.  This work was already started three years ago with yang-push, from where the work was broken out and modularized into the current pieces (with some new pieces added, of course), and I think it is really time to bring it to a closure .  

Regarding notifications and notification bundles, I think it is a worthwhile optimization to address individual notifications (vs notification bundles containing just one notification), given that the bundle comes with some overhead.  But of course you are correct in that the single notification can be considered a special case and be addressed just by a notification bundle, and ultimately it would be up to servers to decide what to do (if they have only a single notification to send). 

Thanks
--- Alex 

> Sent: Wednesday, October 18, 2017 12:13 PM
> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> <[email-masked]>; Kent Watsen <[email-masked]>;
> [email-masked]
> Subject: Re: [Netconf] two-week review of drafts related to notifications and
> subscriptions
> 
> Hi Robert,
> 
> > draft-voit-netconf-subscription-and-notif-overview-00 and
> > draft-ietf-netconf- notification-messages.
> >
> > subscription-and-notif- overview or not?  Having an overview document
> > that binds the technologies together could be quite useful (in fact
> > some of the background, and definitions could move to an overview
> > draft, but I think that this intro draft could do with further work before
> going to WG LC.
> 
> I have not been thinking of progressing this overview document into a WG
> draft.  The main reason is that several highly placed members of the IETF
> have expressed that they don't want to see a proliferation of generalized
> architecture context documents.  With Kent's assistance, I have been trying
> to straddle this line.
> 
> There is still a lot of longer-term work which needs to be done on
> notification-messages.  Once the format stabilizes, we will be going through
> each header object to determine its proper articulation.  Objects like
> signature are about to get contributions on this doc.  Items like attestation of
> the contents of the messages (as well as alignment with attestation of
> information returned from a GET) could also take some time.
> 
> And there are short term drivers which suggest we should close on some
> form of yang-push over NETCONF at least.  For example, at the last IETF,
> there was already some inter-vendor work at the Hackathon looking at
> interoperability.  Also there exist several open source implementations of a
> Subscriber client.  My hope is we just close now on that context, and let the
> rest await the availability of notification-messages.
> 
> > Regarding the notification message format itself: I wasn't quite sure
> > if there needs to be a split between a bundled and unbundled message,
> > in that it seems that having a single message format might be easier, e.g.
> (e.g.
> > information, in that it is presumably desirable to keep the streamed
> > messages as compact as possible.  I think that there is probably a bit
> > of the bigger picture that I'm still missing.
> 
> Yes, going to one message can be done.  But as you point out It adds
> overhead especially to smaller high frequency messages.  The other
> complexity with bundled messages is the publisher needs to determine
> exactly what should be placed in each bundle.  This might not seem to be an
> issue, but what if some elements of the bundle need to be signed, and
> others do not.   What should be the behavior?
> 
> In the end, if the IoT guys don't have an issue with efficiency (where this
> seems to matter most), we could collapse to one.  (it is discussions like this
> which need to stew for a while before we can close on notification-
> messages.)
> 
> Eric
> 
> > Thanks,
> > Rob
> >
> >
> > > each

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 16:06:34 +0100

Hi Alex,

> Regarding ordering of the work: IMHO, we shouldn't serialize this work but try to advance subscribed-notifications, yang-push, and netconf-notifications at the same time.  This work was already sta…
OK, serializing the work might be expressing this the wrong way.

If there any possibility that the notification format might impact the 
subscriber or YANG push configuration?  E.g. the encoding of the 
subscription identifier could affect what the associated configuration 
model looks like.

If so, then it feels like spending a couple months with the WG trying to 
nail down the notification format would be a good idea. Then the 
subscription and YANG push drafts could formally depend on the new 
notification format.

> Regarding notifications and notification bundles, I think it is a worthwhile optimization to address individual notifications (vs notification bundles containing just one notification), given that…
I still don't entirely get this :-).

The device is generating an unbounded stream of notifications.  Most of 
the key information related to the notification (such as a timestamp, 
subscription id, msg contents) should be in the notification structure 
itself.  Ideally, you normally want the device to send the notification 
as soon as it can (but other traffic/latency may slow this down).

If the notifications are being sent to a client on something like a 
buffered TCP connection, then I would think that you would just write 
the encoded notification structures directly to the TCP steam.  I.e. 
presumably without any extra message header fields (back to wanting to 
keep the messages small).

Conversely, if the notifications are being sent over something more like 
UDP then I would assume that you may want to pack multiple notifications 
into a single packet, and add extra fields to detect lost notifications.

Thanks,
Rob

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 19 Oct 2017 17:45:53 +0000

Hi Rob, 
Inline, <ALEX>
Thanks!
--- Alex

> From: Robert Wilton [mailto:[email-masked]]
> Sent: Thursday, October 19, 2017 8:07 AM
> To: Alexander Clemm <[email-masked]>; Eric Voit (evoit)
> <[email-masked]>; Kent Watsen <[email-masked]>;
> [email-masked]
> > Regarding ordering of the work: IMHO, we shouldn't serialize this work but
> try to advance subscribed-notifications, yang-push, and netconf-notifications
> at the same time.  This work was already started three years ago with yang-
> push, from where the work was broken out and modularized into the current
> pieces (with some new pieces added, of course), and I think it is really time
> to bring it to a closure .
> subscriber or YANG push configuration?  E.g. the encoding of the subscription
> identifier could affect what the associated configuration model looks like.
> 
> If so, then it feels like spending a couple months with the WG trying to nail
> down the notification format would be a good idea. Then the subscription
> and YANG push drafts could formally depend on the new notification format.
> 

<ALEX> I would rather try to see if we can get them addressed concurrently than to prolong things out further.  The encoding of the subscription identifier is an issue that we can hopefully resolve quickly.  It seems that we are making the most progress when indicating WGLC is imminent and the eyes are on the ball, so let's keep that momentum.  We will issue new revisions of the drafts in response to the comments that were raised now in hope of converging to rough consensus quickly, but that's of course to the WG chairs to decide.    
</ALEX>

> >
> >
> > Regarding notifications and notification bundles, I think it is a worthwhile
> optimization to address individual notifications (vs notification bundles
> containing just one notification), given that the bundle comes with some
> overhead.  But of course you are correct in that the single notification can be
> considered a special case and be addressed just by a notification bundle, and
> ultimately it would be up to servers to decide what to do (if they have only a
> single notification to send).
> The device is generating an unbounded stream of notifications.  Most of the
> key information related to the notification (such as a timestamp, subscription
> id, msg contents) should be in the notification structure itself.  Ideally, you
> normally want the device to send the notification as soon as it can (but other
> traffic/latency may slow this down).
> 
> If the notifications are being sent to a client on something like a buffered TCP
> connection, then I would think that you would just write the encoded
> notification structures directly to the TCP steam.  I.e.
> Conversely, if the notifications are being sent over something more like UDP
> then I would assume that you may want to pack multiple notifications into a
> single packet, and add extra fields to detect lost notifications.

<ALEX> This is good feedback.  Clearly, in general you want to send notifications without introducing delay - which argues in favor of having single notifications which are perhaps the most common case that we should design for.  Having a single notification is thus not an optimization - it is the normal case we should design for; the notification bundle merely becomes a special case for the scenario in which multiple notifications are sent at the same time.  To me, this seems to confirm that we need to make the distinction between the bundle and the individual message, and not just merely treat individual messages as bundles of size 1 - would you agree?  For notification bundles, one scenario we had in mind was the case in which a client would maintain multiple subscriptions to the same device/server, each potentially with the same reporting periods.   Yes, since we are not making assumptions about the transport, there is a field are intended to help detect lost notifications as a robustness measure, namely the "previous-message-id" field. 
</ALEX> 
...