Subject: [Netconf] mbj's WGLC comments on subscribed-notifications-10

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Mar 2018 10:11:46 +0100 (CET)

Hi,

Here are my WGLC comments on
draft-ietf-netconf-subscribed-notifications-10.

In general, I think ths document has improved a lot, it is now easier
to follow.

Major issue
-----------

o  list receiver

   In the YANG model, the "receiver" list is indexed by ip and port.

   How is the server supposed to use this simple list of ip/port?

   We get a hint from the document in 2.5.2:

     transport specific
     call-home operations will be used to establish the connection

   But it is not clear that this list of ip/port helps.  The document
   draft-ietf-netconf-netconf-client-server provides configuration for
   call home for NETCONF.  In that document, the receiver is
   identified with a "netconf-client" name and an "endpoint" name, not
   ip/port. (draft-ietf-netconf-restconf-client-server has a similar
   structure for RESTCONF).

   The best solution would have been to have leafrefs to these
   datamodels, but if we do that now, it would introduce a delay b/c
   of the dependency.

   The second best solution (I think) is to change this list to have
   just a "name" as the single key, and nothing else, and write that
   transport-specific modules can add to this in the future.

   Once the client-server docs are ready, we need to revise some
   document to add the leafrefs in this list.

   See also below about my comments about transport identities.  I
   think we should introduce a YANG module in both the
   transport-specific documents, that would define the transport
   identity, and augment the receiever list with the appropriate
   leafrefs to call home.

Other issues
------------

o  Section 1

  Somewhere in section 1 you should add:

    Tree diagrams used in this document follow the notation defined in
    [I-D.ietf-netmod-yang-tree-diagrams].

  and add the reference.

o  Section 1.4

  Should this section explain that this document is intended to be
  transport independent, whereas RFC 5277 was for NETCONF only?

o  Section 1.4

  You write:

   o  the data model in this document replaces the data model in
      [RFC5277].

  Does this mean that in an implementation that supports both 5277 and
  this new document, the set of streams in the two data models are
  guaranteed to be equal?

  I would assume that an implementation should be allowed to keep the
  5277 stuff as-is, and just add future streams to this new mechanism.

o  Section 1.4

  I suggest you make the text a bit more explicit:

  OLD:

   o  the RPC operations in this draft replaces the symmetrical
      operations of [RFC5277], section 4.

  NEW:

   o  the RPC operations in this draft replaces the operation
      "create-subscription" defined in [RFC5277], section 4.

o  Section 1.4

  I know that RFC 5277 uses the term "one-way operation" in a comment
  (but also the term "one-way message").  However, I suggest we align
  with the terminology of RFC 6241, and also make the text more
  explicit:

  OLD:

   o  the one way operation of [RFC5277] is still used.  However this
      operation will no longer be required with the availability of
      [I.D.draft-ietf-netconf-notification-messages].

  NEW:

   o  the <notification> message defined in [RFC5277] is still used.
      However this message will no longer be required with the
      availability of [I.D.draft-ietf-netconf-notification-messages].

o  Section 1.4

  (editorial; quote the name of the stream)

  OLD:

   o  the definition and contents of the NETCONF stream are identical
      between this document and [RFC5277].

  NEW:

   o  the definition and contents of the "NETCONF" stream are identical
      between this document and [RFC5277].

o  Section 1.4

  You write:

   o  a publisher MAY implement both the data model and RPCs defined in
      [RFC5277] and this new document concurrently, in order to support
      old clients.  However the use of both alternatives on a single
      transport session is prohibited.

  What exactly does the last sentence mean?  And why do you have this
  restriction?   This is just the Introduction, but I can't find any
  details about this restriction in the rest of the document.  I
  suggest you remove this last sentence.  If not, you should work out
  the details later in the doc, and add a reference to that new new
  text in section 1.4.

o  Section 2.1

  (editorial; quote the name of the stream)

  OLD:

   There is only one reserved event stream within this document:
   NETCONF.  The NETCONF event stream contains all NETCONF XML event
   record information supported by the publisher, except for where it
   has been explicitly indicated that this the event record MUST be
   excluded from the NETCONF stream.  The NETCONF stream will include
   individual YANG notifications as per [RFC7950] section 7.16.  Each of
   these YANG notifications will be treated a distinct event record.
   Beyond the NETCONF stream, implementations are free to add additional
   event streams.

  NEW:

   There is only one reserved event stream within this document:
   "NETCONF".  The "NETCONF" event stream contains all NETCONF XML event
   record information supported by the publisher, except for where it
   has been explicitly indicated that this the event record MUST be
   excluded from the "NETCONF" stream.  The "NETCONF" stream will include
   individual YANG notifications as per [RFC7950] section 7.16.  Each of
   these YANG notifications will be treated a distinct event record.
   Beyond the "NETCONF" stream, implementations are free to add additional
   event streams.

o  Section 2.3

  I think it would be useful to have "dscp" covered by a separate
  feature than "dependency" and "weighting".  The former is quite
  simple to implement, but the latter seems to require a very separate
  implementation; thus I think there should be two separate features.

  Also, you write that dependency MUST work identically to 7540, but
  7540 defines an "exclusive dependency" that is not covered here.
  Maybe it is worth mentioning that this is excluded.

o  Section 2.4.1

  Be explicit:

  OLD:

   o  Successful establish or modify RPCs put the subscription into an
      active state.

   o  Failed modify RPCs will leave the subscription in its previous
      state, with no visible change to any streaming updates.

   o  A delete or kill RPC will end the subscription.

  NEW:

   o  Successful "establish-subscription" or "modify-subscription" RPCs
      put the subscription into the "active" state.

   o  Failed "modify-subscription" RPCs will leave the subscription in
      its previous state, with no visible change to any streaming
      updates.

   o  A "delete-subscription" or "kill-subscription" RPC will end the
      subscription.

o  Section 2.4.2

  (editorial; you have a name for the "via RPC"-subscribtions; use
  that name)

  OLD:

   The "establish-subscription" operation allows a subscriber to request
   the creation of a subscription via RPC.

  NEW:

   The "establish-subscription" operation allows a subscriber to request
   the creation of a dynamic subscription.

o  Section 2.4.2

  You write:

   It MUST be possible to
   support multiple establish subscription RPC requests made within the
   same transport session.

  I think you mean:

   A server MUST support multiple "establish-subscription" requests
   made within the same transport session.

o  Section 2.4.2

  You write:

   And it MUST be possible to support the
   interleaving of RPC requests made on independent subscriptions.

  I think you mean:

   Additionally, a server MUST support interleaving of RPC requests
   with outgoing notification messages.

o  Section 2.4.2

  (clarification)

  OLD:

   If the publisher can satisfy the "establish-subscription" request, it
   provides an identifier for the subscription, and immediately starts
   streaming notification messages.

  NEW:

   If the publisher can satisfy the "establish-subscription" request,
   it replies with an identifier for the subscription, and then
   immediately starts streaming notification messages.

o  Section 2.4.2.1

  This is something I have commented on before (see the thread
  "Martin's thoughts on subscribed-notifications" from October 2017).
  I think there is one small change left to do:

  OLD:

   If a "stop-time" parameter is included, it MAY also be earlier than
   the current time and MUST be later than the "replay-start-time".  The
   publisher MUST NOT accept a "replay-start-time" for a future time.

   If the "replay-start-time" is later than any information stored in
   the replay buffer, then the publisher MUST send a "replay-completed"
   notification immediately after the "subscription-started"
   notification.

  NEW:

   If a "stop-time" parameter is included, it MAY also be earlier than
   the current time and MUST be later than the "replay-start-time".

   If the "replay-start-time" is later than any information stored in
   the replay buffer, then the publisher MUST send a "replay-completed"
   notification immediately after the "subscription-started"
   notification.

o  Section 2.4.2.1

  (editorial clarification)

  OLD:

   To assess the availability of replay, subscribers can
   perform a get on "replay-log-creation-time" and "replay-log-aged-
   time".

  NEW:

   To assess the availability of replay, subscribers can
   read the leafs "replay-log-creation-time" and
   "replay-log-aged-time".

o  Section 2.4.3

  ("via RPC" again)

  OLD:

   Dynamic subscriptions established via RPC can only be modified via
   RPC using the same transport session used to establish that
   subscription.

  NEW:

   Dynamic subscriptions can only be modified
   using the same transport session used to establish that
   subscription.

o  Section 2.4.3

  (there is just *one* active state (I assume))

  OLD:

   (i.e., the modified subscription is returned to an active state.)

  NEW:

   (i.e., the modified subscription is returned to the "active"
   state.)

o  Section 2.4.5

  (fix typo)

  OLD:

   by searching for the IP address of a receiver within
   "subscriptions\subscription\receivers\receiver\address".

  NEW:

   by searching for the IP address of a receiver within
   "/subscriptions/subscription/receivers/receiver/address".

o  Section 2.4.6

  OLD:

   1.  yang-data establish-subscription-error-stream: This MUST be

   NEW:

   1.  "establish-subscription-error-stream": This MUST be

   And same for the other two.

   Also, I suggest you change the name to
   "establish-subscription-error".

o  Section 2.5.1

  (explicitily name the states)

  OLD:

   subscription may also transition to a concluded state if a configured

  NEW:

   subscription may also transition to the "concluded" state if a configured

  OLD:

   subscription, and is only relevant when the configured subscription
   itself is determined to be valid.

  NEW:

   subscription, and is only relevant when the configured subscription
   itself is in the "valid" state.

  OLD:

   When a subscription first becomes valid, the operational state of
   each receiver is initialized to connecting.  Individual receivers are
   moved to an active state when a "subscription-started" state change
   notification is successfully passed to that receiver.  Configured
   receivers remain active if transport connectivity is not lost, and
   event records are not being dropped due to a publisher buffer
   overflow.  A configured subscription's receiver MUST be moved to
   connecting if transport connectivity is lost, or if the receiver is
   reset via configuration operations.

  NEW:

   When a subscription first becomes valid, the "state" leaf of
   each receiver is initialized to "connecting".  Individual receivers are
   moved to the "active" state when a "subscription-started" state change
   notification is successfully passed to that receiver.  Configured
   receivers remain active if transport connectivity is not lost, and
   event records are not being dropped due to a publisher buffer
   overflow.  A configured subscription's receiver MUST be moved to the
   "connecting" state if transport connectivity is lost, or if the receiver is
   reset via configuration operations.

  OLD:

   A configured subscription's receiver MUST be moved to a suspended
   state if there is transport connectivity between the publisher and
   receiver, but notification messages are not being generated for that
   receiver.  A configured subscription receiver MUST be returned to an
   active state from the suspended state when notification messages are
   again being generated and a receiver has successfully been sent a
   "subscription-resumed" or a "subscription-modified".

  NEW:

   A configured subscription's receiver MUST be moved to the "suspended"
   state if there is transport connectivity between the publisher and
   receiver, but notification messages are not being generated for that
   receiver.  A configured subscription receiver MUST be returned to the
   "active" state from the "suspended" state when notification messages are
   again being generated and a receiver has successfully been sent a
   "subscription-resumed" or a "subscription-modified" notification.

o  Section 2.5.1

  You write:

   A configured subscription's receiver MUST be moved to
   connecting if transport connectivity is lost, or if the receiver is
   reset via configuration operations.

  What does "reset via configuration operations" mean?  I see an
  action called "reset", is that involved here?

o  Section 2.5.1

  You write:

   Suspended receivers will also be
   informed of the modification.  However this notification will await
   the end of the suspension for that receiver.

  What does the last sentence mean here?  Maybe instead write

   Suspended receivers will also be
   informed of the modification.  See Section 2.5.3 for details.

o  Section 2.5.1

  OLD:

   [I-D.ietf-netconf-yang-push] provides an example of such an
   extension.

  NEW:

   [I-D.ietf-netconf-yang-push] provides a definition of such an
   extension.

  (it is not just an example...)

o  Section 2.5.3

  If a suspended receiver exists, and the subscription is modified
  several times, does the server have to buffer all
  "subscription-modified" notifs?  I think this behavior should be
  clarified.

o  Section 2.5.5

  Add text that explains that the "reset" action is used for this.

o  Section 2.6

  ("via RPC" again)

  OLD:

   For dynamic subscriptions set up via RPC
   operations, notification messages are sent over the session used to
   establish the subscription.

  NEW:

   For dynamic subscriptions, notification messages are sent over the
   session used to establish the subscription.

o  Section 2.6

  I can't parse this:

   A subscription's events MUST NOT be sent to a receiver
   until after a corresponding RPC response or state-change notification
   has been passed receiver indicating that events should be expected.

  Maybe you mean:

   A subscription's events MUST NOT be sent to a receiver unless the
   receiver is in the "active" state.

o  Section 2.6

  OLD:

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

  NEW:

   This notification
   message MUST be encoded in a <notification> message as defined in [RFC5277],
   Section 4.

  OLD:

   This [RFC5277] section 4 one-way operation has the drawback of not
   including useful header information such as a subscription
   identifier.

  NEW:

   The <notification> message defined in [RFC5277] section 4 has the
   drawback of not including useful header information such as a
   subscription identifier.

o  Section 2.7

  Perhaps write that the subscription state notifications are not
  stored in replay buffers.

o  Section 2.7.1

  The diagram doesn't quite fit.  Using the latest pyang like this:

    $ pyang -f tree [email-masked] \
      --tree-line-length 69 --tree-path /subscription-started

  gives you a tree that fits.

  In general, I think you should re-generate all tree diagrams in the
  document, for example by using the latest pyang from github, so that
  they match the I-D.ietf-netmod-yang-tree-diagrams.

  The RFC editor tries to check that the tree output is correct, so
  fixing this before sending the doc to the RFC editor helps.

o  Section 2.7.2

  (clarififcation)

  OLD:

      A "subscription-modified" state
      change notifications MUST be sent if the contents of a filter
      identified by a "stream-filter-ref" has changed.

  NEW:

      A "subscription-modified" state change notification MUST be sent
      if the contents of the filter identified by the subscription's
      "stream-filter-ref" leaf has changed.

o  Section 2.7.4

  You write:

   The
   two conditions where is this possible are "insufficient-resources"
   and "unsupportable-volume".

  What exactly is the difference between these two?  If I can't handle
  the volume I probably have insufficient resources?

o  Section 2.8

  ("by RPC" again)

  OLD:

   Subscriptions that were established by RPC are removed from the list
   once they expire (reaching stop-time) or when they are terminated.
   Subscriptions that were established by configuration need to be
   deleted from the configuration by a configuration editing operation
   even if the stop time has been passed.

  NEW:

   Dynamic subscriptions are removed from the list
   once they expire (reaching stop-time) or when they are terminated.
   Configured subscriptions need to be
   deleted from the configuration by a configuration editing operation
   even if the stop time has been passed.

o  Section 4

  The module's description should contain the usual IETF boilerplate
  text.

o  subscription-terminated-reason

      "Problem condition communicated to a receiver as part of absolute
      'subscription-terminated' notification. ";

  What does the word "absolute" tell me?  Can it be removed?

  (same for subscription-suspended-reason)

o  identity encodings

  Shouldn't this be "encoding"?  It is just one singluar encoding,
  right?

o  identity encode-xml

   Add "as described in RFC 7950."

   and add a reference statement

o  identity encode-json

   Add "as described in RFC 7951."

   and add a reference statement

o  For the transport identities, add RFC editor notes to replace the
   draft strings.

   For the http1.1 and http2 transport, you have listed these docs as
   "informative refererences".  I understand this; otherwise it would
   have been a downref, but it is really correct?   An alternative
   would be to specify the transport-specific identities in the
   transport-specific documents.

o  typedef stream-ref

    description
      "This type is used to reference a system-provided datastream.";

    What is a "datastream"?   This word occur twice in the document,
    w/o further explanation.

o    typedef stream-filter-ref {

  OLD:

      "This type is used to reference a configured stream filter.";

  NEW:

      "This type is used to reference a stream filter.";

o  list stream-filter

   What happens if no filter-spec has been defined?
   Should the choice filter-spec be mandatory?

o  leaf protocol / encoding

   Why is "protocol" only for the feature "configured", but "encoding"
   is not?

o  For all rpcs:

   In order to make it clear to implementors what to do in the case of
   errors, add a paragraph to the description:

     If an error occurs, the server replies with an 'rpc-error' where
     the 'error-info' field MAY contain an instantation of the
     'establish-subscription-error' structure.

o  The YANG module is inconsistently idented.  To get some help, you
   can use the latest version of pyang on github and run:

     $ pyang -f yang --keep-comments \
         [email-masked]  > x
     $ diff [email-masked] x

o  Terminology issue.

  I have reported this one before.  You use the terms "transport",
  "protocol", and "transport protocol" for the same thing.  I suggest
  you pick one.

  For example, the leaf "protocol" has type "transport".

  I think that the term "protocol" is supposed to mean a management
  protocol for YANG data, such as NETCONF or RESTCONF.

  NETCONF can use two different transports, SSH and TLS.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Mar 2018 13:33:03 +0100 (CET)

Hi,

While reviewing the other drafts, I found another bug in this
document.  The "establish-subscription" rpc is supposed to return the
subscription id in the reply, but the rpc doesn't have any output
defined in the YANG model (interestingly, it is present in the tree
diagram).

/martin

Martin Bjorklund <[email-masked]> wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 16 Mar 2018 13:16:30 +0000

> Martin Bjorklund, March 16, 2018 8:33 AM
>
> Hi,
> 
> While reviewing the other drafts, I found another bug in this document.  The
> "establish-subscription" rpc is supposed to return the subscription id in the
> reply, but the rpc doesn't have any output defined in the YANG model
> (interestingly, it is present in the tree diagram).

Sigh.  I need find better tooling.  I have too much manual stuff right now.   Perhaps someone has documented / is maintaining a continuous integration environment somewhere?   

This particular issue is fixed.  The YANG file if you want it for testing is at
https://github.com/netconf-wg/rfc5277bis/blob/master/ietf-subscribed-notifications%402018-03-16.yang 

Look for responses to your other comments later today.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Mar 2018 14:29:39 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > document.  The
> Sigh.  I need find better tooling.  I have too much manual stuff right
> now.  Perhaps someone has documented / is maintaining a continuous
> integration environment somewhere?

See for example
https://github.com/netmod-wg/rfc7277bis/blob/master/Makefile

The idea is to (i) have all examples in separate files and (ii) use
yang2dsdl to validate them.  Sometimes some scripting needs to be
done; for example I use a awk script (in the repo) to split the xml
into short lines appropriate for the RFC format.

These are just quick hacks to get something that works, I'm sure it
can be done in a better way.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sun, 18 Mar 2018 19:29:11 +0000

Hi Martin,

Thanks very much for the comments.  Thoughts are in line.  Also a few key areas marked with "****"

Note that changes shown below are also included in this working version
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-11.txt

> Martin Bjorklund, March 15, 2018 5:12 AM
> 
> Hi,
> 
> In general, I think ths document has improved a lot, it is now easier to follow.
> 
> 
> 
> Major issue
> -----------
> 
> o  list receiver
> 
>    But it is not clear that this list of ip/port helps. 

Actually, the address is of type Host.  Of course for everyone must eventually resolve to an IP address to make a connection.   

However what I think what you are ultimately trying to do is make sure the choice of index doesn't preclude future mechanisms for referencing receivers beyond address+Port.  And this likely is a good idea.

>    The document

Yes, having alternative, indirect ways of *ultimately* getting to IP address + port would help flexibility.

>    transport-specific modules can add to this in the future.

I am fine with name as a single key.  However "nothing else" injects a few problems:

(1) our traffic counters are transport agnostic.  Displacing them to a transport draft reduces utility.

(2) forcing the acquisition of host or ip address only from the transport draft creates unnecessary complexity for people who are able to simply configure host+Port, should it be available in that form already?  So why not simply leave those in as a transport agnostic option of last resort should it be available to populate?

**** A reasonable approach seems to be:

(a) add "name" as integer under receivers.  Make this the index.
(b) leave address + port as optional objects
(c) note that future augmentations mechanisms for identifying receivers are encouraged.
 
I will put this question up in front of the WG during the Tuesday session to get more feedback.

>    identity, and augment the receiever list with the appropriate

I have no problem with new modules for transport being identified.   I don't think they are needed yet.   My suggestion would be to introduce a new module and augment the receiver list will the leafrefs to call home once those drafts make it through WGLC.  Otherwise we create a dependency per above.

> Other issues

Done

>   transport independent, whereas RFC 5277 was for NETCONF only?

Added a bullet:

this document defines a transport independent capability, [RFC5277] is specific to NETCONF.

>   this new document, the set of streams in the two data models are

No

>   5277 stuff as-is, and just add future streams to this new mechanism.

I have updated the text to say:

the data model in this document provides an alternative structure the Notification Management Schema of [RFC5277], Section 3.4.

>       "create-subscription" defined in [RFC5277], section 4.

Changed.

>       availability of [I.D.draft-ietf-netconf-notification-messages].

Changed

>       between this document and [RFC5277].

Changed.

>   the details later in the doc, and add a reference to that new new

All this was trying to saying is that you can't use this specification and RFC-5277's create-subscription on the same NETCONF transport session.

So what I did was to remove the last sentence.   And then I added the point above into a new section 6.3 in the draft-ietf-netconf-netconf-event-notifications draft.  This section is titled "Concurrent Support of NETCONF Subscription specifications", and has a single sentence: "A single NETCONF transport session MUST NOT support both this specification and a subscription established by [RFC5277]'s "create-subscription" RPC."

>    Beyond the "NETCONF" stream, implementations are free to add additional

Done
 
>   implementation; thus I think there should be two separate features.

****
Dscp should be easy enough to build, why don't we make it part of the base specification?    I can make that a question for the WG on Tuesday.  I am happy with whatever answer is chosen.

>   Maybe it is worth mentioning that this is excluded.

****
Based on Kent's comments, the normative relationship to 7540 as been eliminated.  In fact, the non-normative text should likely be removed as well.   The text has been simplified to now read:

Dequeuing of notification messages across independent subscriptions to a receiver SHOULD be allocated bandwidth proportionally based on each subscription's weight.

and

If a subscription has a dependency, then any buffered notification messages containing event records selected by the parent subscription SHOULD be dequeued prior to the notification messages of the dependent subscription.  If notification messages have dependencies on each other, the notification message queued the longest MUST go first. If a dependency included within an RPC references a subscription which does not exist or is no longer visible to that subscriber, that dependency may be silently removed.

Based on that, "exclusive dependency" is fully out of scope.

Does this work for you?

>    o  A "delete-subscription" or "kill-subscription" RPC will end the

Done.

>    the creation of a dynamic subscription.

Done

>    made within the same transport session.

Agree.  With Kent's comments also integrated, the text now says:

The transport selected by the subscriber to reach the publisher MUST be able to support multiple "establish-subscription" requests made within the same transport session. 

>    with outgoing notification messages.

This is true.  But the ultimate point is also about the pipelining of RPC requests as well.    There are good reasons (like speed to establishment after a reboot, and reducing the number of transport sessions) to require pipeline support for subscriptions.   So the updated text currently says:

The transport session MUST support the pipelining of RPC requests made on independent subscriptions.

Is this good with you?

>    immediately starts streaming notification messages.

Kent made a similar comment.  Now it says:

If the publisher can satisfy the "establish-subscription" request, it replies with an identifier for the subscription, and immediately starts streaming notification messages.

>    notification immediately after the "subscription-started"

Done

>    read the leafs "replay-log-creation-time" and

Updated

>    using the same transport session used to establish that

Updated

>    (i.e., the modified subscription is returned to the "active"

Done

>    "/subscriptions/subscription/receivers/receiver/address".

Done

>    1.  "establish-subscription-error-stream": This MUST be

Done

>    And same for the other two.

Yes
 
>    "establish-subscription-error".

****
I cannot do that as there is a different structure which is provided when hints are being returned for a datastore subscription.
 
>    subscription may also transition to the "concluded" state if a configured

Per comments from Kent and others, Transitioned all states to UPPERCASE across the two diagrams and associated text within the document for consistency.   E.g., this text now reads:

A VALID subscription may become INVALID on one of two ways.  First, it may be modified in a way which fails a re-evaluation.  See (1) in the diagram. Second, the publisher itself might determine that the subscription is no longer supportable.  See (2) in the diagram.  In either case, a "subscription-terminated" notification is sent to any active or suspended receivers.  A VALID subscription may also transition to a CONCLUDED state via (4) if a configured stop time has been reached.  In this case, a "subscription-concluded" is sent to any ACTIVE or SUSPENDED receivers.  Finally, a subscription may be deleted by configuration (3).

>    itself is in the "valid" state.

Ok.  Consistent with above it says 

...itself is in the VALID state.

>    reset via configuration operations.

Made the change:

When a subscription first becomes VALID, the operational state of each receiver is initialized to CONNECTING.  If transport connectivity is not available to any receiver, a transport session is established (e.g., through [RFC8071]). Individual receivers are moved to an ACTIVE state when a "subscription-started" state change notification is successfully passed to that receiver (1). Configured receivers remain ACTIVE if both transport connectivity can be verified to the receiver, and event records are not being dropped due to a publisher buffer overflow. The result is that a receiver will remain ACTIVE on the publisher as long as events aren't being lost, or the receiver cannot be reached.  However if there is buffer overflow, or the publisher cannot generate events for a receiver, the receiver MUST be moved to SUSPENDED (2).  In addition, a configured subscription's receiver MUST be moved to CONNECTING if transport connectivity cannot be achieved, or if the receiver is reset via configuration (3).

>    "subscription-resumed" or a "subscription-modified" notification.

Now:

A configured subscription's receiver MUST be moved to a SUSPENDED state if there is transport connectivity between the publisher and receiver, but notification messages are not able to be generated for that receiver.  A configured subscription receiver MUST be returned to an ACTIVE state from the SUSPENDED state...

>   action called "reset", is that involved here?

Yes.
Based on Kent's comments, a reset section now exists later in this section.   

<section title="Resetting a Configured Receiver" anchor="reset">
It is possible that a configured subscription to a receiver needs to be reset.  This is accomplished via the "reset" action within the YANG model at "/subscriptions/subscription/receivers/receiver/reset". This re-initialization may be useful in cases where a publisher has timed out trying to reach a receiver. When such a reset occurs, a transport session will be initiated if necessary, and a new "subscription-started" notification will be sent.
</section>

I placed a reference to that new section in 2.5.1:

For more on reset, see <xref target="reset"/>.

>    informed of the modification.  See Section 2.5.3 for details.

Based on comments with Kent, all comments on suspended subscriptions are out of 2.5.1.   And the necessary text does still exist in 2.5.3.

>    [I-D.ietf-netconf-yang-push] provides a definition of such an

After Kent's comments, now says:

The YANG model of [I-D.ietf-netconf-yang-push] Section 4.1 provides many such extensions; this includes the augmentation of "/modify-subscription/input/target".
 
>   "subscription-modified" notifs?  I think this behavior should be

Since all subscription parameters are included in the notification, it is not necessary to buffer anything but the last modification.  Added the last sentence in the note below:

(Note: in this case, the "subscription-modified" notification informs the receiver that the subscription has been resumed, so no additional "subscription-resumed" need be sent.  Also note that if multiple modifications have occurred during the suspension, only the latest one need be sent to the receiver.)

>   Add text that explains that the "reset" action is used for this.

There is a new section added for this.   The text is:

2.5.5.  Resetting a Configured Receiver

   It is possible that a configured subscription to a receiver needs to
   be reset.  This is accomplished via the "reset" action within the
   YANG model at "/subscriptions/subscription/receivers/receiver/reset".
   This re-initialization may be useful in cases where a publisher has
   timed out trying to reach a receiver.  When such a reset occurs, a
   transport session will be initiated if necessary, and a new
   "subscription-started" notification will be sent.

	)
>    session used to establish the subscription.

Done

>    receiver is in the "active" state.

****
Based on Kent's comments, this is now:

   A subscription's events MUST NOT be sent to a receiver
   until after a corresponding RPC response (in the case of a dynamic
   subscription) or state-change notification (in the case of a
   configured subscription) has been passed receiver indicating that
   events should be expected.

Does this work for you?

>    message MUST be encoded in a <notification> message as defined in

Done

>    drawback of not including useful header information such as a

Kent has asked that this text be removed for now, as he believes this might impact IESG reviews.   So this and the notification-messages draft reference text has been removed.

>   stored in replay buffers.

Now says:

Subscription state notifications cannot be filtered out, they cannot be stored in replay buffers, and they are delivered only to impacted receiver(s) of a subscription.

>   gives you a tree that fits.

Very happy to use this tool.  I just ran Tree line length, and it is especially helpful with the model from yang-push (which I was manually fixing).

>   they match the I-D.ietf-netmod-yang-tree-diagrams.

Will do.  Will do after working through the YANG doctor comments.

>   fixing this before sending the doc to the RFC editor helps.

Ack.  Will refresh everything as needed after I get through the yang doctor review.  And move to a mechanized tool set for the next drafts!

>       "stream-filter-ref" leaf has changed.

Done

>   the volume I probably have insufficient resources?

I updated the text to:

The two conditions where is this possible are:
 1. "insufficient-resources" when a publisher is unable to produce the requested stream of notification messages, and
 2. "unsupportable-volume" when the bandwidth needed to get generated notification messages to a receiver exceeds a threshold. 

This additional feedback / differentiation is useful as a subscriber prepares for another attempt at subscription.

I have also tweaked the definitions of the identities to better support this.

>    even if the stop time has been passed.

Done

>   The module's description should contain the usual IETF boilerplate

I think I got the additions.    You will see this as part of the YANG doctor review response

>   What does the word "absolute" tell me?  Can it be removed?

Removed

>   (same for subscription-suspended-reason)

Removed

>   Shouldn't this be "encoding"?  It is just one singluar encoding,

Yes.  Fixed.

>    and add a reference statement

Done

>    and add a reference statement

Done

>    transport-specific documents.

****

Having a YANG module for a transport identity seems like overkill.  Plus with things like CBOR, UDP, etc. coming, replicating model names for this seems excessive.   It would be great to leave as is.   I of course will respect whatever IETF process requires. 

>     What is a "datastream"?   This word occur twice in the document,

Renamed to stream

>       "This type is used to reference a stream filter.";

Done

>    Should the choice filter-spec be mandatory?

It is ok to do this.   You just get all the events on a stream.

In Section 2.2 it says:
   If no stream filter is provided within a subscription, all event
   records on a stream are to be sent.

>    Why is "protocol" only for the feature "configured", but "encoding"

****

There have been requests for an establish-subscription RPC to request an alternative encoding (e.g., binary with CBOR).    Since there are lots of instances for which this is possible, trying not to exclude it.

>      'establish-subscription-error' structure.

****
I did this for delete and kill RPCs.

There is already text for establish and modify subscription RPCs.  But it cannot be boilerplate, referring just to this yang-data within this yang module.  The reasoning here is that we need to have different yang-data structures for different targets (datastore vs stream).  This is due to different hints.

>      $ diff [email-masked] x

Will do.  Awaiting YANG doctor change before doing the re-insertion.

>   "protocol", and "transport protocol" for the same thing.  I suggest

Everything now uses "transport".

>   NETCONF can use two different transports, SSH and TLS.

Thanks again for the detailed review!

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Mar 2018 19:13:46 +0000 (GMT)

Hi,

[pruning to open issues]

"Eric Voit (evoit)" <[email-masked]> wrote:
> Actually, the address is of type Host.  Of course for everyone must
> eventually resolve to an IP address to make a connection.
> 
> However what I think what you are ultimately trying to do is make sure
> the choice of index doesn't preclude future mechanisms for referencing
> receivers beyond address+Port.  And this likely is a good idea.
> 
> >    The document

Yes; my mistake, I didn't mean to exclude the counters / state /
action.  Just host/port.

> (2) forcing the acquisition of host or ip address only from the
> transport draft creates unnecessary complexity for people who are able
> to simply configure host+Port, should it be available in that form
> already?  So why not simply leave those in as a transport agnostic
> option of last resort should it be available to populate?

I think it is a bad idea to include open-ended objects just b/c "maybe
someone would like to use them for something".  For interoperability,
it is important that all objects we define have clear semantics, and
that it clear how to use them.

In this case, none of the standard transports will need these nodes
(unless the client-server models are severly changed).  If someone
defines a transport in the future that needs these objects, it is
trivial to do, and it will be done in a more robust way.

This said, if the WG strongly believes that these nodes are important,
here's a design that might work:

  identity inline-address {
    description
      "A transport identity can derive from this identity in order
       to allow inline definition of the host address in the
       'receiver' list";
    }
  }

  ...

  leaf address {
    when 'derived-from(../../../transport, "sn:inline-address")';
    ...
  }

The you can define your transport like this:

  identity my-udp-based-transport {
    base sn:transport;
    base sn:inline-address;
  }

I would prefer to simply leave this out though.
    
> (a) add "name" as integer under receivers.  Make this the index.

Yes, but as a string.

> (b) leave address + port as optional objects

See above.

> receivers are encouraged.

Yes, I think it is important to explain what the intention is.  I
suggest you include an example for how to do this.

> I have no problem with new modules for transport being identified.  I
> don't think they are needed yet.

If new modules just define the identity now, they will be updated to
include receiver-specific parameters later, right?  And we have a
place to add more transport-specific params in the future.  See below.

> My suggestion would be to introduce
> a new module and augment the receiver list will the leafrefs to call
> home once those drafts make it through WGLC.  Otherwise we create a
> dependency per above.

Yes, I think that's what I suggested as well.

[...]

> the data model in this document provides an alternative structure the
> Notification Management Schema of [RFC5277], Section 3.4.

I don't think this is quite right.  If this is an alternative, does it
mean that I can use this with <create-subscription etc from 5277,
instead of using the structure in 5277?  I don't think this is the
intention. 

Maybe say:

   o  the RPC operations in this draft are intended to replace
      the operation "create-subscription" defined in [RFC5277],
      section 4.

   o  the data model in this document is used instead of the data model
      in [RFC5277] for the new operations.

... or something along those lines.

[...]

> All this was trying to saying is that you can't use this specification
> and RFC-5277's create-subscription on the same NETCONF transport
> session.
> 
> So what I did was to remove the last sentence.  And then I added the
> point above into a new section 6.3 in the
> draft-ietf-netconf-netconf-event-notifications draft.  This section is
> titled "Concurrent Support of NETCONF Subscription specifications",
> and has a single sentence: "A single NETCONF transport session MUST
> NOT support both this specification and a subscription established by
> [RFC5277]'s "create-subscription" RPC."

"MUST NOT support this specification" doesn't sound quite right.  I
think what you mean is that an attempt to request a
"establish-sublish-subscription" must fail, if there's an active
subscription started by "create-subscription", and vice versa.

> Dscp should be easy enough to build, why don't we make it part of the
> base specification?  I can make that a question for the WG on Tuesday.
> I am happy with whatever answer is chosen.

It might be safest to have two separate features.  My main point is to
not bundle them into the same feature though.

> Based on Kent's comments, the normative relationship to 7540 as been
> eliminated.  In fact, the non-normative text should likely be removed
> as well.  The text has been simplified to now read:
> 
> Dequeuing of notification messages across independent subscriptions to
> a receiver SHOULD be allocated bandwidth proportionally based on each
> subscription's weight.

I don't understad this.  How can different subscriptions to the same
reciever on the same transport session be allocated different bandwidth?

> If a subscription has a dependency, then any buffered notification
> messages containing event records selected by the parent subscription
> SHOULD be dequeued prior to the notification messages of the dependent
> subscription.  If notification messages have dependencies on each
> other, the notification message queued the longest MUST go first.

Why is the first one a SHOULD but the second a MUST?

> If a
> dependency included within an RPC references a subscription which does
> not exist or is no longer visible to that subscriber, that dependency
                            ^^^^^^^
accessible?

> may be silently removed.
  ^^^^^^

is?

> Based on that, "exclusive dependency" is fully out of scope.

In the sense that I think I know how to implement it - yes.  But I
wonder if this added complexity is necessary, or if we should leave it
out.

[...]

> The transport selected by the subscriber to reach the publisher MUST
> be able to support multiple "establish-subscription" requests made
> within the same transport session.

Ok.  But I wonder if this really is a requirement of the base
mechanism, or if it should be moved to the transport-specific
documents instead.  For example, how is this supposed to work on
non-session based transports?

> This is true.  But the ultimate point is also about the pipelining of
> RPC requests as well.  There are good reasons (like speed to
> establishment after a reboot, and reducing the number of transport
> sessions) to require pipeline support for subscriptions.  So the
> updated text currently says:
> 

First of all, I don't understand what an "RPC on a subscription"
means.

Secondly, I think that this should also be done in the transport
document.  For NETCONF, it is not needed, since 6241 already requires
pipelining.

> replies with an identifier for the subscription, and immediately
> starts streaming notification messages.

I still think you need "and *then* starts ...".  Otherwise it seems it
could be ok to send a notif on this new subscription before sending
the reply.

> I cannot do that as there is a different structure which is provided
> when hints are being returned for a datastore subscription.

Ok.  You also presented this in the session in London.

I suggest you use:

  establish-subscription-stream-error-info
  establish-subscription-datastore-error-info

etc.

> Per comments from Kent and others, Transitioned all states to
> UPPERCASE across the two diagrams and associated text within the
> document for consistency.  E.g., this text now reads:
> 
> A VALID subscription may become INVALID on one of two ways.  First, it

Shouldn't this be:

  A subscription in the VALID state may transition to the INVALID
  state in on of two ways ...

etc, since VALID is the name of a state.

> may be modified in a way which fails a re-evaluation.  See (1) in the
> diagram. Second, the publisher itself might determine that the
> subscription is no longer supportable.  See (2) in the diagram.  In
> either case, a "subscription-terminated" notification is sent to any
> active or suspended receivers.  A VALID subscription may also
> transition to a CONCLUDED state via (4) if a configured stop time has
                ^^^^^^^^^^^

Several of my suggestions earlier was to not write "a XXXX state", but
rather "the XXXX state".  There is just one.

> been reached.  In this case, a "subscription-concluded" is sent to any
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^

This should be:  a "subscription-concluded" notification is sent

> ACTIVE or SUSPENDED receivers.  Finally, a subscription may be deleted
> by configuration (3).
> 
> >   OLD:
> > 
> When a subscription first becomes VALID, the operational state of each
> receiver is initialized to CONNECTING.

You missed my point above.  Please check the whole diff to see if you
agree with all my changes.  If not, let me know.  This applies to all
such comments.

In this case, it is not clear what "the operational state" means,
hence I proposed: the "state" leaf.

> If transport connectivity is
> not available to any receiver, a transport session is established
> (e.g., through [RFC8071]). Individual receivers are moved to an ACTIVE
> state when a "subscription-started" state change notification is
> successfully passed to that receiver (1). Configured receivers remain
> ACTIVE if both transport connectivity can be verified to the receiver,
> and event records are not being dropped due to a publisher buffer
> overflow. The result is that a receiver will remain ACTIVE on the
> publisher as long as events aren't being lost, or the receiver cannot
> be reached.  However if there is buffer overflow, or the publisher
> cannot generate events for a receiver, the receiver MUST be moved to
> SUSPENDED (2).  In addition, a configured subscription's receiver MUST
> be moved to CONNECTING if transport connectivity cannot be achieved,
> or if the receiver is reset via configuration (3).
> 
> >   OLD:
> > 
> A configured subscription's receiver MUST be moved to a SUSPENDED

again you missed some of my changes; specifically "*the* SUSPENDED state".

> receiver, but notification messages are not able to be generated for

You missed "not able to" as well.

It is ok with me if you disagree with my proposed changes, but please
write that so that we can close these issues.  As it is now I don't
know if you just missed them, or didn't like them.

> that receiver.  A configured subscription receiver MUST be returned to
> an ACTIVE state from the SUSPENDED state...
> 
> > o  Section 2.5.1
> > 
> >   You write:
> > 
> be reset.  This is accomplished via the "reset" action within the YANG
> model at "/subscriptions/subscription/receivers/receiver/reset". This
> re-initialization may be useful in cases where a publisher has timed
> out trying to reach a receiver. When such a reset occurs, a transport
> session will be initiated if necessary, and a new

Ok.  I'll guess I'll review the new text when you publish an updated
version.  I want to make sure that you addressed my point, which was
that it is not clear (or rather it is wrong) to talk about "reset via
configuration operations"; reference present or not.

[...]

> Since all subscription parameters are included in the notification, it
> is not necessary to buffer anything but the last modification.  Added
> the last sentence in the note below:
> 
> 
> (Note: in this case, the "subscription-modified" notification informs
> the receiver that the subscription has been resumed, so no additional
> "subscription-resumed" need be sent.  Also note that if multiple
> modifications have occurred during the suspension, only the latest one
> need be sent to the receiver.)

Ok.

>    "subscription-started" notification will be sent.

Ok.

>    events should be expected.

s/events/event records/

I understand what you want to say, but I don't think text does a good
job of explainig it.  What is a "corresponding RPC response"?
Corresponding to what?  Maybe be more explict, along the lines of:

  When a dynamic subscription has been started or modified, with
  "establish-subscription" or "modify-subcription" respectively, event
  records matching the new filter criteria MUST NOT be sent until
  after the RPC reply has been sent.

  When a configuried subscription has been started or modified, event
  records matching the new filter criteria MUST NOT be sent until
  after the "subscription-started" or "subscription-modified"
  notifications has been sent, respectively.

[...]

> Kent has asked that this text be removed for now, as he believes this
> might impact IESG reviews.  So this and the notification-messages
> draft reference text has been removed.

Ok.

> Subscription state notifications cannot be filtered out, they cannot
> be stored in replay buffers, and they are delivered only to impacted
> receiver(s) of a subscription.

Ok.

>  1. "insufficient-resources" when a publisher is unable to produce the
>  requested stream of notification messages, and
>  2. "unsupportable-volume" when the bandwidth needed to get generated
>  notification messages to a receiver exceeds a threshold.
> 
> This additional feedback / differentiation is useful as a subscriber
> prepares for another attempt at subscription.
> 

Ok.

> Having a YANG module for a transport identity seems like overkill.

I agree.  But see my other comments above; I think such a module will
likely define receiver params (address, authentication info, timers
etc).  I think we agree that transport-specific receiver parameters
will be needed, so where will they be defined?   It seems logical to
define the transport identity and corresponding receiver params in the
same module.

> Plus with things like CBOR, UDP, etc. coming, replicating model names
> for this seems excessive.  It would be great to leave as is.  I of
> course will respect whatever IETF process requires.

I would like to hear the opinion from others in the WG about this
one.

> >     What is a "datastream"?   This word occur twice in the document,

Ok.  I would probably have used "event stream", but stream is fine.

> There have been requests for an establish-subscription RPC to request
> an alternative encoding (e.g., binary with CBOR).  Since there are
> lots of instances for which this is possible, trying not to exclude
> it.

Hmm, ok.  It would have been nice to not have this leaf for transports
that don't support it, and even better if the encoding would depend on
the transport.  This *can* be done with some new identities:

  identity configurable-encoding {
    description
      "If a transport identity derives from this identity, it means
       that it supports configurable encodings.";
  }

  identity http-2 {
    base transport;
    base configurable-encoding;
  }

  leaf encoding {
    when 'derived-from(../transport, "sn:configurable-encoding")';
  }

You can also have transport-specific encodings, instead of generic
encondings, in order to make it impossible to set e.g. "xml" encoding
on a comi transport (if that is a transport...).

> There is already text for establish and modify subscription RPCs.  But
> it cannot be boilerplate, referring just to this yang-data within this
> yang module.  The reasoning here is that we need to have different
> yang-data structures for different targets (datastore vs stream).
> This is due to different hints.

Ok.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 23 Mar 2018 16:39:08 +0000

Hi Martin,

> From: Martin Bjorklund, March 22, 2018 3:14 PM
> 
> Hi,
> 
> [pruning to open issues]
> 
> 
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-
> netcon
> > f-subscribed-notifications-11.txt
> >
> Yes; my mistake, I didn't mean to exclude the counters / state / action.  Just
> host/port.
> 
> someone would like to use them for something".  For interoperability, it is
> important that all objects we define have clear semantics, and that it clear
> how to use them.
> 
> In this case, none of the standard transports will need these nodes (unless
> the client-server models are severly changed).  If someone defines a
> transport in the future that needs these objects, it is trivial to do, and it will
> be done in a more robust way.
> 
> This said, if the WG strongly believes that these nodes are important, here's
> a design that might work:
> 

This proposal makes good sense to me, and can be extended if necessary.  I know implementers which need this now.   So I will insert it as a replacement for address + port (unless anyone else has an issue.)

> > (a) add "name" as integer under receivers.  Make this the index.

Agree: string.
 
> > (b) leave address + port as optional objects

Will remove.

> Yes, I think it is important to explain what the intention is.  I suggest you
> include an example for how to do this.

I would like to simply document that mechanisms for such receiver addressing extension can be done within the definition of the receivers container.  The document is so big already that inclusion of examples for all mechanisms of extensibility will overwhelm readers.  

Perhaps parallel documentation in the git repository could do this.  A single monolithic RFC is ill-suited to holding all such futures.  
 
> > session to get more feedback.

Look for a proposal to the WG with a proposal based on what you have above to the WG shortly.

> If new modules just define the identity now, they will be updated to include
> receiver-specific parameters later, right?  And we have a place to add more
> transport-specific params in the future.  See below.

Sounds good.
 
> Yes, I think that's what I suggested as well.

This looks to be workable to me.

> I don't think this is quite right.  If this is an alternative, does it mean that I
> can use this with <create-subscription etc from 5277, instead of using the
> structure in 5277?  I don't think this is the intention.
> 
> Maybe say:
> 

This works

> "MUST NOT support this specification" doesn't sound quite right.  I think
> what you mean is that an attempt to request a "establish-sublish-
> subscription" must fail, if there's an active subscription started by "create-
> subscription", and vice versa.

Agree.  Will tweak working this way.

> It might be safest to have two separate features.  My main point is to not
> bundle them into the same feature though.

Agree not to place in the same feature.  I will ask the WG if it prefers dscp to be mandatory-to-implement option, or a separate feature.  Either way is fine with me.

Note: based on other feedback, the IESG is going to force a rename away from dscp to something like 'priority'.  I might as well make this change to the name now.  As it will remain:
type inet:dscp;

Few people should get confused.  Look for this in the email to the WG as well.

> I don't understad this.  How can different subscriptions to the same reciever
> on the same transport session be allocated different bandwidth?

This is how weighting works with HTTP2.  Dequeuing counters figure out the proportion of each stream to place on the path to a destination.  Further dequeuing and balancing from there can be done across receivers.  And for physical paths too.  

Maybe your point is that we are not actually allocating bandwidth at this step.  And this is true.  But we are ultimately allocating a proportion of bandwidth relative to the two subscribers.  So the text reads true to me.   Maybe a couple more words wouldn't hurt?  Something like:

    Dequeuing of notification messages across independent subscriptions to
    a receiver SHOULD be allocated bandwidth proportionally to each other 
    based on each subscription's weight.

> Why is the first one a SHOULD but the second a MUST?

They both should be a MUST.  I was wrongly trying to give implementers wiggle room with the SHOULD.  As an optional feature, let's make it the more stringent MUST.
 
> > not exist or is no longer visible to that subscriber, that dependency

Yes, will change to accessible.

> is?

Will do that.  It is more stringent.

> In the sense that I think I know how to implement it - yes.  But I wonder if
> this added complexity is necessary, or if we should leave it out.

With the feature being optional, it being very useful for HTTP2, I am hoping it stays in.

> Ok.  But I wonder if this really is a requirement of the base mechanism, or if
> it should be moved to the transport-specific documents instead.  For
> example, how is this supposed to work on non-session based transports?

If there is no session, then the requirement that supporting multiple within them is not an issue.   

I think the requirement is helpful as it sets an expectation of behavior which should not deviate across different session-oriented transports.
 
> Secondly, I think that this should also be done in the transport document.
> For NETCONF, it is not needed, since 6241 already requires pipelining.

Ok.  As all the transports I know about support pipelining, I will drop this.

> I still think you need "and *then* starts ...".  Otherwise it seems it could be
> ok to send a notif on this new subscription before sending the reply.

Will add 'then'.

>   establish-subscription-datastore-error-info

Will do.
 
> etc, since VALID is the name of a state.

Ok.  Will do the tweak.

> > transition to a CONCLUDED state via (4) if a configured stop time has

Will make the change

Ok.

> You missed my point above.  Please check the whole diff to see if you agree
> with all my changes.  If not, let me know.  This applies to all such
> comments.
>
> In this case, it is not clear what "the operational state" means, hence I
> proposed: the "state" leaf.

Got it.  Will make the change.
 
> again you missed some of my changes; specifically "*the* SUSPENDED

Got it.   The formalism you are requesting will be added.

> You missed "not able to" as well.

Will do.
 
> It is ok with me if you disagree with my proposed changes, but please write
> that so that we can close these issues.  As it is now I don't know if you just
> missed them, or didn't like them.

Basically I didn't even see them as I thought the more and less formal versions were effectively equivalent.
 
> > <section title="Resetting a Configured Receiver" anchor="reset"> It is
> > possible that a configured subscription to a receiver needs to be
> > reset.  This is accomplished via the "reset" action within the YANG
> Ok.  I'll guess I'll review the new text when you publish an updated version.
> I want to make sure that you addressed my point, which was that it is not
> clear (or rather it is wrong) to talk about "reset via configuration
> operations"; reference present or not.
> 
> [...]
> 
> > > o  Section 2.5.3
> > >

Ok.  
 
> I understand what you want to say, but I don't think text does a good job of
> explainig it.  What is a "corresponding RPC response"?

Placed your proposed text after the example notification message.  And changed 'new' to 'newly applied'.

> > requested stream of notification messages, and  2.
> > "unsupportable-volume" when the bandwidth needed to get generated
> I agree.  But see my other comments above; I think such a module will likely
> define receiver params (address, authentication info, timers etc).  I think we
> agree that transport-specific receiver parameters
> I would like to hear the opinion from others in the WG about this one.

Will take this one to the list.

> Hmm, ok.  It would have been nice to not have this leaf for transports that
> don't support it, and even better if the encoding would depend on the
> transport.  This *can* be done with some new identities:
> 
> encondings, in order to make it impossible to set e.g. "xml" encoding on a
> comi transport (if that is a transport...).

I like it.   This provides good protections.  It also addresses Andy's comment.

> > This is due to different hints.

Thanks again for the comments Martin.    Looking above at everywhere we have general agreement, I am pretty positive on the effectiveness of these dialogs.

Eric