Subscription to YANG Notifications for Datastore Updates
draft-ietf-netconf-yang-push-25

Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Andy Bierman , Alexander Clemm , Balazs Lengyel , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

[Ballot comment]
Also, there are some changes suggested by the YANG doctor review, which seem relevant.

I found text about YANG validation in the document shepherd's write-up, so I cleared on this point.

[Ballot discuss]
YANG validation reports the following errors:

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.
err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" failed.
err : Module "ietf-yang-push" parsing failed.

Are these real problems or are these errors in the validation tool?

[Ballot discuss]
Note that I reviewed the -22 and the current version is -23.  Briefly
skimming the diff, it seems that some changes touch on points I make in
my review, but there is probably still discussion to have on them.

(pro-forma) I see the GenArt reviewer noted the author count (seven)
already, but I couldn't find a response or note in the ballot or
shephert writeup acknowledging this.  So failing that, I'll put up a
discuss point until the responsible AD says it's fine.

[See also discussion on draft-ietf-netconf-subscribed notifications
about the pre-RFC5378 boilerplate and whether or not it can be removed
from this document]

Section 3.3 states:

            In order for a subscriber to determine whether objects
  support on-change subscriptions, objects are marked accordingly on a
  publisher.  Accordingly, when subscribing, it is the responsibility
  of the subscriber to ensure it is aware of which objects support on-
  change and which do not.  For more on how objects are so marked, see
  Section 3.10.

Chasing the reference, we see that this marking is left for future work
or implementation-specific usage.  I'm not very comfortable with the way
we are describing this situation, as it seems pretty fragile in the face
of different implementations trying to interoperate.

[Ballot comment]
Thank you for the very thoughtful document!  I've lost track of the
number of places where I started writing a comment only to note that my
concern had already been addressed in the following text.  In general
the writing style is great, though I did find some grammar and clarity
nits (noted inline).

Abstract

              Providing such visibility into updates enables new
  capabilities based on the remote mirroring and monitoring of
  configuration and operational state.

This phrasing ("new capabilities based on") is hard for me to follow,
particularly about whether these are protocol-level capabilities and
what actors are granted the new capabilities.

Section 1

  Traditional approaches to providing visibility into managed entities
  from remote have been built on polling.  [...]

nit: "remote" is an adjective and needs a noun to bind to; "from remote
systems", "from remote vantages", or "from afar" would all be fine
wordings here.

  o  Polling incurs significant latency.  This latency prohibits many
      application types.

nit: I'd suggest wording as "types of application", since on my first
reading I thought this was referring to some sort of codepoint.

  o  Polling cycles may be missed, requests may be delayed or get lost,
      often when the network is under stress and the need for the data
      is the greatest.

nit: the grammar is a bit weird, here, as if a comma splice.  I think
replacing the first comma with a colon or em dash would suffice.

  o  Datastore node update: A data item containing the current value of
      a datastore node at the time the datastore node update was
      created, as well as the path to the datastore node.

Is this storing the "new" or the "old" value as the "current value"?

Section 3.1

        +  Dampening period: In an on-change subscription, detected
            [...]
            is included.  The dampening period goes into effect every
            time an update record completes assembly.

Just to double-check: this means that after a long hiatus, the first
change to the monitored subtree(s) triggers an immediate push with just
the single update, and only then does the dampening period kick in and
defer delivery of potential subsequent updates?

Section 3.5.2

This bit about the "create" and "delete" errors from RFC 8072 Section
2.5 not being errors in our usage is a little interesting, process-wise.
In one sense, we are changing the semantics of an already published RFC,
and would need to apply an "Updates:" relationship to indicate that, but
in the other sense we are building a new custom thing that reuses a lot
of the syntax/semantics of YANG patch but is fundamentally a new
(different) thing.  The phrasing we use to talk about it can affect
which case the reader perceives us to be in...

The discussion on the "change-type" enumeration seems to pretty clearly
place us in the latter case, which is good.

Section 3.6

Thank you for the note about the power of XPath expressions and the duty
of the receiver to understand what it's asking for -- that sort of
statement would potentially even be appropriate in the Security
Considerations (but is fine where it is)!

Section 3.7

  Of note in the above example is the 'patch-id' with a value of '0'.
  Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG
  Push, the publisher SHOULD put into the 'patch-id' a counter starting
  at '0' which increments with every 'push-change-update' generated for
  a subscription.  If used as a counter, this counter MUST be reset to
  '0' anytime a resynchronization occurs (i.e., with the sending of a
  'push-update').  Also if used as a counter, the counter MUST be reset
  to '0' after passing a maximum value of '4294967295' (i.e. maximum
  value that can be represented using uint32 data type).  Such a
  mechanism allows easy identification of lost or out-of-sequence
  update records.

It's not really clear to me how much value there is in this counter
mechanism if the client' can't rely on the server's behavior actually
being to use a counter (the requirement is only "SHOULD").  Can this be
a "MUST" (or maybe "MUST excpet when [...]") instead?

Section 3.9

                                                          Empty "push-
  change-update" messages (in case of an on-change subscription) MUST
  NOT be sent.  This is required to ensure that clients cannot
  surreptitiously monitor objects that they do not have access to via
  carefully crafted selection filters.  By the same token, changes to
  objects that are filtered MUST NOT affect any dampening intervals.

I appreciate this attention to security-relevant detail; thank you!

Section 3.11.1

Do we want to give any guidance for the "incomplete-update" case about
whether a subscriber should wait and give the publisher a chance to
provide a full "push-update" for resynchronization (per Section 4.3.2)
versus perform a normal query for the datastore contents and
effectuating its own resynchronization?

Section 4.2

  o  For on-change subscriptions, assuming any dampening period has
      completed, triggering occurs whenever a change in the subscribed
      information is detected.  On-change subscriptions have more
      complex semantics that is guided by its own set of parameters:

nit: singular/plural mismatch "semantics"/"is"

Section 4.3.2


  A "time-of-update" which represents the time an update record
  snapshot was generated.  A receiver MAY assume that at this point in
  time a publisher's objects have the values that were pushed.

nit: I think "had the values" (past tense) is more appropriate.

Section 4.4.1

  a publisher that cannot serve on-change updates but periodic updates
  might return the following NETCONF response:

nit: "but can serve periodic updates"

Section 4.4.2

  The specific parameters to be returned in as part of the RPC error
  response depend on the specific transport that is used to manage the
  subscription.  For NETCONF, those parameters are specified in
  [I-D.draft-ietf-netconf-netconf-event-notifications].

nit: "in" and "as part of" are redundant.

Section 5

It is slightly interesting to note that (apparently) the
update-policy-modifiable grouping allows for a subscription to switch
between periodic and triggered at runtime (by virtue of wanting a single
grouping to cover all the cases and needing to be able to modify the
parameters for each case).  I would mostly expect implementations to
deny such modification requests due to the needed complexity, but I'm
also not sure that there's a need to mention this explicitly in the
document.

            leaf period {
              type centiseconds;
              mandatory true;
              description
                "Duration of time which should occur between periodic
                push updates, in one hundredths of a second.";

It would probably be okay to skip "in one hundredths of a second" given
the usage of the centiseconds typedef.

    rc:yang-data resync-subscription-error {
      container resync-subscription-error {
        description
          "If a 'resync-subscription' RPC fails, the subscription is
          not resynced and the RPC error response MUST indicate the
          reason for this failure.  This yang-data MAY be inserted as
          structured data within a subscription's RPC error response
          to indicate the failure reason.";

It's a little weird to have the normative language here constraining the
RPC error response that must be returned for a specific RPC, since this
is not the description of that RPC.  (It's probably also duplicating
langauge elsewhere but I didn't double-check.)

    rc:yang-data establish-subscription-datastore-error-info {
      container establish-subscription-datastore-error-info {
        description
          "If any 'establish-subscription' RPC parameters are
          unsupportable against the datastore, a subscription is not
          created and the RPC error response MUST indicate the reason
          why the subscription failed to be created.  This yang-data
          MAY be inserted as structured data within a subscription's
          RPC error response to indicate the failure reason.  This
          yang-data MUST be inserted if hints are to be provided back
          to the subscriber.";

(ditto)

Contrast to modify-subscription-datastore-error-info, which only has
normative language about the yang-data being described and not the RPCs
that (might) use it.


nit: push-update and push-change-update use different langauge about
"does not constitute a general-purpose notification" and I'm not sure
there's a reason to diverge.
Their "incomplete-update" leaves also have divergent descriptions, but I
think that latter divergence is more reasonable.

    augment "/sn:subscription-modified/sn:target" {
      [...]
      case datastore {
        uses datastore-criteria {
          refine "selection-filter/within-subscription" {
            description
              "Specifies where the selection filter, and where it came
              from within the subscription and then populated within
              this notification.  If the 'selection-filter-ref' is

nit: "where the selection filter" seems like an incomplete clause.

[Ballot comment]
Per Section 3.7:
-- Is the re-synchronization behavior/value of patch-id different with dynamic vs. configured subscriptions, especially if the publisher crashed or lost the connection?

-- I’d recommend being explicit about the value by which patch-id gets incremented (1?) so that there won’t be ambiguity on the lost/out-of-sequence detection.

Request for posting confirmation emailed to previous authors: Alberto Prieto , Andy Bierman , Alexander Clemm , Balazs Lengyel , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

[Ballot comment]
A small comment/question mostly regarding section 3.4:
I wondering what happens if the system crashes or is in a state where not even a notification can be sent anymore...? Is the assumption that a crash could be detected because the transport connection  goes away? However, that would mean that there is requirement that the transport must be connection-oriented and maybe also support some kind of keep-alive mechanism. Given this document tries to be transport-agnostic (as it relies on I-D.draft-ietf-netconf-subscribed-notifications), I don't think that is a safe assumption and should at least be further discussed. My understanding was that I-D.draft-ietf-netconf-subscribed-notifications assumes an active connection for dynamic subscriptions, but I guess this does not have to be the case for a configured subscription...?

Also there seems to be an implicit assumption that the chosen transport is reliable in order for the system to work as expected. If that is the case, I think that it could be good to spelled that out in the document as a requirement as well. I guess all transports available today for YANG (NETCONF/RETSCONF) are reliable but that might not be the case in future.

[Ballot comment]
A small comment/question mostly regarding section 3.4:
I wondering what happens if the system crashes or is in a state where not even a notification can be sent anymore...? Or is the assumption that a crash could be detected because the transport connection  goes away? However, that would mean that there is requirement that the transport must be connection-oriented and maybe also support some kind of keep-alive mechanism. Hiven this document tries to be transport-agnostic, I don't think that is a safe assumption and should at least be further discussed.

Also there seems to be an implicit assumption that the chosen transport is reliable. If that is the case, I think that should the spelled out in the document as a requirement.

[Ballot comment]
This comment relates mostly to section 3.4, however, section 3.3 explicitly says:
"If the resulting patch record is non-empty, send it to the receiver."
I wonder if it could make sense to also indicate an empty record (if a dampening time is used), compared to not sending anything at all which could also mean the system crashed or whatever...? Or is the assumption that a crash could be detected because the transport connection  goes away? However, given this document tries to be transport-agnostic, I don't think that is a safe assumption and should at least be further discussed.

[Ballot comment]
Getting a streaming telemetry for changes in datastore appears quite useful.

Please note that I did not review in depth after the section 4.

Comments
--------

C1) Out of curiosity, it is surprising for a netconf wg document to have 7 errors indicated by the YANG validator. Are they real errors or is the `pyang` validator incorrect or missing references?

C2) 7 authors... the limit is usually 5 authors max. Can you justify?

C3) section 2. It should be RFC 8174 without citing RFC 2119.

C4) section 3.7, why not forcing a resynch (and a patch-id of 0) rather than simply rolling explicitly the patch-id to 0. The latter seems to me as prone to synchronization errors.

Nits
----

N1) unsure why all Cisco Systems authors are not grouped together

N2) "Xpath": should be described (or having a reference) before first use in section 3.6

N3) a couple of "yang" in lowercase while I believe "YANG" is always written in uppercase

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netconf-yang-push-22. 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-yang-push
URI: urn:ietf:params:xml:ns:yang:ietf-yang-push
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-yang-push
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-push
Prefix: yp
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

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-yang-push@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 Datastores) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'Subscription to YANG Datastores'
  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


  Via the mechanism described in this document, subscriber applications
  may request a continuous, customized stream of updates from a YANG
  datastore.  Providing such visibility into updates enables new
  capabilities based on the remote mirroring and monitoring of
  configuration and operational state.




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

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


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

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:

  Via the mechanism described in this document, subscriber applications
  may request a continuous, customized stream of updates from a YANG
  datastore.  Providing such visibility into updates enables new
  capabilities based on the remote mirroring and monitoring of
  configuration and operational state.

[SHEPHERD] From the Introduction:

  Traditional approaches to providing visibility into managed entities
  from remote have been built on polling.  With polling, data is
  periodically requested and retrieved by a client from a server to
  stay up-to-date.  However, there are issues associated with polling-
  based management:

  o  Polling incurs significant latency.  This latency prohibits many
      application types.

  o  Polling cycles may be missed, requests may be delayed or get lost,
      often when the network is under stress and the need for the data
      is the greatest.

  o  Polling requests may undergo slight fluctuations, resulting in
      intervals of different lengths.  The resulting data is difficult
      to calibrate and compare.

  o  For applications that monitor for changes, many remote polling
      cycles place unwanted and ultimately wasteful load on the network,
      devices, and applications, particularly when changes occur only
      infrequently.

  A more effective alternative to polling is for an application to
  receive automatic and continuous updates from a targeted subset of a
  datastore.  Accordingly, there is a need for a service that allows
  applications to subscribe to updates from a datastore and that
  enables the server (also referred to as publisher) to push and in
  effect stream those updates.  The requirements for such a service
  have been documented in [RFC7923].

  This document defines a corresponding solution that is built on top
  of "Custom Subscription to Event Streams"
  [I-D.draft-ietf-netconf-subscribed-notifications].  Supplementing
  that work are YANG data model augmentations, extended RPCs, and new
  datastore specific update notifications.  Transport options for
  [I-D.draft-ietf-netconf-subscribed-notifications] will work
  seamlessly with this solution.


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.


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-yang-push-21-yangdoctors-lc-bjorklund-2019-01-30/


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/rAppo72ya1OLqLwz2cvWDJa9N-U.


(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 positives warnings
  - one "unexpected reference format" ([RFC8343]'s), which RFC Editor
    should catch - one "outdated ref": SN-22 --> SN-23
  - one "Couldn't figure out when the document was first submitted"
    and related "document seems to contain a disclaimer for pre-RFC5378
    work" warnings


(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] The only quazi-questionable normative references 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.


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

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:

  Via the mechanism described in this document, subscriber applications
  may request a continuous, customized stream of updates from a YANG
  datastore.  Providing such visibility into updates enables new
  capabilities based on the remote mirroring and monitoring of
  configuration and operational state.

[SHEPHERD] From the Introduction:

  Traditional approaches to providing visibility into managed entities
  from remote have been built on polling.  With polling, data is
  periodically requested and retrieved by a client from a server to
  stay up-to-date.  However, there are issues associated with polling-
  based management:

  o  Polling incurs significant latency.  This latency prohibits many
      application types.

  o  Polling cycles may be missed, requests may be delayed or get lost,
      often when the network is under stress and the need for the data
      is the greatest.

  o  Polling requests may undergo slight fluctuations, resulting in
      intervals of different lengths.  The resulting data is difficult
      to calibrate and compare.

  o  For applications that monitor for changes, many remote polling
      cycles place unwanted and ultimately wasteful load on the network,
      devices, and applications, particularly when changes occur only
      infrequently.

  A more effective alternative to polling is for an application to
  receive automatic and continuous updates from a targeted subset of a
  datastore.  Accordingly, there is a need for a service that allows
  applications to subscribe to updates from a datastore and that
  enables the server (also referred to as publisher) to push and in
  effect stream those updates.  The requirements for such a service
  have been documented in [RFC7923].

  This document defines a corresponding solution that is built on top
  of "Custom Subscription to Event Streams"
  [I-D.draft-ietf-netconf-subscribed-notifications].  Supplementing
  that work are YANG data model augmentations, extended RPCs, and new
  datastore specific update notifications.  Transport options for
  [I-D.draft-ietf-netconf-subscribed-notifications] will work
  seamlessly with this solution.


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.


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-yang-push-21-yangdoctors-lc-bjorklund-2019-01-30/


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/rAppo72ya1OLqLwz2cvWDJa9N-U.


(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 positives warnings
  - one "unexpected reference format" ([RFC8343]'s), which RFC Editor
    should catch - one "outdated ref": SN-22 --> SN-23
  - one "Couldn't figure out when the document was first submitted"
    and related "document seems to contain a disclaimer for pre-RFC5378
    work" warnings


(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] The only quazi-questionable normative references 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.


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

Request for posting confirmation emailed to previous authors: Alberto Prieto , Andy Bierman , Alexander Clemm , Balazs Lengyel , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: netconf-chairs@ietf.org, Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Andy Bierman , Alexander Clemm , Balazs Lengyel , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Andy Bierman , Alexander Clemm , Balazs Lengyel , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Andy Bierman , Alexander Clemm , Balazs Lengyel , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Andy Bierman , Alexander Clemm , Balazs Lengyel , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard

Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Andy Bierman , Balazs Lengyel , Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard