Skip to main content

Subscription to YANG Notifications
draft-ietf-netconf-subscribed-notifications-26

Revision differences

Document history

Date Rev. By Action
2019-09-07
26 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-08-12
26 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-07-08
26 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2019-07-02
26 (System) RFC Editor state changed to AUTH from RFC-EDITOR
2019-06-27
26 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2019-06-21
26 (System) RFC Editor state changed to AUTH from EDIT
2019-05-30
26 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-05-30
26 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2019-05-30
26 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-05-30
26 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-05-30
26 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-05-23
26 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-05-21
26 (System) RFC Editor state changed to EDIT
2019-05-21
26 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-05-21
26 (System) Announcement was received by RFC Editor
2019-05-21
26 (System) IANA Action state changed to In Progress
2019-05-21
26 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-05-21
26 Amy Vezza IESG has approved the document
2019-05-21
26 Amy Vezza Closed "Approve" ballot
2019-05-21
26 Amy Vezza Ballot approval text was generated
2019-05-21
26 Ignas Bagdonas IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-05-10
26 Jean Mahoney Request closed, assignment withdrawn: Jari Arkko Last Call GENART review
2019-05-10
26 Jean Mahoney Closed request for Last Call review by GENART with state 'Team Will not Review Version'
2019-05-10
26 Magnus Westerlund
[Ballot comment]
Thanks for addressing the discuss and issues. I understand that there is significant work in defining a solution that actually is capable of …
[Ballot comment]
Thanks for addressing the discuss and issues. I understand that there is significant work in defining a solution that actually is capable of expressing the receiver's need and provides the publisher with reasonable to process rules and avoids the randomness in what happens in an overload situation. I hope the community will consider how they deal with this issue going forward.
2019-05-10
26 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2019-05-08
26 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-05-08
26 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-05-08
26 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-26.txt
2019-05-08
26 (System) New version approved
2019-05-08
26 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2019-05-08
26 Eric Voit Uploaded new revision
2019-05-06
25 Roman Danyliw [Ballot comment]
Thank you for resolving my DISCUSS.
2019-05-06
25 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2019-05-06
25 Benjamin Kaduk [Ballot comment]
Thank you for resolving my Discuss points!
2019-05-06
25 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-05-03
25 Benjamin Kaduk [Ballot discuss]
It looks like the description of filter-failure-hint in
modify-subscription-stream-error-info needs the same treatment that
establish-subscription-stream-error-info  received.
2019-05-03
25 Benjamin Kaduk
[Ballot comment]
[original comment section replaced]

In the updated security considerations:

  The replay mechanisms described in Sections Section 2.4.2.1 and
  Section 2.5.6 provides …
[Ballot comment]
[original comment section replaced]

In the updated security considerations:

  The replay mechanisms described in Sections Section 2.4.2.1 and
  Section 2.5.6 provides access to historical event records.  By
  design, the access control model that protects these records could
  enable subscribers to view data to which they were not authorized at
  the time of collection.

Looks like there's some xml2rfc redundancy ("Sections Section").

  o  "excluded-event-records": leaf can provide information about
      filtered event records.  A network operator should have
      permissions to know about such filtering.  Improper configuration
      could provide a receiver with information leakage consisting of
      the dropping of event records.

In mail I had proposed "Improper configuration could allow a receiver to learn
that event records were dropped due to an ACL when the existence of that ACL
would otherwise be transparent."; repeating it here just in case it got missed
(but this  remains the non-blocking comment section).
2019-05-03
25 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2019-05-02
25 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-05-02
25 Magnus Westerlund
[Ballot discuss]
My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this …
[Ballot discuss]
My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this will actually work, especially in a fashion that preservers goodput and ensure what is considered the most important subscriptions are delivered. Not having good undertanding into netconf and restconf don't hesitate to call out likely missunderstanding by me and provide clarification and pointers.

A) The QoS and priority sending mechanism discussed in 2.3 and furhter defined by the YANG model.

I do want to raise the usage of the DSCP code point to a discuss. As the DSCP defines different PHB and relative priorities in the router queues a DSCP value does not provide the publisher any information about priority. I get the feeling from the text that this may be intended. If the only intention is to have the transport perform differential treatment in the network between the publisher and the receiver there are still more considerations are needed. First of all I think these sentence needs a total rewrite:

  If the publisher supports the "dscp" feature, then a subscription
  with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
  marking being placed within the IP header of any resulting
  notification messages and subscription state change notifications.
  Where TCP is used, a publisher which supports the "dscp" feature
  SHOULD ensure that a subscription's notification messages are
  returned within a single TCP transport session where all traffic
  shares the subscription's "dscp" leaf value.

I think one need to put a requriement on the transport to use a transport that utilize the DSCP marking on its traffic. Which for the current set of connection oriented transport protocols, TCP, SCTP, and QUIC all currently only support using a single DSCP per connection. Implying multiple transport protocol connections using a particular transport to enable this mapping.

A.2 Queuing model of a publisher.
With the DSCP and the Weight and dependency model I think it is important to clarify the model of the queueing in the publisher. So is the intention that several subscriptions with different weights and possibly dependencies have their individual queues that goes into a scheduler? To avoid complex queue interactions on this level I think there need to be seperate scheduler instances per DSCP. I would also note that Dependency mechanism can't ensure that a dependent stream arrive at receiver after the identified dependency if they are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not even guarantee it within a single connection and same DSCP due to packet loss impact. To me this model and what relationship one need to consider here need to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication of just the importance of considering what is in the same dependency tree and what it means to have different weighting. To conclude I think this needs a model description and clearer definition and possibly requirements towards the transport. Espceially if you actually need an in-order delivery requirement?

B. The unpredictability of the circuit breaker overload mechanism.

My description of the overload handling in this document is that it is a circuit breaker based mechanism that can blow a fuse on subscriptions that it fails to honor in overload situations. What worries me deply is the total unpredictability of this mechanism.

First, is it the intention to derive what subscriptions are least important from the DSCP, weighting and Dependency parameters? If it is, I think that may be a misstake as priority on what subscriptions are most important to retain are not necessarily reflected in their QoS parameters.

Secondly, what are the values when a subscription are considered to be to heavy or not be handled accordingly. Are there any parameter sets that actually describe what SLA the subscriber expect that can be converted into timeout timers or buffer depth thresholds to indicate that publisher side isn't delivering these in time?

Third, I what I understand there are no any additional back pressure mechanism between the receiver and the publisher than the transport protocols flow control? So a receiver that is not keeping up processing the data it process will not read out the data out of the flow controlled buffers in the receiver and thus prevent the publisher to write to the transport conncetion, thus causing the publisher to eventually trigger a suspension due to its queue build up? 

To my understanding the current mechanism places all subscriptions on the same importance and with the same SLA. Thus likely causing short term overload situations to cause subscription suspensions in random subscriptions. Is the WG fine with this type of randomness occuring and expecting that normally there will be such amount of overprovisioning that being able to indicate priority and SLA are overkill?

At a minimal a change of this sentence in Section 2.5.1 is needed:

  This could
  be for reasons of an unexpected but sustained increase in an event
  stream's event records, degraded CPU capacity, a more complex
  referenced filter, or other higher priority subscriptions which have
  usurped resources.

As it states that subscriptions has priorities without reference to a mechanism that provides that priority.

C. 2.4.5.  Killing a Dynamic Subscription

  The "kill-subscription" operation permits an operator to end a
  dynamic subscription which is not associated with the transport
  session used for the RPC.  A publisher MUST terminate any dynamic
  subscription identified by the "id" parameter in the RPC request, if
  such a subscription exists.

Can someone please clarify the use case for this functionality. To my understanding it allows another receiver given authority to kill the subscription being delivered to another receiver. Based on the otherwise rather strict that all manipulations of dynamic subscriptions happens from the transport session context that established it I want to better understand the use case it appears out place.

D. The Requirements on a transport supporting Configured Subscriptions
Reading through Section 2.5 I arrived at a number of questions. I tried to understand what the requirements are for the transport that supports Configured Subscriptions. I did note that neither draft-ietf-netconf-restconf-notif-13 nor draft-ietf-netconf-netconf-event-notifications-17 supports configured subscriptions. Thus, there appear no template for a solution either, or does there exist another document that is being worked on defining such a transport?

Questions that arose for me related to Configured Susbription Transport where the following:
1. Can Transport Session be initiated in both direction. RFC 8071 provides a solution for Publisher to Receiver initiation. It is unclear if all parts are in place to have a receiver to publisher initiated transport to be bound to the subscription.
2. What is "name" really? It appears to be defined as an empty container. Despite that it appears to have requirements on being both a security identity as well as network address.
3. In Figure 9, which is stated to be for the receiver. What information does the receiver use to determine the transition (d)? And what does it do in this step. Related to Discuss part B).
4. RFC 8071 appears to lack any considerations for how often and how many times it attempts to connect to the receiver. So applying that mechanism appears to require some usage guidance to avoid causing overload situations or DoS potential by misconfiguring network devices with this soltution to dial out frequently to a target.

As the transport solution requirements are not detail it is actually hard to determine if there are short comings in the description in Section 2.5 and the corresponding YANG model. Is it an reasonable request to document these requirements?
2019-05-02
25 Magnus Westerlund
[Ballot comment]
1. Section 2.3: DSCP domains
I think the text could benefit from pointing out that the subscriber actually needs to know what the …
[Ballot comment]
1. Section 2.3: DSCP domains
I think the text could benefit from pointing out that the subscriber actually needs to know what the DSCP values represents in the diffserv domain of the publisher. As these could be different, they also create an interesting problems for transports of how they establish a transport connection that uses a particular DSCP, as the receiver if initiating need to know the local DSCP value that corresponds to the behavior in the publisher's domain.

2. In general I think there are more than one description that are fuzzy about if it describes a publisher or receiver action/requirement.
2019-05-02
25 Magnus Westerlund Ballot comment and discuss text updated for Magnus Westerlund
2019-05-02
25 Magnus Westerlund
[Ballot discuss]
My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this …
[Ballot discuss]
My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this will actually work, especially in a fashion that preservers goodput and ensure what is considered the most important subscriptions are delivered. Not having good undertanding into netconf and restconf don't hesitate to call out likely missunderstanding by me and provide clarification and pointers.

A) The QoS and priority sending mechanism discussed in 2.3 and furhter defined by the YANG model.

I do want to raise the usage of the DSCP code point to a discuss. As the DSCP defines different PHB and relative priorities in the router queues a DSCP value does not provide the publisher any information about priority. I get the feeling from the text that this may be intended. If the only intention is to have the transport perform differential treatment in the network between the publisher and the receiver there are still more considerations are needed. First of all I think these sentence needs a total rewrite:

  If the publisher supports the "dscp" feature, then a subscription
  with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
  marking being placed within the IP header of any resulting
  notification messages and subscription state change notifications.
  Where TCP is used, a publisher which supports the "dscp" feature
  SHOULD ensure that a subscription's notification messages are
  returned within a single TCP transport session where all traffic
  shares the subscription's "dscp" leaf value.

I think one need to put a requriement on the transport to use a transport that utilize the DSCP marking on its traffic. Which for the current set of connection oriented transport protocols, TCP, SCTP, and QUIC all currently only support using a single DSCP per connection. Implying multiple transport protocol connections using a particular transport to enable this mapping.

A.2 Queuing model of a publisher.
With the DSCP and the Weight and dependency model I think it is important to clarify the model of the queueing in the publisher. So is the intention that several subscriptions with different weights and possibly dependencies have their individual queues that goes into a scheduler? To avoid complex queue interactions on this level I think there need to be seperate scheduler instances per DSCP. I would also note that Dependency mechanism can't ensure that a dependent stream arrive at receiver after the identified dependency if they are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not even guarantee it within a single connection and same DSCP due to packet loss impact. To me this model and what relationship one need to consider here need to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication of just the importance of considering what is in the same dependency tree and what it means to have different weighting.

B. The unpredictability of the circuit breaker overload mechanism.

My description of the overload handling in this document is that it is a circuit breaker based mechanism that can blow a fuse on subscriptions that it fails to honor in overload situations. What worries me deply is the total unpredictability of this mechanism.

First, is it the intention to derive what subscriptions are least important from the DSCP, weighting and Dependency parameters? If it is, I think that is a misstake as priority on what subscriptions are most important to retain are not necessarily reflected in their QoS parameters.

Secondly, what are the values when a subscription are considered to be to heavy or not be handled accordingly. Are there any parameter sets that actually describe what SLA the subscriber expect that can be converted into timeout timers or buffer depth thresholds to indicate that publisher side isn't delivering these in time?

Third, I hard time to understand if there are any additional back pressure mechanism between the receiver and the publisher than the transport protocols flow control? So a receiver that is not keeping up processing the data it process will not read out the data out of the flow controlled buffers in the receiver and thus prevent the publisher to write to the transport conncetion, thus causing the publisher to eventually trigger a suspension. Is it correct that this is the only mechanism present?

To my understanding the current mechanism places all subscriptions on the same importance and with the same SLA. Thus likely causing short term overload situations to cause subscription suspensions in random subscriptions. Is the WG fine with this type of randomness occuring and expecting that normally there will be such amount of overprovisioning that being able to indicate priority and SLA are overkill?

C. 2.4.5.  Killing a Dynamic Subscription

  The "kill-subscription" operation permits an operator to end a
  dynamic subscription which is not associated with the transport
  session used for the RPC.  A publisher MUST terminate any dynamic
  subscription identified by the "id" parameter in the RPC request, if
  such a subscription exists.

Can someone please clarify the use case for this functionality. To my understanding it allows another receiver given authority to kill the subscription being delivered to another receiver. Based on the otherwise rather strict that all manipulations of dynamic subscriptions happens from the transport session context that established it I want to better understand the use case it appears out place.

D. The Requirements on a transport supporting Configured Subscriptions
Reading through Section 2.5 I arrived at a number of questions. I tried to understand what the requirements are for the
2019-05-02
25 Magnus Westerlund
[Ballot comment]
1. Section 2.3: DSCP domains
I think the text could benefit from pointing out that the subscriber actually needs to know what the …
[Ballot comment]
1. Section 2.3: DSCP domains
I think the text could benefit from pointing out that the subscriber actually needs to know what the DSCP values represents in the diffserv domain of the publisher. As these could be different, they also create an interesting problems for transports of how they establish a transport connection that uses a particular DSCP, as the receiver if initiating need to know the local DSCP value that corresponds to the behavior in the publisher's domain.
2019-05-02
25 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2019-05-02
25 Alexey Melnikov [Ballot comment]
I missed comment from the document shepherd about YANG validation, so I am clearing my DISCUSS.
2019-05-02
25 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2019-05-02
25 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-05-01
25 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-05-01
25 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-05-01
25 Alvaro Retana [Ballot comment]
I support Roman's DISCUSS.
2019-05-01
25 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-05-01
25 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-05-01
25 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-05-01
25 Alissa Cooper
[Ballot comment]
= Section 1.3 =

"Also note that transport specific transport drafts based on this
  specification MUST detail the life cycle of dynamic …
[Ballot comment]
= Section 1.3 =

"Also note that transport specific transport drafts based on this
  specification MUST detail the life cycle of dynamic subscriptions, as
  well as the lifecycle of configured subscriptions (if supported)."

I think this would be clearer if it said "transport-specific documents."

= Section 2.5 =

Please expand VRF on first use.
2019-05-01
25 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-05-01
25 Alexey Melnikov
[Ballot discuss]
YANG validator reports the following:

yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i:
err : The leafref leaf is …
[Ballot discuss]
YANG validator reports the following:

yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i:
err : The leafref leaf is config but refers to a non-config leaf. (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream)
err : The leafref leaf is config but refers to a non-config leaf. (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream)
err : Invalid value "subscription-policy" of "uses". (/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)
err : Copying data from grouping failed. (/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)
err : Module "ietf-subscribed-notifications" parsing failed.

I would like to understand whether this is a problem with the document or a problem with the validating tool.
2019-05-01
25 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2019-05-01
25 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-05-01
25 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-25.txt
2019-05-01
25 (System) New version approved
2019-05-01
25 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2019-05-01
25 Eric Voit Uploaded new revision
2019-04-30
24 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-04-30
24 Warren Kumari [Ballot comment]
I support Benjamin and Roman's DISCUSSes.

Also, thanks to Benjamin and others for such detailed reviews, they saved my much typing :-)
2019-04-30
24 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-04-30
24 Benjamin Kaduk
[Ballot discuss]
Thanks for this document; I just have a few minor "housekeeping" points
that should get resolved before publication.  (Please also note the
substantive …
[Ballot discuss]
Thanks for this document; I just have a few minor "housekeeping" points
that should get resolved before publication.  (Please also note the
substantive comments in the COMMENT section as well, particularly those
relating to the transport requirements and security considerations.)

I'm not sure that we state clearly enough what is required to have a
specification for a transport for notifications.  Specifically (see
COMMENT), in the module we seem to say that the specification must
indicate what the default encoding is to be used if not otherwise
specified, but that's not enumerated as a requirement on such a
specification anywhere I see.  I also think that we could probably
require (as opposed to "highly recommend" in the current security
considerations) that the transport provide message confidentiality and
integrity protection.

I'm also unsure that I properly understand the use of the "reset" RPC --
if it has no effect when transit connectivity already exists, then what
entity is going to call "reset" in the case of publisher timeout when
trying to reach a receiver?  Surely not the publisher itself, since
that would just be publisher-internal functionality with no need for an
external-facing RPC.

I'm also a little unclear on the mechanics of the list of subscriptions
described in Section 3.3.  Does it provide a way for a low-privilege
client (that can only access one or a handful of the subscriptions) to
enumerate all subscriptions that exist, including subscriptions used by
high-privilege clients?  If so, we may want to think about some security
considerations text to that effect; if not, we may want to say that the
access-control will limit which leafs are visible to some clients.

Finally, we have a few instances of "leaf filter-failure-hint" that's of
type "string", providing
            "Information describing where and/or why a provided filter
              was unsupportable for a subscription.";
I don't understand why it's a string as opposed to some form of
machine-readable data.  Is it supposed to be human-readable?  Does that
bring in any internationalization considerations?
2019-04-30
24 Benjamin Kaduk
[Ballot comment]
Section 1.3

  Also note that transport specific transport drafts based on this
  specification MUST detail the life cycle of dynamic subscriptions, …
[Ballot comment]
Section 1.3

  Also note that transport specific transport drafts based on this
  specification MUST detail the life cycle of dynamic subscriptions, as
  well as the lifecycle of configured subscriptions (if supported).

I'm not sure I understand what additional specification is needed for
the lifecycle of configured subscriptions -- doesn't the previous
text tightly tie their lifecycle to the presence of configuration in the
configuration datastore?
nit: please be consistent about "life cycle" vs. "lifecycle" throughout.

Section 2.1

  An event stream is a named entity on a publisher which exposes a
  continuously updating set of YANG encoded event records.  [...]

nit: I don't think "YANG encoded" is well-defined (here and below), in
that YANG structures generate data models but can be encoded into
various formats (like XML and JSON).

Section 2.3

  If the publisher supports the "dscp" feature, then a subscription
  with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
  marking being placed within the IP header of any resulting
  notification messages and subscription state change notifications.
  Where TCP is used, a publisher which supports the "dscp" feature
  SHOULD ensure that a subscription's notification messages are
  returned within a single TCP transport session where all traffic
  shares the subscription's "dscp" leaf value.  Where this cannot be
  guaranteed, any "establish subscription" RPC request SHOULD be
  rejected with a "dscp-unavailable" error

I can't decide whether we need to be more explicit in the second and/or
third sentences that this remains contingent on the subscription in
question having a "dscp" leaf.
nit: end sentence with a full stop

I share the TSV-ART reviewer's confusion about how the weighting
(as well as DSCP) functionality is intended to work.

Section 2.4.2.1

  Replay provides the ability to establish a subscription which is also
  capable of passing recently generated event records.  In other words,

nit/editorial: this language could probably be more clear about
"recently generated" meaning "in the past", that is, records for events
that have already happened when the subscription is established.

Section 2.4.3

  any number of times.  Dynamic subscriptions can only be modified via
  this RPC using a transport session connecting to the subscriber.  If

nit(?): is this more readable as "connecting to" or "connecting from"
the subscriber?  (The same wording shows up throughout the document, but
I'll try to just comment once.)

Section 2.4.5

Is there any distinction between "killing a subscription" and
"administratively deleting a subscription"?  It's unclear to me that we
need the extra connotations of the word "kill", here.

Section 2.4.6

  As a result of this mixture, how subscription errors are encoded

nit: "mixture" doesn't seem like the right word to me; "variety" or
"varied population" are the first alternatives that come to mind, though
they are not perfect either.

Is there some sort of "access denied" error that could result from
kill-subscription RPCs?  (The table/artwork only lists
"no-such-subscription".)

Section 2.5

It's interesting to see a slight dichotomy between dynamic and
configured subscriptions, in that (IIUC) for dynamic subscriptions, a
modification event un-suspends a subscription immediately, but for
configured subscriptions the publisher seems to have some latitude to
retain the subscription in the suspended state for some time before
un-suspending it and sending the "subscription-modified" state change
message.

                In this case, a separate dynamic subscription can be
  established to retransmit the missing event records.

Do you want to put in a pointer to replay-start-time here?

Section 2.5.1

        Event records are only sent to active receivers.  Receivers of
  a configured subscription 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.  [...]

nit: "buffer overflow" is a technical term in security circles
indicating a potentially exploitable security flaw; would "publisher
buffer capacity being reached" be an acceptable substitute (here and
below)?

Section 2.7.7

  This notification indicates that all of the event records prior to
  the current time have been passed to a receiver.  It is sent before
  any notification message containing an event record with a timestamp
  later than (1) the "stop-time" or (2) the subscription's start time.

nit(?): this text seems to imply that a notification message with a
timestamp later than the "stop-time" might actually be sent, which IIUC
is not the case.

Section 2.9

nit: the name "supports-vrf" for the feature doesn't really parallel the
other feature names, that don't include a word like "support" and rather
just describe the actual feature.

Section 3.1

Is there any risk of collision in event stream names from
vendor-specific streams?  (We don't seem to create an IANA registry
for them, for example.)

Section 4

  identity subscription-suspended-reason {
      description
      "Problem condition communicated to a receiver as part of a
      'subscription-terminated' notification.";
  }

  identity subscription-terminated-reason {
      description
      "Problem condition communicated to a receiver as part of a
      'subscription-terminated' notification.";
  }

Are these descriptions supposed to be the same?

  identity configurable-encoding {
    description
      "If a transport identity derives from this identity, it means
        that it supports configurable encodings.  An example of a [...]

Is it intended that such future transports (or future encodings?) will
derive from both this and the normal base identity (i.e., "transport")?
I guess I'm asking why this identity does not derive from the
corresponding base, but that's just a style question and not really a
protocol matter, making this question a side note.

    leaf weighting {
      if-feature "qos";
      type uint8 {
          range "0 .. 255";
      }
      description
        "Relative weighting for a subscription. Allows an underlying
          transport layer perform informed load balance allocations
          between various subscriptions";
      reference
        "RFC-7540, section 5.3.2";

Do we want to chase the reference for readers and say that larger
weights get more resources?

    leaf encoding {
      when 'not(../transport) or derived-from(../transport,
      "sn:configurable-encoding")';
      type encoding;
      description
        "The type of encoding for notification messages.  For a
        dynamic subscription, if not included as part of an establish-
        subscription RPC, the encoding will be populated with the
        encoding used by that RPC.  For a configured subscription, if
        not explicitly configured the encoding with be the default
        encoding for an underlying transport.";

Where is the default encoding for an underlying transport specified?
Section 5.3 does not seem to say that a transport specification must
provide this information, nor does Section 1.3 (which mentions that
transport specifications must detail the lifecycle of dynamic
subscriptions), nor does Section 2.5.7 (that discusses the need for a
separate model augmenting /subscriptions/subscription/receivers/receiver
to provide transport details).

      choice notification-message-origin {
        if-feature "configured";
        description
          "Identifies the egress interface on the publisher from which
            notification messages are to be sent.";

nit: given the address-originated case, perhaps "the egress interface"
is not quite correct anymore.

              enum connecting {
                value 3;
                if-feature "configured";
                description
                  "A subscription has been configured, but a
                  'subscription-started' subscription state change
                  notification needs to be successfully received before
                  notification messages are sent.

nit: successful receipt happens on the receiver but sending happens on
the publisher, so there's a bit of a mismatch in the sentence subject
here.  Perhaps we could talk about "successfully sent" state-changes to
resolve things.

            config false;
            mandatory true;
            description
              "Specifies the state of a subscription from the
              perspective of a particular receiver.  With this info it
              is possible to determine whether a subscriber is
              currently generating notification messages intended for
              that receiver.";

nit: is it the subscriber that is generating messages or the publisher?

Section 5.3

  A secure transport is highly recommended and the publisher MUST
  ensure that the receiver has sufficient authorization to perform the
  function they are requesting against the specific subset of content
  involved.

"secure transport" usually means that it provides message
confidentiality, integrity protection, and source authenticity (akin to
the mutual authentication).  This is qualitatively different from
implementing authorization checks, and it's surprising to see them
squashed into the same sentence.

Do we want to say anything about discovery for support of new
transports, and what workflow would be used to negotiate the use of a
new transport?

Section 5.4

I can think of a couple other considerations to mention here:

- Using DNS names for receiver "name" lookup can cause situations where
  the name resolves differently on the publisher and subscriber, so the
  recipient would be different than expected.

- Using the publisher's boot time for deduplication protection on
  replayed messages introduces a dependency on accurate time.  We don't
  have a great secure time story at present, so this is more of a
  "beware of risk" situation than something we can mitigate, but it does
  seem that an attacker that could (e.g.) spoof the NTP traffic to the
  publisher on boot could cause it to send duplicate notifications to
  recipients that requested historical data.

Some other comments on what's already there (which is pretty good;
thanks for it!) follow.

  Container: "/filters"

  o  "stream-subtree-filter": updating a filter could increase the
      computational complexity of all referencing subscriptions.

  o  "stream-xpath-filter": updating a filter could increase the
      computational complexity of all referencing subscriptions.

Do we want to say anything about modifying either of these causing the
set of notifications delivered to recipients to shrink (or become
unmanageably large)?  I guess it may not be necessary, since the
recipient gets a notification about the modification that includes the
details of the filter.

  Container: "/subscriptions"

  o  "excluded-event-records": leaf can provide information about
      filtered event records.  A network operator should have
      permissions to know about such filtering.

To be clear, this is event records filtered either via explicit filter
or via access control restrictions.  Specifically, it can allow a
receiver to learn that there exists access controls that deny it access
to some data, in the case when they did not apply any filtering rules
explicitly.  This potential for information leakage (of the existence of
ACLs) should be mentioned explicitly.

Appendix A

This example transport module does not specify the life cycle of dynamic
subscriptions per Section 1.3, and a couple other things required from a
transport module specification.  Perhaps we are okay claiming that since
this is just an example YANG model and not a full transport example, the
omission is okay, but it may be worth mentioning the omission for
clarity.
2019-04-30
24 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Discuss from No Record
2019-04-30
24 Roman Danyliw
[Ballot discuss]
Sections 2.4.2.1 and 2.5.6 seems to describe a mechanism (replay) to access historical data that was potentially collected prior to a given subscriber …
[Ballot discuss]
Sections 2.4.2.1 and 2.5.6 seems to describe a mechanism (replay) to access historical data that was potentially collected prior to a given subscriber having access to it.  This appears to be an explicitly designed feature.  No push back on that.  However, I believe that explicitly stating this arrangement is warranted.  Perhaps something on the order of the following could be added to the Security Considerations -- “The replay mechanisms described in Sections 2.4.2.1 and 2.5.6 provides access to historical event records.  By design, the access control model that protects these records could enable subscribers to view data to which they were not authorized at the time of collection.”
2019-04-30
24 Roman Danyliw
[Ballot comment]
(1) Section 2.5.1.  Per Figure 8, if a modify operation fails re-evaluation (the “no (2)” branch) wouldn’t it go directly to “invalid” (instead …
[Ballot comment]
(1) Section 2.5.1.  Per Figure 8, if a modify operation fails re-evaluation (the “no (2)” branch) wouldn’t it go directly to “invalid” (instead of through “unsupportable->invalid”)?

(2) Section 2.5.2, what are “transport specific call-home operations”?

(3) Section 2.5.6.  Typos

s/timegap/time gap/
s/successfully/successfully/
2019-04-30
24 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2019-04-30
24 Éric Vyncke
[Ballot comment]
I appreciate the goal of this document to specify another telemetry streaming than gRPC. As the I-D has been reviewed by YANG-doctors, I …
[Ballot comment]
I appreciate the goal of this document to specify another telemetry streaming than gRPC. As the I-D has been reviewed by YANG-doctors, I did not look in the YANG module.

Comments
--------

C1) section 1.3, should the published check authorization before accepting an subscription? There is some text in section 3.1 is about authorization but I would prefer to have this authorization stated as early as possible

C2) end of section 1.3, "transport drafts" shouldn't rather be "transport specifications" ?

C3) end of section 1.3, upon termination decided by the publisher, is there a need for any explanation message sent to the subscriber?

C4) is there any reason why the YANG module validation but the datatracker fails? Outdated/invalid PYANG ?

C5) section 2.2 "all event records on an event stream are to be sent", should there be a mention of publisher being out of ressource ?

C6) section 2.4.1 "insufficient CPU or bandwidth available" but there may be other reasons (e.g. memory), what about using "insufficient CPU, bandwidth unavailable or other lack of ressource"

C7) for my curiosity, in section 2.4.2.1, how deep could realistically be a replay buffer? Minutes?

C8) the term 'transport' is used quite often in the document but it seems to refer to NETCONF and not so much to my understanding of 'transport' in an IETF document (which is TCP, UDP, SCTP, ...). Is it obvious to the readers? If so, then I do not mind. Else, it may be useful to clarify in section 1.2

Nits
----

N1) is there any reason why not all Cisco authors are not grouped together? (even if another one has changed affiliation)

N2) abstract s/information/data/ also applicable in other sections IMHO

N3) section 1.3, expand RPC even if obvious

N4) section 2.3, expand QoS even if obvious
2019-04-30
24 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-04-29
24 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Record from Discuss
2019-04-29
24 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-04-29
24 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-24.txt
2019-04-29
24 (System) New version approved
2019-04-29
24 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2019-04-29
24 Eric Voit Uploaded new revision
2019-04-29
23 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-04-29
23 Benjamin Kaduk
[Ballot discuss]
[putting this out early in the hopes it can be resolved quickly; I'm just starting to review the document.]

This document started life …
[Ballot discuss]
[putting this out early in the hopes it can be resolved quickly; I'm just starting to review the document.]

This document started life as a rfc5277bis, published in July 2008, before RFC 5378 (BCP 78) was published
in November of 2008.  If we are using any text from RFC 5277 and did not gain the additional rights
declaration from the authors of that document, this document needs to use a different boilerplate text
(the "pre-2008" text).  I look at the sibling document draft-ietf-netfonf-yang-push of this document,
which does use the pre-2008 boilerplate, and am having a hard time understanding why this document
does not also have the pre-2008 boilerplate.
2019-04-29
23 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-04-29
23 Mirja Kühlewind
[Ballot comment]
1) Sec 2.3:
  “Where TCP is used, a publisher which supports the "dscp" feature
  SHOULD ensure that a subscription's notification messages …
[Ballot comment]
1) Sec 2.3:
  “Where TCP is used, a publisher which supports the "dscp" feature
  SHOULD ensure that a subscription's notification messages are
  returned within a single TCP transport session where all traffic
  shares the subscription's "dscp" leaf value.“
This should probably be generalised to “If a connection-oriented protocol is used, …”, however, I’m not sure I understand the sentence correctly. It is no problem to have multiple TCP session using the same DSCP value, however, what should be avoided is using different DCSP values within the same TCP connection. Can you please clarify what this sentence is supposed to say?

2) Also sec 2.3:
“For the "weighting" parameter, when concurrently dequeuing
  notification messages from multiple subscriptions to a receiver, the
  publisher MUST allocate bandwidth to each subscription proportionally
  to the weights assigned to those subscriptions.”
I’m also wondering about this sentence. Should this really be a MUST? I can assume that there could also be cases where there is a local policy to prioritise some notification. And do you really mean bandwidth (which would mean taking the message size into account), or would it make sense to leave the details to the exact implementation of the publisher and maybe talk just about “resources” instead?

3) Sec 1.3 says
“ the loss of the transport session will
      result in the immediate termination of any associated dynamic
      subscriptions.”

However, there is the following text in section 2.4.5:
“The "kill-subscription" operation permits an operator to end a
  dynamic subscription which is not associated with the transport
  session used for the RPC.”
If the subscription is anyway immediately terminated when the transport session is lost, why is the kill-subscription operation still needed?

4) Sec 2.5: Please expand VRF.

5) Figure 8: I would recommend to call the second “evaluate” event “re-evaluate” instead.
2019-04-29
23 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-04-17
23 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-04-16
23 Ignas Bagdonas IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2019-04-16
23 Amy Vezza Placed on agenda for telechat - 2019-05-02
2019-04-16
23 Ignas Bagdonas IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
2019-04-16
23 Ignas Bagdonas Ballot has been issued
2019-04-16
23 Ignas Bagdonas [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas
2019-04-16
23 Ignas Bagdonas Created "Approve" ballot
2019-04-16
23 Ignas Bagdonas Ballot writeup was changed
2019-04-16
23 Min Ye Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Ravi Singh.
2019-04-12
23 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-04-12
23 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netconf-subscribed-notifications-23. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netconf-subscribed-notifications-23. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-subscribed-notifications
URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-subscribed-notifications
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications
Prefix: sn
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-04-12
23 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-04-05
23 Carlos Pignataro Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Carlos Pignataro. Sent review to list.
2019-04-04
23 Jean Mahoney Request for Last Call review by GENART is assigned to Jari Arkko
2019-04-04
23 Jean Mahoney Request for Last Call review by GENART is assigned to Jari Arkko
2019-04-03
23 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2019-04-03
23 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2019-04-02
23 Wesley Eddy Request for Last Call review by TSVART Completed: Almost Ready. Reviewer: Wesley Eddy. Sent review to list.
2019-03-28
23 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Chris Lonvick.
2019-03-25
23 Min Ye Request for Last Call review by RTGDIR is assigned to Ravi Singh
2019-03-25
23 Min Ye Request for Last Call review by RTGDIR is assigned to Ravi Singh
2019-03-24
23 Magnus Westerlund Request for Last Call review by TSVART is assigned to Wesley Eddy
2019-03-24
23 Magnus Westerlund Request for Last Call review by TSVART is assigned to Wesley Eddy
2019-03-22
23 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2019-03-22
23 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2019-03-22
23 Alvaro Retana Requested Last Call review by RTGDIR
2019-03-22
23 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-03-22
23 Amy Vezza
The following Last Call announcement was sent out (ends 2019-04-12):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, draft-ietf-netconf-subscribed-notifications@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net …
The following Last Call announcement was sent out (ends 2019-04-12):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, draft-ietf-netconf-subscribed-notifications@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Subscription to YANG Event Notifications) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'Subscription to YANG Event
Notifications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model and associated mechanisms
  enabling subscriber-specific subscriptions to a publisher's event
  streams.  Applying these elements allows a subscriber to request for
  and receive a continuous, custom feed of publisher generated
  information.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-03-22
23 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-03-22
23 Amy Vezza Last call announcement was changed
2019-03-22
23 Alissa Cooper Last call was requested
2019-03-22
23 Alissa Cooper Last call announcement was generated
2019-03-22
23 Alissa Cooper Ballot approval text was generated
2019-03-22
23 Alissa Cooper Ballot writeup was generated
2019-03-22
23 Alissa Cooper IESG state changed to Last Call Requested from Publication Requested
2019-02-26
23 Kent Watsen
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

[SHEPHERD] This document is a Proposed Standard document, and is
indicated in the title page as a "Standards Track" document.  This
is the proper designation for this RFC by WG consensus.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.


[SHEPHERD]  From the Abstract:

  This document defines a YANG data model and associated mechanisms
  enabling subscriber-specific subscriptions to a publisher's event
  streams.  Applying these elements allows a subscriber to request for
  and receive a continuous, custom feed of publisher generated
  information.

[SHEPHERD] From the Introduction:

  This document defines a YANG data model and associated mechanisms
  enabling subscriber-specific subscriptions to a publisher's event
  streams.  Effectively this enables a 'subscribe then publish'
  capability where the customized information needs and access

  permissions of each target receiver are understood by the publisher
  before subscribed event records are marshaled and pushed.  The
  receiver then gets a continuous, custom feed of publisher generated
  information.

  While the functionality defined in this document is transport-
  agnostic, transports like NETCONF [RFC6241] or RESTCONF [RFC8040] can
  be used to configure or dynamically signal subscriptions, and there
  are bindings defined for subscribed event record delivery for NETCONF
  within [I-D.draft-ietf-netconf-netconf-event-notifications], and for
  RESTCONF within [I-D.draft-ietf-netconf-restconf-notif].

  The YANG model in this document conforms to the Network Management
  Datastore Architecture defined in [RFC8342].


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?


[SHEPHERD] Nothing in the process is worth noting.  No decisions
were particularly rough.  There was a debate as to if this
RFC should define support for *configured* subscriptions, in
additional to dynamic subscriptions; in the end, the WG consensus
was to define support for configured subscriptions in this draft,
but to NOT define support for configured subscriptions in the
two drafts that complete the model (draft-ietf-netconf-restconf-notif
and draft-ietf-netconf-event-notifications).


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

[SHEPHERD] Apparently (not confirmed), this work has been
implemented in the OpenDayLight SDN controller.  This document
just went through a post-LC YANG Doctor review (all issues
raised were addressed):

https://datatracker.ietf.org/doc/review-ietf-netconf-subscribed-notifications-21-yangdoctors-lc-bierman-2019-01-14/


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

[SHEPHERD] The Document Shepherd is Kent Watsen.  The
Responsible Area Director is Ignas Bagdonas.   


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

[SHEPHERD] The shepherd has reviewed emails on the list, and tested
against `idnits`, and validated the YANG modules using both `pyang`
and `yanglint`.  The shepherd is comfortable with forwarding the
document to the IESG at this time.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

[SHEPHERD] The Shepherd has no concerns about the depth or breadth
of the reviews that have been performed.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

[SHEPHERD] No review from a particular or from broader perspective is
required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

[SHEPHERD] There are no specific concerns or issues that the Responsible
Area Director and/or the IESG should be aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

[SHEPHERD] Each author has just confirmed that any and all appropriate
IPR disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed.  Here is the thread:
https://mailarchive.ietf.org/arch/msg/netconf/pMdfD8tKMoV42nuwl3nKTOCrRZk.
Note: Alberto sent his response on on Feb 19, though it does not show
up in the mail archive...


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

[SHEPHERD] No IPR disclosure been filed that references this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

[SHEPHERD] Generally solid, with many being interested in and reviewing
this work. 


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[SHEPHERD] No one has threatened an appeal or otherwise indicated
extreme discontent.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

[SHEPHERD]
  - several "weird spacing" false-positive warnings
  - one "obsolete normative reference" error: RFC 5246 (Obsoleted
    by RFC 8446)  [this will be fixed later]
  - one "possible downref" (XPATH), but it's okay


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

[SHEPHERD] The document was reviewed by the YANG doctor assigned to it.


(13) Have all references within this document been identified as
either normative or informative?

[SHEPHERD] Yes, all references within this document been identified
as either normative or informative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

[SHEPHERD] as mentioned above, RFC5246 is obsoleted by RFC8446 needs
to be replaced by RFC8446 in the normative references section. 
Otherwise, the only quazi-questionable normative reference is to
draft-ietf-netconf-subscribed-notifications, which is being submitted
to the IESG at the same time as this draft.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

[SHEPHERD] There are no downward normative references.  IDNITS warns
about a possible downref to non-RFC "XPATH", but it is okay.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

[SHEPHERD] The publication of this document will not change the status
of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

[SHEPHERD] The shepherd has reviewed the IANA Considerations section.
The document registers one URI and one YANG module. The registries
for each of them have been identified in the document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

[SHEPHERD] There are no new IANA registries that require Expert review
for future allocations.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

[SHEPHERD] `pyang` and `yanglint` were used to validate the YANG module
defined in this document.  Note that Datatracker shows YANG validation
errors, but the module validates fine on my machine (I'm using yanglint
0.16.110, whereas DataTracker is using yanglint 0.14.80).
2019-02-26
23 Kent Watsen Responsible AD changed to Ignas Bagdonas
2019-02-26
23 Kent Watsen IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-02-26
23 Kent Watsen IESG state changed to Publication Requested from I-D Exists
2019-02-26
23 Kent Watsen IESG process started in state Publication Requested
2019-02-26
23 Kent Watsen
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

[SHEPHERD] This document is a Proposed Standard document, and is
indicated in the title page as a "Standards Track" document.  This
is the proper designation for this RFC by WG consensus.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.


[SHEPHERD]  From the Abstract:

  This document defines a YANG data model and associated mechanisms
  enabling subscriber-specific subscriptions to a publisher's event
  streams.  Applying these elements allows a subscriber to request for
  and receive a continuous, custom feed of publisher generated
  information.

[SHEPHERD] From the Introduction:

  This document defines a YANG data model and associated mechanisms
  enabling subscriber-specific subscriptions to a publisher's event
  streams.  Effectively this enables a 'subscribe then publish'
  capability where the customized information needs and access

  permissions of each target receiver are understood by the publisher
  before subscribed event records are marshaled and pushed.  The
  receiver then gets a continuous, custom feed of publisher generated
  information.

  While the functionality defined in this document is transport-
  agnostic, transports like NETCONF [RFC6241] or RESTCONF [RFC8040] can
  be used to configure or dynamically signal subscriptions, and there
  are bindings defined for subscribed event record delivery for NETCONF
  within [I-D.draft-ietf-netconf-netconf-event-notifications], and for
  RESTCONF within [I-D.draft-ietf-netconf-restconf-notif].

  The YANG model in this document conforms to the Network Management
  Datastore Architecture defined in [RFC8342].


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?


[SHEPHERD] Nothing in the process is worth noting.  No decisions
were particularly rough.  There was a debate as to if this
RFC should define support for *configured* subscriptions, in
additional to dynamic subscriptions; in the end, the WG consensus
was to define support for configured subscriptions in this draft,
but to NOT define support for configured subscriptions in the
two drafts that complete the model (draft-ietf-netconf-restconf-notif
and draft-ietf-netconf-event-notifications).


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

[SHEPHERD] Apparently (not confirmed), this work has been
implemented in the OpenDayLight SDN controller.  This document
just went through a post-LC YANG Doctor review (all issues
raised were addressed):

https://datatracker.ietf.org/doc/review-ietf-netconf-subscribed-notifications-21-yangdoctors-lc-bierman-2019-01-14/


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

[SHEPHERD] The Document Shepherd is Kent Watsen.  The
Responsible Area Director is Ignas Bagdonas.   


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

[SHEPHERD] The shepherd has reviewed emails on the list, and tested
against `idnits`, and validated the YANG modules using both `pyang`
and `yanglint`.  The shepherd is comfortable with forwarding the
document to the IESG at this time.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

[SHEPHERD] The Shepherd has no concerns about the depth or breadth
of the reviews that have been performed.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

[SHEPHERD] No review from a particular or from broader perspective is
required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

[SHEPHERD] There are no specific concerns or issues that the Responsible
Area Director and/or the IESG should be aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

[SHEPHERD] Each author has just confirmed that any and all appropriate
IPR disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed.  Here is the thread:
https://mailarchive.ietf.org/arch/msg/netconf/pMdfD8tKMoV42nuwl3nKTOCrRZk.
Note: Alberto sent his response on on Feb 19, though it does not show
up in the mail archive...


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

[SHEPHERD] No IPR disclosure been filed that references this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

[SHEPHERD] Generally solid, with many being interested in and reviewing
this work. 


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[SHEPHERD] No one has threatened an appeal or otherwise indicated
extreme discontent.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

[SHEPHERD]
  - several "weird spacing" false-positive warnings
  - one "obsolete normative reference" error: RFC 5246 (Obsoleted
    by RFC 8446)  [this will be fixed later]
  - one "possible downref" (XPATH), but it's okay


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

[SHEPHERD] The document was reviewed by the YANG doctor assigned to it.


(13) Have all references within this document been identified as
either normative or informative?

[SHEPHERD] Yes, all references within this document been identified
as either normative or informative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

[SHEPHERD] as mentioned above, RFC5246 is obsoleted by RFC8446 needs
to be replaced by RFC8446 in the normative references section. 
Otherwise, the only quazi-questionable normative reference is to
draft-ietf-netconf-subscribed-notifications, which is being submitted
to the IESG at the same time as this draft.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

[SHEPHERD] There are no downward normative references.  IDNITS warns
about a possible downref to non-RFC "XPATH", but it is okay.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

[SHEPHERD] The publication of this document will not change the status
of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

[SHEPHERD] The shepherd has reviewed the IANA Considerations section.
The document registers one URI and one YANG module. The registries
for each of them have been identified in the document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

[SHEPHERD] There are no new IANA registries that require Expert review
for future allocations.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

[SHEPHERD] `pyang` and `yanglint` were used to validate the YANG module
defined in this document.  Note that Datatracker shows YANG validation
errors, but the module validates fine on my machine (I'm using yanglint
0.16.110, whereas DataTracker is using yanglint 0.14.80).
2019-02-15
23 Kent Watsen Notification list changed to Kent Watsen <kent+ietf@watsen.net>
2019-02-15
23 Kent Watsen Document shepherd changed to Kent Watsen
2019-02-13
23 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-23.txt
2019-02-13
23 (System) New version approved
2019-02-13
23 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2019-02-13
23 Eric Voit Uploaded new revision
2019-01-23
22 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-22.txt
2019-01-23
22 (System) New version approved
2019-01-23
22 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2019-01-23
22 Eric Voit Uploaded new revision
2019-01-14
21 Andy Bierman Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Andy Bierman. Sent review to list.
2019-01-09
21 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-21.txt
2019-01-09
21 (System) New version approved
2019-01-09
21 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2019-01-09
21 Eric Voit Uploaded new revision
2018-12-19
20 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-20.txt
2018-12-19
20 (System) New version approved
2018-12-19
20 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2018-12-19
20 Eric Voit Uploaded new revision
2018-12-19
19 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman
2018-12-19
19 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman
2018-12-18
19 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-19.txt
2018-12-18
19 (System) New version approved
2018-12-18
19 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2018-12-18
19 Eric Voit Uploaded new revision
2018-12-18
18 Kent Watsen Requested Last Call review by YANGDOCTORS
2018-10-26
18 Kent Watsen IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-10-23
18 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-18.txt
2018-10-23
18 (System) New version approved
2018-10-23
18 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2018-10-23
18 Eric Voit Uploaded new revision
2018-09-28
17 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-17.txt
2018-09-28
17 (System) New version approved
2018-09-28
17 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2018-09-28
17 Eric Voit Uploaded new revision
2018-08-15
16 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-16.txt
2018-08-15
16 (System) New version approved
2018-08-15
16 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto
2018-08-15
16 Eric Voit Uploaded new revision
2018-08-03
15 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-15.txt
2018-08-03
15 (System) New version approved
2018-08-03
15 (System) Request for posting confirmation emailed to previous authors: netconf-chairs@ietf.org, Alexander Clemm , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard
2018-08-03
15 Eric Voit Uploaded new revision
2018-07-02
14 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-14.txt
2018-07-02
14 (System) New version approved
2018-07-02
14 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2018-07-02
14 Eric Voit Uploaded new revision
2018-06-18
13 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-13.txt
2018-06-18
13 (System) New version approved
2018-06-18
13 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2018-06-18
13 Eric Voit Uploaded new revision
2018-04-16
12 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-12.txt
2018-04-16
12 (System) New version approved
2018-04-16
12 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2018-04-16
12 Eric Voit Uploaded new revision
2018-04-06
11 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-11.txt
2018-04-06
11 (System) New version approved
2018-04-06
11 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2018-04-06
11 Eric Voit Uploaded new revision
2018-03-15
10 Andy Bierman Request for Last Call review by YANGDOCTORS Completed: Almost Ready. Reviewer: Andy Bierman. Sent review to list.
2018-03-08
10 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman
2018-03-08
10 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman
2018-03-07
10 Kent Watsen Requested Last Call review by YANGDOCTORS
2018-03-07
10 Kent Watsen IETF WG state changed to In WG Last Call from WG Document
2018-03-07
10 Kent Watsen Changed consensus to Yes from Unknown
2018-03-07
10 Kent Watsen Intended Status changed to Proposed Standard from None
2018-02-23
10 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-10.txt
2018-02-23
10 (System) New version approved
2018-02-23
10 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2018-02-23
10 Eric Voit Uploaded new revision
2018-01-25
09 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-09.txt
2018-01-25
09 (System) New version approved
2018-01-25
09 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2018-01-25
09 Eric Voit Uploaded new revision
2017-12-22
08 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-08.txt
2017-12-22
08 (System) New version approved
2017-12-22
08 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2017-12-22
08 Eric Voit Uploaded new revision
2017-10-30
07 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-07.txt
2017-10-30
07 (System) New version approved
2017-10-30
07 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2017-10-30
07 Eric Voit Uploaded new revision
2017-10-27
06 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-06.txt
2017-10-27
06 (System) New version approved
2017-10-27
06 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2017-10-27
06 Eric Voit Uploaded new revision
2017-10-03
05 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-05.txt
2017-10-03
05 (System) New version approved
2017-10-03
05 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2017-10-03
05 Eric Voit Uploaded new revision
2017-09-19
04 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-04.txt
2017-09-19
04 (System) New version approved
2017-09-19
04 (System) Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard
2017-09-19
04 Eric Voit Uploaded new revision
2017-07-02
03 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-03.txt
2017-07-02
03 (System) New version approved
2017-07-02
03 (System) Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard
2017-07-02
03 Eric Voit Uploaded new revision
2017-04-20
02 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-02.txt
2017-04-20
02 (System) New version approved
2017-04-20
02 (System) Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard
2017-04-20
02 Eric Voit Uploaded new revision
2017-04-14
01 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-01.txt
2017-04-14
01 (System) New version approved
2017-04-14
01 (System) Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard
2017-04-14
01 Eric Voit Uploaded new revision
2017-03-15
00 Mahesh Jethanandani Added to session: IETF-98: netconf  Tue-1640
2017-02-23
00 Mahesh Jethanandani This document now replaces draft-ietf-netconf-rfc5277bis instead of None
2017-02-23
00 Eric Voit New version available: draft-ietf-netconf-subscribed-notifications-00.txt
2017-02-23
00 (System) WG -00 approved
2017-02-23
00 Eric Voit Set submitter to "Eric Voit ", replaces to draft-ietf-netconf-rfc5277bis and sent approval email to group chairs: netconf-chairs@ietf.org
2017-02-23
00 Eric Voit Uploaded new revision