Dynamic Subscription to YANG Events and Datastores over RESTCONF
draft-ietf-netconf-restconf-notif-15

[Ballot comment]
Section 4:

Based on the QoS discussion for draft-ietf-netconf-subscribed-notifications weight is not really a a priority in the terms people think of it. It only provides a weight for bandwidth allocation.

  o  take any existing subscription "priority", as specified by the
      "weighting" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and copy it
      into the HTTP2 stream weight, [RFC7540] section 5.3, and

I would recommend that the use of "priority" is reformualted here to reflect that aspect.


  o  take any existing subscription "dependency", as specified by the
      "dependency" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and use the
      HTTP2 stream for the parent subscription as the HTTP2 stream
      dependency, [RFC7540] section 5.3.1, of the dependent
      subscription.

What is not obivous to me is that just because that a subscription exists at the publisher that it is going over the same HTTP/2 connection and thus there might be nothing for the dependency to point at that is relevant for the mechanism described in RFC 7540. I didn't even find a recommendation that the receiver (subscriber) should actually re-use the HTTP/2 connection for all communication with the same publisher.

[Ballot discuss]
Per Section 9, [draft-ietf-netconf-netconf-event-notifications] and [draft-ietf-netconf-subscribed-notifications] mention concerns about a “malicious or buggy subscriber sends a number of establish-subscription requests” in their Security Considerations.  Is that not a concern here too?

[Ballot comment]
(1) Section 3.1.  “A subscriber can then attempt to re-establish the dynamic subscription by using the procedure described in Section 3.”  This seems like a circular reference.  This guidance (to go read Section 3) is being given in Section 3.1 (which is inside Section 3).

(2) Section 3.3.  Missing word.
s/requests with publisher/requests with the publisher/

(3) Section 3.4.  “This initiates the publisher to initiate the flow …”.  I stumbled over the double use of “initiate”.  Do you mean “This signals to the publisher to initiate the flow …”?

(4) Section 3.4 suggests that NACM/related methods should be used to authorize “modify-subscription, resync-subscription and delete-subscription” RPCs.  Section 9, Security Considerations, says “Therefore, even if an attacker succeeds in guessing the subscription URI, a RESTCONF username [RFC8040] with the required administrative permissions must be used to be able to access or  modify that subscription.”  Is there a reason not to say the obvious thing in the Security Considerations that these particular RPCs should be protected (with NACM/related methods like was stated in Section 3.4).

[Ballot discuss]
Thanks for all the work that the authors and other contributors have
put into this document. I have two comments that need to be addressed
before publication, but they should both be very easy to fix.

---------------------------------------------------------------------------


§3.3:

>  If a publisher fails to serve the RPC request for one of the reasons
>  indicated in [I-D.draft-ietf-netconf-subscribed-notifications]
>  Section 2.4.6 or [I-D.ietf-netconf-yang-push] Appendix A, this will
>  be indicated by "406" status code transported in the HTTP response.

This really isn't what 406 means. 406 means "you sent one or more of the
'Accept', 'Accept-Charset', 'Accept-Encoding', or 'Accept-Language' header
fields, and I can't generate a response that satisfies what you've asked for."

For some of the errors listed in the two cited sections, there is a reasonable
semantic mapping onto existing HTTP response codes; e.g. the
"no-such-subscription" errors could all reasonably map on to HTTP 404.  I'll
note that RFC 8040 section 7 performs exactly this kind of mapping, so the
approach seems to be consistent with the way that RESTCONF has elected to use
HTTP response codes. In fact, this document already maps from the cited errors
to error tags already, and that table maps from error-tag to
HTTP response codes, so fixing this should be the relatively straightforward
exercise of updaing the tables in this section to also include the HTTP response
code that RFC 8040 maps to the indicated error-tag. For example:

    error identity        uses error-tag            HTTP Response
    ---------------------- --------------            -------------
    dscp-unavailable      invalid-value              400
    encoding-unsupported  invalid-value              400
    filter-unsupported    invalid-value              400
    insufficient-resources resource-denied            409
    no-such-subscription  invalid-value              404
    replay-unsupported    operation-not-supported    501

    error identity              uses error-tag          HTTP Response
    ----------------------      --------------          -------------
    cant-exclude                operation-not-supported 501
    datastore-not-subscribable  invalid-value          400
    no-such-subscription-resync invalid-value          404
    on-change-unsupported      operation-not-supported 501
    on-change-sync-unsupported  operation-not-supported 501
    period-unsupported          invalid-value          400
    update-too-big              too-big                400
    sync-too-big                too-big                400
    unchanging-selection        operation-failed        500

However you choose to address this, if the error isn't related to any of the
four header fields I mention above, then you can't specify the use of a 406.

---------------------------------------------------------------------------

§3.4:

This section is unclear about how Server-Sent Events are to be used (in
particular, they don't say anything about event type to be used). Based on the
one example in Appendix A that shows SSE syntax, I'm assuming you probably do
not intend to use SSE "event type" fields to distinguish between events in any
way.  This would mean that you need to specify that all SSE messages are sent
with an event type of "message," which the server may omit (as it is the
default specified in the Server-Side Events specification).  This means that
clients will need to accept both:

data: {
data:  "ietf-restconf:notification" : {
data:    "eventTime": "2007-09-01T10:00:00Z",
data:    "ietf-subscribed-notifications:subscription-modified": {
data:      "id": "39",
data:      "uri": "https://example.com/restconf/subscriptions/22"
data:      "stream-xpath-filter": "/example-module:foo",
data:      "stream": {
data:          "ietf-netconf-subscribed-notifications" : "NETCONF"
data:      }
data:    }
data:  }
data: }

...and...

event: message
data: {
data:  "ietf-restconf:notification" : {
data:    "eventTime": "2007-09-01T10:00:00Z",
data:    "ietf-subscribed-notifications:subscription-modified": {
data:      "id": "39",
data:      "uri": "https://example.com/restconf/subscriptions/22"
data:      "stream-xpath-filter": "/example-module:foo",
data:      "stream": {
data:          "ietf-netconf-subscribed-notifications" : "NETCONF"
data:      }
data:    }
data:  }
data: }

It may be helpful to incorporate the SSE syntax into all of the notification
examples in Appendix A (that is, all of the examples in A.2 and A.3). I would
recommend a mix of examples with and without "event: message".

[Ballot comment]
General comment:

It's a bit unclear about what the normative relationship between a Server-Sent
Events connection and a subscription is intended to be. For example: if I send
an RPC command to create a subscription, and then make two different SSE
connections to the resulting URL, will they both receive events associated
with that subscription? If so, does a TLS heartbeat failure on one of them
cause the entire subscription to go away? (If not, what happens?)

If I have only one connection related to a subscription, and I close the TCP
connection, does that necessarily make the subscription go away? What if I
set up a new TCP connection right away after closing the first one? Will
that work?

What if I use RPC to set up a new subscription, and then wait a few minutes
before connecting to the subscription URL?

I don't think you need to answer all of these corner cases per se (although it
would be nice), but minimally a couple of statements that clearly spell out
the relationship between subscriptions and the connections used to deliver
related events would help implementors figure out the answers to these
questions.

---------------------------------------------------------------------------

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please use the boilerplate specified by RFC 8174.

---------------------------------------------------------------------------

§3.1:

>  As stated in Section 2.1 of [RFC8040], a subscriber MUST establish
>  the HTTP session over TLS [RFC5246] in order to secure the content in
>  transit.

Is the intention here to restrict clients to TLS 1.2? If not, please cite
RFC 8446 instead of RFC 5246. If so, please add text that explains why.

(This comment also applies to section 9)

---------------------------------------------------------------------------

§3.1:

>  Loss of the heartbeat MUST result in any subscription related TCP

nit: "...subcription-related..."

[Ballot comment]
= Section 9 =

"Access control must be set so that only someone
      with proper access permissions, and perhaps even HTTP session has
      the ability to access this resource."
   
There is a grammar error in this sentence -- "perhaps even HTTP session" doesn't follow from the antecedent.

[Ballot comment]
One question (and this is probably just because of my lack of detailed knowledge about RESTCONF):

Sec 4 says: "To meet subscription quality of service promises, the publisher MUST
  take any existing subscription "dscp" and apply it to the DSCP
  marking in the IP header."
What does "existing subscription "dscp"" mean here?

Related update: please also consider the comment from the TSV-ART review about the example DSCP value (Thanks Wes!). I actually would also appreciate to add a comment that this is an internal value that depends on the network configuration (in order to avoid that people just randomly copy this example value and suddenly always use 10)!

[Ballot comment]
One question (and this is probably just because of my lack of detailed knowledge about RESTCONF):

Sec 4 says: "To meet subscription quality of service promises, the publisher MUST
  take any existing subscription "dscp" and apply it to the DSCP
  marking in the IP header."
What does "existing subscription "dscp"" mean here?

[Ballot discuss]
Thanks for the well-written document!  I  just have some boring housecleaning
points that should be easy to resolve.

Section 3.2 states:

  Subscribers can learn what event streams a RESTCONF server supports
  by querying the "streams" container of ietf-subscribed-
  notification.yang in
  [I-D.draft-ietf-netconf-subscribed-notifications].  Support for the
  "streams" container of ietf-restconf-monitoring.yang in [RFC8040] is
  not required.  If it is supported, the event streams which are in the
  "streams" container of ietf-subscribed-notifications.yang SHOULD also
  be in the "streams" container of ietf-restconf-monitoring.yang.

This "SHOULD" seems to be attempting to impose a normative requirement
on specifications that implement
draft-ietf-netconf-subscribed-notifications and RFC 8040 streams,
without regard to whether they implement this specification.  It seems
better-placed in draft-ietf-netconf-subscribed-notifications.

Similarly, when Section 4 writes:

  To meet subscription quality of service promises, the publisher MUST
  take any existing subscription "dscp" and apply it to the DSCP
  marking in the IP header.

that seems to be duplicating a normative requirement from the core
subscribed-notifications document.  (And I'm sure Magnus will have
further follow-up about how DSCP markings are per-connection for the
stream transports we have available, as well.)

[Ballot comment]
The core subscribed-notifications document notes that dynamic
subscriptions only last as long as the underlying transport.  In this
document, we have two connections in Figure 1, which could potentially
be separate TCP/TLS connections (or HTTP/2 streams).  In the "two TCP
connections" case, does terminating either one cause the cessation of
the subscription, or just (b)?

Section 2

Please use the boilerplate from RFC 8174.

Section 3

                                      YANG datastore subscription is
  accomplished via augmentations to
  [I-D.draft-ietf-netconf-subscribed-notifications] as described within
  [I-D.ietf-netconf-yang-push] Section 4.4.

I see some reviewers commented that things were a bit terse/arcane; I
might suggest that "via augmentations to [subscribed notifications]" is
not really adding much here, and the yang-push RPCs are the important
part.

Section 3.1

                                                        Where quick
  recognition of the loss of a publisher is required, a subscriber
  SHOULD use a TLS heartbeat [RFC6520], just from receiver to
  publisher, to track HTTP session continuity.

TLS heartbeats require initiation by the TLS client, by virtue of
including the HeartbeatExtension in the ClientHello.  Who is going to be
making the determination that quick recognition is required, and if
that's the publisher, how does the subscriber know to use TLS
heartbeats?

nit: It's interesting that we seem to be using both "subscriber" and
"receiver" to talk about the TLS client, in the same sentence.

side note: per https://github.com/openssl/openssl/pull/1928, OpenSSL
will not support TLS or DTLS heartbeats of any form in its next major
release (3.0.0).

  Loss of the heartbeat MUST result in any subscription related TCP
  sessions between those endpoints being torn down.  A subscriber can
  then attempt to re-establish the dynamic subscription by using the
  procedure described in Section 3.

RFC 6520 does not specify retransmit numbers or intervals to be used to
determine that a peer is nonresponsive (i.e., "lost"), so this text
seems under-specified.  Is the intent to leave these decisions to be
implementation-specific?

Section 3.3

I see that draft-ietf-netconf-subscribed-notifications (section 2.4.6)
admonishes us to check for transport-layer errors (and ACLs!) before
RPC-level errors; is the text here about "fails to serve the RPC
request" and our description of error handling consistent with the
separate transport-layer error handling?  (I think it can be, with a
careful reading of "one of the reasons indicated in [] Section 2.4.6",
but perhaps other readings are possible.)

      The yang-data included within "error-info" SHOULD NOT include the
      optional leaf "error-reason", as such a leaf would be redundant
      with information that is already placed within the
      "error-app-tag".

I'm not sure where this "error-reason" leaf is defined -- I don't see it
in any of subscribed-notifications, yang-push, or RFC 8040.

Section 3.4

I'm not sure that I've previously encountered using the section heading
to introduce an acronym (as is done here for SSE).  I bet the RFC Editor
will do the right thing, though.

  o  In addition to an RPC response for a "modify-subscription" RPC
      traveling over (a), a "subscription-modified" state change
      notification MUST be sent within (b).  This allows the receiver to
      know exactly when the new terms of the subscription have been
      applied to the notification messages.  See arrow (c).

nit: I might suggest some language about "order within the notifications
stream" for this state change, but that's purely editorial.

  o  In addition to any required access permissions (e.g., NACM), RPCs
      modify-subscription, resync-subscription and delete-subscription
      SHOULD only be allowed by the same RESTCONF username [RFC8040]
      which invoked establish-subscription.

I'm confused about this "SHOULD" (the secdir reviewer noted it as well)
-- in my understanding, the core subscribed-notifications requires that
such RPCs must be done on the same transport connection as the one used
to create a dynamic subscription (i.e., line (a) in Figure 1), and since
RFC 8040 authenticated client identities are at the connection level,
there could never be any change of username across the calls.

  o  Loss of TLS heartbeat

(As noted above, this is under-specified at present.)

Section 9

I would suggest also recommending that the 'uri' values not have a
predictable structure or be guessable.  While we do have solid access
control in place via NACM/etc., there is still a risk of side-channel
leakage if there's a distinction between "resource does not exist" and
"not authorized".  (FYI we had a long discussion about unguessable URIs
in the context of draft-ietf-acme-acme, which had a much weaker
access-control story and could in some sense be said to use "capability
URIs", if anyone wants to do some background reading.)
(One might see also draft-gont-numeric-ids-sec-considerations.)

I see that the subscription-id type is only of type uint32 in
draft-ietf-netconf-subscribed-notifications, which to some extent limits
the unguessability property to the URIs and not as much for the IDs
themselves (though randomization within a 32-bit space is not without
value).

Appendix A

Consistent with my suggestion in the Security Considerations, I'd change
the returned URI here or at least note that the "22", "23", etc. are
placeholders and not indicative of expected usage.

(This snippet from A.1.1)

  {
      "ietf-subscribed-notifications:input": {
        "stream-xpath-filter": "/example-module:foo/",
        "stream": "NETCONF",
        "dscp": "10"
      }
  }

The ambiguity of "10" has been noted elsewhere, but since it's a uint8
(range "0..63") wouldn't it be a JSON number, not a JSON string?

Similarly, subscription IDs are uint32, which IIUC gets encoded as a
number.

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

The IANA Functions Operator has completed its review of draft-ietf-netconf-restconf-notif-13. 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-restconf-subscribed-notifications
URI: urn:ietf:params:xml:ns:yang:ietf-restconf-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-restconf-subscribed-notifications
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed-notifications
Prefix: rsn
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-restconf-notif@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Dynamic subscription to YANG Events and Datastores over RESTCONF) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'Dynamic subscription to YANG Events
and Datastores over RESTCONF'
  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 provides a RESTCONF binding to the dynamic subscription
  capability of both subscribed notifications and YANG-Push.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/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:

  This document provides a RESTCONF binding to the dynamic
  subscription capability of both subscribed notifications
  and YANG-Push.

[SHEPHERD] From the Introduction:

  Mechanisms to support event subscription and push are defined in
  [I-D.draft-ietf-netconf-subscribed-notifications].  Enhancements to
  [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG
  datastore subscription and push are defined in
  [I-D.ietf-netconf-yang-push].  This document provides a transport
  specification for dynamic subscriptions over RESTCONF [RFC8040].
  Driving these requirements is [RFC7923].


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, which it does support, but
the WG consensus was to add support for configured subscriptions
at a later time.


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] Unknown if there are any implementations of this
draft as yet.  This document just went through a post-LC
YANG Doctor review (all issues raised were addressed):

https://datatracker.ietf.org/doc/review-ietf-netconf-restconf-notif-11-yangdoctors-lc-wilton-2019-01-07/


Personnel

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

[SHEPHERD] The Document Shepherd is Kent Watsen, with Qin Wu's
assistance. 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-assistant found a number of issues
that have been resolved in the current version.  Both the shepherd
and the assistant are 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/gxToVCK4h3PLOZ7v-hTt4prJorI.

(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 false-positives: a few "weird spacing" and one
    "possible downref"
  - two "outdated ref" warnings: SN-21 --> SN-23 and YP-20 --> YP-22
  - one obsolete normative reference error: RFC 5246 (Obsoleted by
    RFC 8446) [this will be fixed later]


(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 references are to
draft-ietf-netconf-subscribed-notifications and ietf-netconf-yang-push,
which are 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 "W3C-20150203", 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).

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 provides a RESTCONF binding to the dynamic
  subscription capability of both subscribed notifications
  and YANG-Push.

[SHEPHERD] From the Introduction:

  Mechanisms to support event subscription and push are defined in
  [I-D.draft-ietf-netconf-subscribed-notifications].  Enhancements to
  [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG
  datastore subscription and push are defined in
  [I-D.ietf-netconf-yang-push].  This document provides a transport
  specification for dynamic subscriptions over RESTCONF [RFC8040].
  Driving these requirements is [RFC7923].


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 subcriptions, which it does support, but
the WG consensus was to add support for configured subscriptions
at a later time.


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] Unknown if there are any implementations of this
draft as yet.  This document just went through a post-LC
YANG Doctor review (all issues raised were addressed):

https://datatracker.ietf.org/doc/review-ietf-netconf-restconf-notif-11-yangdoctors-lc-wilton-2019-01-07/


Personnel

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

[SHEPHERD] The Document Shepherd is Kent Watsen, with Qin Wu's
assistance. 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-assistant found a number of issues
that have been resolved in the current version.  Both the shepherd
and the assistent are 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/gxToVCK4h3PLOZ7v-hTt4prJorI.

(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 summarise 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 false-positives: a few "weird spacing" and one
    "possible downref"
  - two "outdated ref" warnings: SN-21 --> SN-23 and YP-20 --> YP-22
  - one obsolete normative reference error: RFC 5246 (Obsoleted by
    RFC 8446) [this will be fixed later]


(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 references are to
draft-ietf-netconf-subscribed-notifications and ietf-netconf-yang-push,
which are 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 "W3C-20150203", 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).

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 provides a RESTCONF binding to the dynamic
  subscription capability of both subscribed notifications
  and YANG-Push.

[SHEPHERD] From the Introduction:

  Mechanisms to support event subscription and push are defined in
  [I-D.draft-ietf-netconf-subscribed-notifications].  Enhancements to
  [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG
  datastore subscription and push are defined in
  [I-D.ietf-netconf-yang-push].  This document provides a transport
  specification for dynamic subscriptions over RESTCONF [RFC8040].
  Driving these requirements is [RFC7923].


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 subcriptions, which it does support, but
the WG consensus was to add support for configured subscriptions
at a later time.


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] Unknown if there are any implementations of this
draft as yet.  This document just went through a post-LC
YANG Doctor review (all issues raised were addressed):

https://datatracker.ietf.org/doc/review-ietf-netconf-restconf-notif-11-yangdoctors-lc-wilton-2019-01-07/


Personnel

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

[SHEPHERD] The Document Shepherd is Kent Watsen, with Qin Wu's
assistance. 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-assistant found a number of issues
that have been resolved in the current version.  Both the shepherd
and the assistent are 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/gxToVCK4h3PLOZ7v-hTt4prJorI.

(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 summarise 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 false-positives: a few "weird spacing" and one
    "possible downref"
  - two "outdated ref" warnings: SN-21 --> SN-23 and YP-20 --> YP-22
  - one obsolete normative reference error: RFC 5246 (Obsoleted by
    RFC 8446) [this will be fixed later]


(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 references are to
draft-ietf-netconf-subscribed-notifications and ietf-netconf-yang-push,
which are 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 "W3C-20150203", 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).

Request for posting confirmation emailed to previous authors: netconf-chairs@ietf.org, Andy Bierman , Alexander Clemm , 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 , 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 , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard