Skip to main content

An HTTPS-based Transport for YANG Notifications
draft-ietf-netconf-https-notif-15

Revision differences

Document history

Date Rev. By Action
2024-02-02
15 Mark Nottingham Request for Telechat review by HTTPDIR Completed: Ready with Issues. Reviewer: Mark Nottingham. Sent review to list. Submission of review completed at an earlier date.
2024-02-02
15 Mark Nottingham Request for Telechat review by HTTPDIR Completed: Ready with Issues. Reviewer: Mark Nottingham.
2024-02-02
15 Mark Nottingham Request for Telechat review by HTTPDIR is assigned to Mark Nottingham
2024-02-02
15 Murray Kucherawy Requested Telechat review by HTTPDIR
2024-02-01
15 John Scudder
[Ballot comment]
Thanks!

Residual nit: it should really be “registration policy”, not “update policy”. IANA will understand what you’re trying to say, but if you …
[Ballot comment]
Thanks!

Residual nit: it should really be “registration policy”, not “update policy”. IANA will understand what you’re trying to say, but if you cut another version maybe fix this.
2024-02-01
15 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2024-02-01
15 (System) Changed action holders to Robert Wilton (IESG state changed)
2024-02-01
15 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-01
15 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-15.txt
2024-02-01
15 Mahesh Jethanandani New version accepted (logged-in submitter: Mahesh Jethanandani)
2024-02-01
15 Mahesh Jethanandani Uploaded new revision
2024-02-01
14 (System) Changed action holders to Mahesh Jethanandani, Kent Watsen (IESG state changed)
2024-02-01
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-02-01
14 Lars Eggert
[Ballot comment]
I disagree that the argument that "NETCONF doesn't do QUIC, hence
this spec doesn't support H3" is correct. NETCONF is a protocol exchanging …
[Ballot comment]
I disagree that the argument that "NETCONF doesn't do QUIC, hence
this spec doesn't support H3" is correct. NETCONF is a protocol exchanging
XML snippets, it doesn't support TCP/TLS either. That's what the transports
are for, and this one surely could support H3 if it wanted to, but it
doesn't, because $REASONS. It'd be more honest to actually say what those
reasons are.
2024-02-01
14 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2024-01-31
14 Murray Kucherawy
[Ballot comment]
I support Lars' DISCUSS position.  I also support John Scudder's DISCUSS position, and withdraw my own, which I realize now was incorrect and …
[Ballot comment]
I support Lars' DISCUSS position.  I also support John Scudder's DISCUSS position, and withdraw my own, which I realize now was incorrect and "Specification Required" was a reasonable choice.  Apologies for this oversight.

Comments preserved from the previous ballot version:

The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  Or should this be a MUST?

I suspect you need normative references to RFC 7303 ("application/xml") and RFC 8259 ("application/json").

====

Additional comments from incoming ART AD, Orie Steele:

> The receiver responds with a "200 (OK)" message, having the "Content-Type" header set to either "application/xml" or "application/json"

I assume there are no media types using the +xml or +json structured suffixes that are relevant here.

>  refine "transport/tcp" {
>    // create the logical impossibility of enabling the
>    // "tcp" transport (i.e., "HTTP" without the 'S').
>    if-feature "not httpc:tcp-supported";
>  }

Is it typical to preserve comments like this in a published module?
2024-01-31
14 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-01-31
14 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

I strongly agree with John's DISCUSS. As he says, RFC required is probably what you …
[Ballot comment]
Thank you for the work on this document.

I strongly agree with John's DISCUSS. As he says, RFC required is probably what you want, also given that the "Reference" field specifically ask for "The RFC that defined the URN.".

In Section 1: Please update the reference to HTTP/1.1: 7230 has been obsoleted by 9110 and 9112 (you already have the ref to 9110, so here it is enough to change 7230 to 9112).

Just a note from someone who is not experienced with YANG, so most likely OK to ignore, especially since IANA will most likely know how to deal with this, but by quickly scanning for the "YANG Notifications" registry group, I am not really sure where to find it. 3553 doesn't really point me to it. But again, happy to be educated.
2024-01-31
14 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2024-01-30
14 Murray Kucherawy
[Ballot comment]
I support Lars' DISCUSS position.  I also support John Scudder's DISCUSS position, and withdraw my own, which I realize now was incorrect and …
[Ballot comment]
I support Lars' DISCUSS position.  I also support John Scudder's DISCUSS position, and withdraw my own, which I realize now was incorrect and "Specification Required" was a reasonable choice.  Apologies for this oversight.

Comments preserved from the previous ballot version:

The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  Or should this be a MUST?

I suspect you need normative references to RFC 7303 ("application/xml") and RFC 8259 ("application/json").
2024-01-30
14 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2024-01-29
14 John Scudder
[Ballot discuss]
Thanks for this update. Since I already balloted No Objection on version 13, I’ve only reviewed the changes. They look fine, except one, …
[Ballot discuss]
Thanks for this update. Since I already balloted No Objection on version 13, I’ve only reviewed the changes. They look fine, except one, on which I’m balloting DISCUSS. Be not afraid, this is the world’s easiest DISCUSS, and it comes packaged with a fix I think you will like.

Version 14 says: “The update policy is “Specification Required”. Updates do not require an expert review by a Designated Expert.” This was changed from version 13, which said, “The update policy is “RFC Required”. Updates do not require an expert review by a Designated Expert.” I presume it was changed as a result of Murray’s DISCUSS questioning the “do not require an expert review” sentence and suggesting the use of Specification Required.

I agree with Murray’s questioning of that sentence, but I’m afraid his fix has made things worse, not better. That’s the bad news, the good news is the correct fix is trivially easy. In my view, the correct fix is to revert to the version 13 policy, but completely delete the “do not require” sentence. That is,

OLD (version 14):
  The update policy is “Specification Required”.  Updates do not
  require an expert review by a Designated Expert.

NEW:
  The registration policy is “RFC Required”. 
 
I’ve discussed this with Murray and he agrees in broad strokes.

A little more background: the problem with shifting to Specification Required is that it definitionally requires use of an expert, you can’t disclaim it per my reading of RFC 8126 Section 4.6:

  For the Specification Required policy, review and approval by a
  designated expert (see Section 5) is required [...]
 
There is no “unless” clause. No DE, no SR. Besides that, it’s not what you want! (I think. More below.)

On the other hand, “RFC Required” (Section 4.7) doesn’t require expert review to begin with, so it’s redundant to say one isn’t required. Ergo, since this seems to be the policy you really want (demonstrated by the “reference” field definition in your template), simplify and stick with it! Do note that “RFC Required” is a more stringent policy than some, since as you know, it isn’t trivial to publish an RFC. But I’m assuming you knew that and chose your words deliberately.

(In my NEW text I also changed “update policy” to “registration policy” since that’s the RFC 8126 lingo.)
2024-01-29
14 John Scudder [Ballot Position Update] Position for John Scudder has been changed to Discuss from No Objection
2024-01-29
14 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-01-26
14 Gunter Van de Velde Request closed, assignment withdrawn: Joel Jaeggli Last Call OPSDIR review
2024-01-26
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version': Cleaning up stale OPSDIR queue
2024-01-24
14 Robert Wilton Telechat date has been changed to 2024-02-01 from 2022-12-15
2024-01-24
14 Robert Wilton Bring it back to the IESG eval for second review and to help give time to review and hopefully clear for the discuss holders.
2024-01-24
14 Robert Wilton IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2024-01-18
14 Roman Danyliw
[Ballot comment]
Thank you to Leif Johansson for the SECDIR review

I support Lars Eggert’s and Éric Vyncke’s related DISCUSS position.

Thank you for addressing …
[Ballot comment]
Thank you to Leif Johansson for the SECDIR review

I support Lars Eggert’s and Éric Vyncke’s related DISCUSS position.

Thank you for addressing my COMMENT and DISCUSS feedback.
2024-01-18
14 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2024-01-18
14 Éric Vyncke [Ballot comment]
Thanks for the work done and for addressing my previous DISCUSS position at:
https://mailarchive.ietf.org/arch/msg/netconf/rx2nrr9MZRR3sXsOzERl5eWQ9UI/
2024-01-18
14 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2024-01-18
14 (System) Changed action holders to Robert Wilton (IESG state changed)
2024-01-18
14 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-18
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2024-01-18
14 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-14.txt
2024-01-18
14 Mahesh Jethanandani New version accepted (logged-in submitter: Mahesh Jethanandani)
2024-01-18
14 Mahesh Jethanandani Uploaded new revision
2023-05-22
13 Barry Leiba Closed request for Last Call review by ARTART with state 'Team Will not Review Version'
2023-05-22
13 Barry Leiba Assignment of request for Last Call review by ARTART to Martin Thomson was marked no-response
2022-12-15
13 Jean Mahoney Request closed, assignment withdrawn: Pete Resnick Last Call GENART review
2022-12-15
13 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events': Gen AD has already balloted
2022-12-15
13 (System) Changed action holders to Mahesh Jethanandani, Kent Watsen, Robert Wilton (IESG state changed)
2022-12-15
13 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-12-15
13 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from No Record
2022-12-15
13 Murray Kucherawy
[Ballot discuss]
I'm curious about the new IANA registry.  Why was "RFC Required" with no designated expert chosen as the registration policy?  If no expert …
[Ballot discuss]
I'm curious about the new IANA registry.  Why was "RFC Required" with no designated expert chosen as the registration policy?  If no expert review is needed, why not "Specification Required" or something a little easier?
2022-12-15
13 Murray Kucherawy
[Ballot comment]
I support Lars' DISCUSS position.

The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  …
[Ballot comment]
I support Lars' DISCUSS position.

The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  Or should this be a MUST?

I suspect you need normative references to RFC 7303 ("application/xml") and RFC 8259 ("application/json").
2022-12-15
13 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to Discuss from No Objection
2022-12-15
13 Warren Kumari [Ballot comment]
I support Lars', Roman's and Eric's DISCUSS positions, but have nothing useful to add, other than my thanks to the authors and WG.
2022-12-15
13 Warren Kumari Ballot comment text updated for Warren Kumari
2022-12-15
13 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-12-15
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-12-14
13 Murray Kucherawy
[Ballot comment]
I support Lars' DISCUSS position.

The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  …
[Ballot comment]
I support Lars' DISCUSS position.

The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  Or should this be a MUST?

I'm curious about the new IANA registry.  Why was "RFC Required" with no designated expert chosen as the registration policy?  If no expert review is needed, why not "Specification Required" or something a little easier?

I suspect you need normative references to RFC 7303 ("application/xml") and RFC 8259 ("application/json").
2022-12-14
13 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2022-12-14
13 Murray Kucherawy
[Ballot comment]
The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  Or should this be a …
[Ballot comment]
The SHOULD in Section 2 has me wondering why one might choose not to do what it says.  Or should this be a MUST?

I'm curious about the new IANA registry.  Why was "RFC Required" with no designated expert chosen as the registration policy?  If no expert review is needed, why not "Specification Required" or something a little easier?

I suspect you need normative references to RFC 7303 ("application/xml") and RFC 8259 ("application/json").
2022-12-14
13 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-12-14
13 Paul Wouters
[Ballot comment]
I support the three DISCUSSes filed.

Additionally one more comment:

Section 3.4:

    If the receiver is unable to reply using "application/xml", …
[Ballot comment]
I support the three DISCUSSes filed.

Additionally one more comment:

Section 3.4:

    If the receiver is unable to reply using "application/xml", the response might look like this:
    [...]
    "urn:ietf:capability:https-notif-receiver:encoding:xml",

I assume this line for supporting xml should not be in this example as it is for the response when it is not supported ?
2022-12-14
13 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2022-12-14
13 Zaheduzzaman Sarker
[Ballot comment]
Thanks for this specification.

Lars kind of covered issues related to HTTP3. Hence supporting his discuss points.

I have marked that - RFC …
[Ballot comment]
Thanks for this specification.

Lars kind of covered issues related to HTTP3. Hence supporting his discuss points.

I have marked that - RFC XXXX refers both to "An HTTPS-based Transport for YANG Notifications" (in section 5.2) and "An HTTPS-based Transport for Configured Subscriptions" (in section 6.2), while clearly stating RFC XXXX = An HTTPS-based Transport for YANG Notifications in Section 1.2. I am assuming this just an oversight from the authors. Otherwise, this would be a discuss worthy issue. So please respond to this observation.
2022-12-14
13 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-12-13
13 Roman Danyliw
[Ballot discuss]
** Section 6.2

      container receiver-identity {
        if-feature receiver-identity;
        description
      …
[Ballot discuss]
** Section 6.2

      container receiver-identity {
        if-feature receiver-identity;
        description
          "Maps the receiver's TLS certificate to a local identity
            enabling access control to be applied to filter out
            notifications that the receiver may not be authorized
            to view.";
        container cert-maps {
          uses x509c2n:cert-to-name;
          description
            "The cert-maps container is used by a TLS-based HTTP
              server to map the HTTPS client's presented X.509
              certificate to a 'local' username. If no matching and
              valid cert-to-name list entry is found, the publisher
              MUST close the connection, and MUST NOT send any
              notifications over it.";

The ietf-x509-cert-to-name module exposes many certificate fields.  What specific fields need to be matched from this module and the local identity value?

** Unsafe TLS configurations seem possible.

(a) Section 6.2. 
    grouping https-receiver-grouping {
      description
        "A grouping that may be used by other modules wishing to
          configure HTTPS-based notifications without using RFC 8639.";
      uses httpc:http-client-stack-grouping {

(b) Section 7
  The YANG modules in this document make use of grouping that are
  defined in YANG Groupings for HTTP Clients and HTTP Servers
  [I-D.ietf-netconf-http-client-server], and A YANG Data Model for SNMP
  Configuration [RFC7407].  Please see the Security Considerations
  section of those documents for considerations related to sensitivity
  and vulnerability of the data nodes defined in them.

Per (a) “grouping https-receiver-grouping” seems to reference draft-ietf-netconf-netconf-client-server which in turn seems to reference draft-ietf-netconf-tls-client-server. 

Per (b), the Security Considerations for draft-ietf-ietf-netconf-http-client-server say none of the modules are read or write sensitive.  Draft-ietf-netconf-tls-client-server’s Security Considerations (not referenced here) do note that write access could alter the security policy.

Please provide a declarative caution here about writing to https-receiver-group.  Additionally, are any TLS parameters in transport/tls/tls/http/client-parameters acceptable?  Should they conform to draft-ietf-uta-rfc7525bis?

** Section 10.
  *  The "path" node in "ietf-subscribed-notif-receivers" module can be
      modified by a malicious user to point to an invalid URI.

It could be worse than that.  An attacker could direct the to a URL of their choosing which could (a) serve an exploit against a vulnerable client; or (b) assuming redirects are followed, track usage.
2022-12-13
13 Roman Danyliw
[Ballot comment]
Thank you to Leif Johansson for the SECDIR review

I support Lars Eggert’s and Éric Vyncke’s related DISCUSS position.

Editorially, due to the …
[Ballot comment]
Thank you to Leif Johansson for the SECDIR review

I support Lars Eggert’s and Éric Vyncke’s related DISCUSS position.

Editorially, due to the module imports, it was difficulty to read the YANG tree view in Section 6.1 and reconcile it with the module in Section 6.2.
2022-12-13
13 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2022-12-12
13 Amanda Baber
IANA question: This document is creating a registry for URNs that begin with the string "urn:ietf:capability:". Should it also register "capability" in the IETF URN …
IANA question: This document is creating a registry for URNs that begin with the string "urn:ietf:capability:". Should it also register "capability" in the IETF URN Sub-namespaces registry? See

https://www.iana.org/assignments/params
2022-12-12
13 Éric Vyncke
[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-netconf-https-notif-13
CC @evyncke

Thank you for the work put into this document.

Please find below one …
[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-netconf-https-notif-13
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Qiufang Ma for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 6.1

`The module contains the TCP, TLS and HTTPS parameters` seems to prevent the use of HTTP/3, which relies on QUIC, i.e., UDP. Is it on purpose ? If so, a justification is probably required.

Related to the above sentence, the tree has:
```
          +--rw https-receiver
            +--rw (transport)
            |  +--:(tls) {tls-supported}?
            |    +--rw tls
```
Please, bear with my ignorance of YANG, but does the '?' indicate that the tls sub-tree may not be supported ? Weird for an IETF draft whose title include HTTPS ;-) (or is it to support QUIC ?)

Finally, and for sure it is my ignorance about YANG, but I do not see an obvious link between the tree view and the YANG module. Should there be a written explanation in the text ? (this is of course a COMMENT-level point).

### Section 7

The security section is mainly about the YANG RESTCONF/NETCONF template, but does not address the security of sending notifications over HTTP. E.g., as written below, what about TLS mutual authentication ? How is the HTTP server certificate is trusted ?
2022-12-12
13 Éric Vyncke
[Ballot comment]

## COMMENTS

### Abstract
```
  This document requires that the publisher is a "server" (e.g., a
  NETCONF or RESTCONF server), but …
[Ballot comment]

## COMMENTS

### Abstract
```
  This document requires that the publisher is a "server" (e.g., a
  NETCONF or RESTCONF server), but does not assume that the receiver is
  a server.
```
This last paragraph adds more confusion on the roles... Suggest to remove it.

### Roles

Suggest to prefix server always by HTTPS (i.e., "HTTPS server") and use "publisher" for the NETCONF/RESTCONF "server".

### Which TLS version ?

I will let the transport/security ADs to ballot a DISCUSS if required, but wouldn't a specification of which HTTP and TLS versions are required ?

Should the certificate validation procedure be specified ?

### Section 2

Probably linked to my ignorance of the system (a global archicture or a more detailed introduction would be appreciated), but how is the "relay-notifications" known by the publisher ? In the examples, there is not such item.

Minor comment: is it a "path" or a "common prefix" ? Also, doesn't having a common prefix in the URI prevent having two "HTTP servers" for the same subscription. E.g., one for the capabilities and one for the notifications (e.g., for geographica load distribution).

### Section 3.2

`a publisher can issue an HTTPS GET request` should the 'can' be 'upgraded' to a "SHOULD" or "MAY" ?

### Section 3.4

Please replace 'nnn' by the exact Content-Length.

### Section 4.1

s/HTTPS POST request/HTTP POST request/ ?

### Section 4.2

```
  ... In case of
  corrupted or malformed event, the response should be an appropriate
  HTTP error response.
```

Suggest to replace "should" by "SHOULD" or even "MUST".

## NITS


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2022-12-12
13 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2022-12-12
13 Lars Eggert
[Ballot discuss]
# GEN AD review of draft-ietf-netconf-https-notif-13

CC @larseggert

## Discuss

### "NETCONF", paragraph 1
```
              An …
[Ballot discuss]
# GEN AD review of draft-ietf-netconf-https-notif-13

CC @larseggert

## Discuss

### "NETCONF", paragraph 1
```
              An HTTPS-based Transport for YANG Notifications
                    draft-ietf-netconf-https-notif-13
```
Given this title, the document really needs to normatively cite
(some of) RFCs 9110-9114 and explain how YANG notifications are
transported over HTTP/1.1, /2 and /3. (Mark Nottingham has also
raised this during last-call, but apparently no changes were made.)

### Section 1.1, paragraph 1
```
    While the YANG modules have been defined as an augmentation of
    Subscription to YANG Notifications [RFC8639], the notification method
    defined in this document MAY be used outside of Subscription to YANG
    Notifications [RFC8639] by using some of the definitions from this
    module along with the grouping defined in Groupings for HTTP Clients
    and Servers [I-D.ietf-netconf-http-client-server].  For an example on
    how that can be done, see Section A.2.
```
draft-ietf-netconf-http-client-server also does not seem to discuss
HTTP/3 and QUIC. It is therefore not a suitable basis.

### Section 6.1, paragraph 1
```
    This YANG module is a definition of a set of receivers that are
    interested in the notifications published by the publisher.  The
    module contains the TCP, TLS and HTTPS parameters that are needed to
    communicate with the receiver.  The module augments the "ietf-
    subscribed-notif-receivers" module to define a transport specific
    receiver.
```
HTTP/3 is carried over QUIC and not TCP/TLS. Can this YANG module
support that?

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.
2022-12-12
13 Lars Eggert
[Ballot comment]
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore …
[Ballot comment]
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.2, paragraph 1
```
-    and/or "application/json" media-types, with the latter as mandatory
-                                                              ^^^^^^^^^
+    and/or "application/json" media-types, with the latter as REQUIRED
+                                                              ^^^^^^^^
```

### URLs

These URLs point to tools.ietf.org, which has been taken out of service:

* http://tools.ietf.org/wg/netconf

### Grammar/style

#### Section 3.3, paragraph 1
```
publisher wants to receive the capabilities response in XML but, if not sup
                                ^^^^^^^^^^^^
```
An apostrophe may be missing.

#### Section 5.2, paragraph 9
```
"; } } description "Augment the subscriptions container to define the transp
                                ^^^^^^^^^^^^^
```
An apostrophe may be missing.

#### Section 5.2, paragraph 10
```
e."; } description "Augment the subscriptions container to define an optional
                                ^^^^^^^^^^^^^
```
An apostrophe may be missing.

#### Section 9.1, paragraph 9
```
to use HTTPS-based notifications outside of Subscribed Notifications, an app
                                ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2022-12-12
13 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2022-12-09
13 Amanda Baber IANA Experts State changed to Expert Reviews OK from Issues identified
2022-12-08
13 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-netconf-https-notif-13
CC @ekline

## Nits

### S4.1

* "SSE" acronym used without prior expansion.  Perhaps this is a …
[Ballot comment]
# Internet AD comments for draft-ietf-netconf-https-notif-13
CC @ekline

## Nits

### S4.1

* "SSE" acronym used without prior expansion.  Perhaps this is a well-known
  abbreviation within the relevant circles, but neither of the expansions from
  https://www.rfc-editor.org/materials/abbrev.expansion.txt seemed intuitively
  obvious (admittedly: I'm not *CONF/YANG specialist).

  Indeed, 8040 S1.1.5 suggests this means "Server-Sent Events", which is not
  currently in the RFC Editor's abbreviations list.
2022-12-08
13 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-12-07
13 Cindy Morgan Placed on agenda for telechat - 2022-12-15
2022-12-07
13 Robert Wilton Ballot has been issued
2022-12-07
13 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2022-12-07
13 Robert Wilton Created "Approve" ballot
2022-12-07
13 Robert Wilton IESG state changed to IESG Evaluation from Waiting for Writeup
2022-12-06
13 Robert Wilton Ballot writeup was changed
2022-11-24
13 Magnus Westerlund Closed request for Last Call review by TSVART with state 'Team Will not Review Document'
2022-11-24
13 Magnus Westerlund Assignment of request for Last Call review by TSVART to Bernard Aboba was withdrawn
2022-11-22
13 David Dong
This is up to the usual standard for YANG documents.  I note that in the example in A.1 we see the following:

      …
This is up to the usual standard for YANG documents.  I note that in the example in A.1 we see the following:

              x509c2n:san-any

in which the "x509c2n:" is a namespace prefix correctly declared above, and used in running text content of an XML element. In the general case this WILL NOT WORK and requires that software which processes text encoded this way has a special feature offered by some but not all XML parsers, namely, that it will make available to calling software the mapping between XML namespaces and their declared prefixes.  This is generally not regarded as a best practice. 

I would like this to see this special requirement for processing software to be called out in the RFC text.

However, multiple YANG specifications use this nonstandard idiom and have declined to call out the requirement, so, as I said, this is up to the normal YANG standard. If that's good enough for the editors, then I see no further issues with this draft.
2022-11-22
13 David Dong IANA Experts State changed to Issues identified from Reviews assigned
2022-11-20
13 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-11-18
13 David Dong IANA Experts State changed to Reviews assigned
2022-11-18
13 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2022-11-18
13 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

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

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three 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/

two, new namespaces will be registered as follows:

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

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

As this document requests registrations in an Expert Review or 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/

two, new YANG modules will be registered as follows:

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

Name: ietf-https-notif-transport
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif-transport
Prefix: hnt
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.

Third, a new registry is to be created called the Capabilities for HTTPS Notification Receivers registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

The following note shall be at the top of the registry:

This registry defines capabilities that can be supported by HTTPS-based notification receivers.

The registration rules will be RFC Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

URN: urn:ietf:capability:https-notif-receiver:encoding:json
Reference: [ RFC-to-be ]
Description: Identifies support for JSON-encoded notifications.

URN: urn:ietf:capability:https-notif-receiver:encoding:xml
Reference: [ RFC-to-be ]
Description: Identifies support for XML-encoded notifications.

URN: urn:ietf:capability:https-notif-receiver:sub-notif
Reference: RFC XXXX
Description: Identifies support for state machine described in
RFC 8639, enabling the publisher to send, e.g., the
"subscription-started" notification.

The IANA Functions 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist
2022-11-17
13 Leif Johansson Request for Last Call review by SECDIR Completed: Ready. Reviewer: Leif Johansson. Sent review to list.
2022-11-11
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Leif Johansson
2022-11-11
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Leif Johansson
2022-11-10
13 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2022-11-10
13 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2022-11-09
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2022-11-09
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2022-11-08
13 Magnus Westerlund Request for Last Call review by TSVART is assigned to Bernard Aboba
2022-11-08
13 Magnus Westerlund Request for Last Call review by TSVART is assigned to Bernard Aboba
2022-11-07
13 Barry Leiba Request for Last Call review by ARTART is assigned to Martin Thomson
2022-11-07
13 Barry Leiba Request for Last Call review by ARTART is assigned to Martin Thomson
2022-11-06
13 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-11-06
13 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-11-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netconf-https-notif@ietf.org, maqiufang1@huawei.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com …
The following Last Call announcement was sent out (ends 2022-11-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netconf-https-notif@ietf.org, maqiufang1@huawei.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (An HTTPS-based Transport for YANG Notifications) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'An HTTPS-based Transport for YANG
Notifications'
  as Proposed Standard

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

Abstract


  This document defines a protocol for sending notifications over
  HTTPS.  YANG modules for configuring publishers are also defined.
  Examples are provided illustrating how to configure various
  publishers.

  This document requires that the publisher is a "server" (e.g., a
  NETCONF or RESTCONF server), but does not assume that the receiver is
  a server.




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



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




2022-11-06
13 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-11-06
13 Robert Wilton Last call was requested
2022-11-06
13 Robert Wilton Ballot approval text was generated
2022-11-06
13 Robert Wilton Ballot writeup was generated
2022-11-06
13 Robert Wilton IESG state changed to Last Call Requested from AD Evaluation
2022-11-06
13 Robert Wilton Last call announcement was generated
2022-11-04
13 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-13.txt
2022-11-04
13 Jenny Bui Forced post of submission
2022-11-04
13 (System) Request for posting confirmation emailed to previous authors: Kent Watsen , Mahesh Jethanandani
2022-11-04
13 Mahesh Jethanandani Uploaded new revision
2022-09-29
12 (System) Changed action holders to Robert Wilton (IESG state changed)
2022-09-29
12 Robert Wilton IESG state changed to AD Evaluation from Publication Requested
2022-09-07
12 Mahesh Jethanandani
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Shepherd:
The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments on the changes of the document.
WGLC has received some detailed reviews and other additional comments, there is no objection to publication.
Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netconf/lRVid8TdPOglKyHxfDxAHAlTUXE/ 

As such, the document has reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Shepherd:
There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough.

This document has received enough review in both WG meeting and on the NETCONF WG mailing list, both authors and the shepherd believe that all the comments and questions from that review have been incorporated into the document.

3. 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 threatened an appeal or otherwise indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Shepherd:
The shepherd knows that there is an existing implementation from INSA Unyte team, which is an open-sourced library for collecting HTTPS-notif protocol message available at https://github.com/insa-unyte/https-notif-c-collector.
No other existing implementations have been publicly reported.

The shepherd is unaware of any potential implementers indicating plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Shepherd:
The shepherd doesn't think the contents of this document closely interact with technologies in other fields, and therefore the shepherd doesn't believe this document needs review from other IETF working groups or external organizations.
The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netconf-https-notif-06-yangdoctors-lc-lindem-2021-01-27/
And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list:
https://mailarchive.ietf.org/arch/msg/netconf/9dpwQHFIwhpPQxdKNLfLKOSNerE/

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Shepherd:
The document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation, no errors or warnings have been flagged out.
$pyang --ietf ietf-subscribed-notif-receivers@2022-08-22.yang
$yanglint  ietf-subscribed-notif-receivers@2022-08-22.yang

$pyang --ietf ietf-https-notif-transport@2022-08-22.yang
$yanglint  ietf-https-notif-transport@2022-08-22.yang

The shepherd also tested the formatting using the command:
$pyang -f yang --keep-comments --yang-line-length 69 ietf-subscribed-notif-receivers@2022-08-22.yang > test1.yang && diff ietf-subscribed-notif-receivers@2022-08-22.yang test1.yang

The following results are returned which the shepherd thinks is innocuous:
5c5
<  prefix "snr";
---
>  prefix snr;
15d14
<
22d20
<
59c57
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
70d67
<
73d69
<
80d75
<
97,98c92,93
<  augment
<    "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
---
>  augment "/sn:subscriptions/sn:subscription/sn:receivers"
>        + "/sn:receiver" {
101,102c96,97
<        path "/sn:subscriptions/snr:receiver-instances/" +
<              "snr:receiver-instance/snr:name";
---
>        path "/sn:subscriptions/snr:receiver-instances/"
>            + "snr:receiver-instance/snr:name";
112d106
<

$pyang -f yang --keep-comments --yang-line-length 69 ietf-https-notif-transport@2022-08-22.yang > test2.yang && diff ietf-https-notif-transport@2022-08-22.yang test2.yang

The following results are returned which the shepherd thinks is innocuous:
4c4
<  prefix "hnt";
---
>  prefix hnt;
11d10
<
17d15
<
24d21
<
33d29
<
40d35
<
67c62
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
113c108
<      if-feature receiver-identity;
---
>      if-feature "receiver-identity";
134,135c129,130
<  augment "/sn:subscriptions/snr:receiver-instances/" +
<          "snr:receiver-instance/snr:transport-type" {
---
>  augment "/sn:subscriptions/snr:receiver-instances/"
>        + "snr:receiver-instance/snr:transport-type" {

Note that DataTracker’s YANG validator reports 0 errors and 2 warnings which are ignored by me (I am using yanglint 2.0.112, whereas DataTracker is using yanglint 1.9.2).

Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342].

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:
The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Shepherd:
The shepherd doesn't see any related issues that are listed at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics.
The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Shepherd:
This document is requested to be published as a Proposed standard. In this case, it's the correct state because this documents defines a protocol for sending notifications over HTTPS.

This status is properly reflected on the title page and in the Datatracker (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Shepherd:
No IPR disclosure has been filed that references this document.

The Area director(only because both chairs are listed as authors on this document) has requested an IPR call on the list.
Both authors confirmed that they are not aware of any IPR related to this document.
All responses indicated no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Shepherd:
There are 2 authors (no greater than 5) for this draft and no contributor being listed.
Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that both of the authors have been listed for a long time and their silence implies consent. Both of the authors have been actively involved in the discussion about this document both on the list and during WG meeting.
and their response to the IPR poll during WGLC( here is the direct link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg) also implies that both authors are aware of their status on the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Shepherd:
I-D nits has been tested against -12, and it reports 0 error (**), 0 flaws (~~), 3 warnings (==), 0 comments (--), which are innocuous.
Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Shepherd:
The shepherd has reviewed that all references within this document have been identified as either normative or informative, and all the informative and normative references are classified correctly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Shepherd:
None. All the normative references in the document are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Shepherd:
There is no normative downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Shepherd:
No. All normative references are published except [I-D.ietf-netconf-http-client-server] which needs to be published first before this document being progressed.
It has been planned to move [I-D.ietf-netconf-http-client-server] for publication first.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Shepherd:
The publication of this document will not change the status of any existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Shepherd:
The shepherd has reviewed the IANA considerations section. This document registers two URIs and two YANG modules. Besides that, the document also requests to define a "Capabilities for HTTPS Notification Receivers" registry.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries.
The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and the newly created "Capabilities for HTTPS Notification Receivers" IANA registry specifies its initial contents, allocations procedures, and a reasonable name.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Shepherd:
The new IANA registries will not require Designated Expert Review for future allocations.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2022-09-07
12 Mahesh Jethanandani Responsible AD changed to Robert Wilton
2022-09-07
12 Mahesh Jethanandani IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-09-07
12 Mahesh Jethanandani IESG state changed to Publication Requested from I-D Exists
2022-09-07
12 Mahesh Jethanandani IESG process started in state Publication Requested
2022-08-26
12 Qiufang Ma
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Shepherd:
The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments on the changes of the document.
WGLC has received some detailed reviews and other additional comments, there is no objection to publication.
Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netconf/lRVid8TdPOglKyHxfDxAHAlTUXE/ 

As such, the document has reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Shepherd:
There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough.

This document has received enough review in both WG meeting and on the NETCONF WG mailing list, both authors and the shepherd believe that all the comments and questions from that review have been incorporated into the document.

3. 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 threatened an appeal or otherwise indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Shepherd:
The shepherd knows that there is an existing implementation from INSA Unyte team, which is an open-sourced library for collecting HTTPS-notif protocol message available at https://github.com/insa-unyte/https-notif-c-collector.
No other existing implementations have been publicly reported.

The shepherd is unaware of any potential implementers indicating plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Shepherd:
The shepherd doesn't think the contents of this document closely interact with technologies in other fields, and therefore the shepherd doesn't believe this document needs review from other IETF working groups or external organizations.
The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netconf-https-notif-06-yangdoctors-lc-lindem-2021-01-27/
And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list:
https://mailarchive.ietf.org/arch/msg/netconf/9dpwQHFIwhpPQxdKNLfLKOSNerE/

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Shepherd:
The document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation, no errors or warnings have been flagged out.
$pyang --ietf ietf-subscribed-notif-receivers@2022-08-22.yang
$yanglint  ietf-subscribed-notif-receivers@2022-08-22.yang

$pyang --ietf ietf-https-notif-transport@2022-08-22.yang
$yanglint  ietf-https-notif-transport@2022-08-22.yang

The shepherd also tested the formatting using the command:
$pyang -f yang --keep-comments --yang-line-length 69 ietf-subscribed-notif-receivers@2022-08-22.yang > test1.yang && diff ietf-subscribed-notif-receivers@2022-08-22.yang test1.yang

The following results are returned which the shepherd thinks is innocuous:
5c5
<  prefix "snr";
---
>  prefix snr;
15d14
<
22d20
<
59c57
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
70d67
<
73d69
<
80d75
<
97,98c92,93
<  augment
<    "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
---
>  augment "/sn:subscriptions/sn:subscription/sn:receivers"
>        + "/sn:receiver" {
101,102c96,97
<        path "/sn:subscriptions/snr:receiver-instances/" +
<              "snr:receiver-instance/snr:name";
---
>        path "/sn:subscriptions/snr:receiver-instances/"
>            + "snr:receiver-instance/snr:name";
112d106
<

$pyang -f yang --keep-comments --yang-line-length 69 ietf-https-notif-transport@2022-08-22.yang > test2.yang && diff ietf-https-notif-transport@2022-08-22.yang test2.yang

The following results are returned which the shepherd thinks is innocuous:
4c4
<  prefix "hnt";
---
>  prefix hnt;
11d10
<
17d15
<
24d21
<
33d29
<
40d35
<
67c62
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
113c108
<      if-feature receiver-identity;
---
>      if-feature "receiver-identity";
134,135c129,130
<  augment "/sn:subscriptions/snr:receiver-instances/" +
<          "snr:receiver-instance/snr:transport-type" {
---
>  augment "/sn:subscriptions/snr:receiver-instances/"
>        + "snr:receiver-instance/snr:transport-type" {

Note that DataTracker’s YANG validator reports 0 errors and 2 warnings which are ignored by me (I am using yanglint 2.0.112, whereas DataTracker is using yanglint 1.9.2).

Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342].

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:
The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Shepherd:
The shepherd doesn't see any related issues that are listed at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics.
The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Shepherd:
This document is requested to be published as a Proposed standard. In this case, it's the correct state because this documents defines a protocol for sending notifications over HTTPS.

This status is properly reflected on the title page and in the Datatracker (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Shepherd:
No IPR disclosure has been filed that references this document.

The Area director(only because both chairs are listed as authors on this document) has requested an IPR call on the list.
Both authors confirmed that they are not aware of any IPR related to this document.
All responses indicated no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Shepherd:
There are 2 authors (no greater than 5) for this draft and no contributor being listed.
Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that both of the authors have been listed for a long time and their silence implies consent. Both of the authors have been actively involved in the discussion about this document both on the list and during WG meeting.
and their response to the IPR poll during WGLC( here is the direct link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg) also implies that both authors are aware of their status on the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Shepherd:
I-D nits has been tested against -12, and it reports 0 error (**), 0 flaws (~~), 3 warnings (==), 0 comments (--), which are innocuous.
Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Shepherd:
The shepherd has reviewed that all references within this document have been identified as either normative or informative, and all the informative and normative references are classified correctly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Shepherd:
None. All the normative references in the document are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Shepherd:
There is no normative downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Shepherd:
No. All normative references are published except [I-D.ietf-netconf-http-client-server] which needs to be published first before this document being progressed.
It has been planned to move [I-D.ietf-netconf-http-client-server] for publication first.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Shepherd:
The publication of this document will not change the status of any existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Shepherd:
The shepherd has reviewed the IANA considerations section. This document registers two URIs and two YANG modules. Besides that, the document also requests to define a "Capabilities for HTTPS Notification Receivers" registry.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries.
The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and the newly created "Capabilities for HTTPS Notification Receivers" IANA registry specifies its initial contents, allocations procedures, and a reasonable name.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Shepherd:
The new IANA registries will not require Designated Expert Review for future allocations.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2022-08-26
12 Qiufang Ma
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Shepherd:
The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments on the changes of the document.
WGLC has received some detailed reviews and other additional comments, there is no objection to publication.
Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netconf/lRVid8TdPOglKyHxfDxAHAlTUXE/ 

As such, the document has reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Shepherd:
There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough.

This document has received enough review in both WG meeting and on the NETCONF WG mailing list, both authors and the shepherd believe that all the comments and questions from that review have been incorporated into the document.

3. 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 threatened an appeal or otherwise indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Shepherd:
The shepherd knows that there is an existing implementation from INSA Unyte team, which is an open-sourced library for collecting HTTPS-notif protocol message available at https://github.com/insa-unyte/https-notif-c-collector.
No other existing implementations have been publicly reported.

The shepherd is unaware of any potential implementers indicating plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Shepherd:
The shepherd doesn't think the contents of this document closely interact with technologies in other fields, and therefore the shepherd doesn't believe this document needs review from other IETF working groups or external organizations.
The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netconf-https-notif-06-yangdoctors-lc-lindem-2021-01-27/
And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list:
https://mailarchive.ietf.org/arch/msg/netconf/9dpwQHFIwhpPQxdKNLfLKOSNerE/

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Shepherd:
The document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation, no errors or warnings have been flagged out.
$pyang --ietf ietf-subscribed-notif-receivers@2022-08-22.yang
$yanglint  ietf-subscribed-notif-receivers@2022-08-22.yang

$pyang --ietf ietf-https-notif-transport@2022-08-22.yang
$yanglint  ietf-https-notif-transport@2022-08-22.yang

The shepherd also tested the formatting using the command:
$pyang -f yang --keep-comments --yang-line-length 69 ietf-subscribed-notif-receivers@2022-08-22.yang > test1.yang && diff ietf-subscribed-notif-receivers@2022-08-22.yang test1.yang

The following results are returned which the shepherd thinks is innocuous:
5c5
<  prefix "snr";
---
>  prefix snr;
15d14
<
22d20
<
59c57
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
70d67
<
73d69
<
80d75
<
97,98c92,93
<  augment
<    "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
---
>  augment "/sn:subscriptions/sn:subscription/sn:receivers"
>        + "/sn:receiver" {
101,102c96,97
<        path "/sn:subscriptions/snr:receiver-instances/" +
<              "snr:receiver-instance/snr:name";
---
>        path "/sn:subscriptions/snr:receiver-instances/"
>            + "snr:receiver-instance/snr:name";
112d106
<

$pyang -f yang --keep-comments --yang-line-length 69 ietf-https-notif-transport@2022-08-22.yang > test2.yang && diff ietf-https-notif-transport@2022-08-22.yang test2.yang

The following results are returned which the shepherd thinks is innocuous:
4c4
<  prefix "hnt";
---
>  prefix hnt;
11d10
<
17d15
<
24d21
<
33d29
<
40d35
<
67c62
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
113c108
<      if-feature receiver-identity;
---
>      if-feature "receiver-identity";
134,135c129,130
<  augment "/sn:subscriptions/snr:receiver-instances/" +
<          "snr:receiver-instance/snr:transport-type" {
---
>  augment "/sn:subscriptions/snr:receiver-instances/"
>        + "snr:receiver-instance/snr:transport-type" {

Note that DataTracker’s YANG validator reports 0 errors and 2 warnings which are ignored by me (I am using yanglint 2.0.112, whereas DataTracker is using yanglint 1.9.2).

Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342].

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:
The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Shepherd:
The shepherd doesn't see any related issues that are listed at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics.
The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Shepherd:
This document is requested to be published as a Proposed standard. In this case, it's the correct state because this documents defines a protocol for sending notifications over HTTPS.

This status is properly reflected on the title page and in the Datatracker (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Shepherd:
No IPR disclosure has been filed that references this document.

The Area director(only because both chairs are listed as authors on this document) has requested an IPR call on the list.
Both authors confirmed that they are not aware of any IPR related to this document.
All responses indicated no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Shepherd:
There are 2 authors (no greater than 5) for this draft and no contributor being listed.
Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that both of the authors have been listed for a long time and their silence implies consent. Both of the authors have been actively involved in the discussion about this document both on the list and during WG meeting.
and their response to the IPR poll during WGLC( here is the direct link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg) also implies that both authors are aware of their status on the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Shepherd:
I-D nits has been tested against -12, and it reports 0 error (**), 0 flaws (~~), 3 warnings (==), 0 comments (--), which are innocuous.
Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Shepherd:
The shepherd has reviewed that all references within this document have been identified as either normative or informative, and all the informative and normative references are classified correctly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Shepherd:
None. All the normative references in the document are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Shepherd:
There is no normative downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Shepherd:
No. All normative references are published except [I-D.ietf-netconf-http-client-server] which needs to be published first before this document being progressed.
It has been planned to move [I-D.ietf-netconf-http-client-server] for publication first.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Shepherd:
The publication of this document will not change the status of any existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Shepherd:
The shepherd has reviewed the IANA considerations section. This document registers two URIs and two YANG modules. Besides that, the document also requests to define a "Capabilities for HTTPS Notification Receivers" registry.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries.
The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and the newly created "Capabilities for HTTPS Notification Receivers" IANA registry specifies its initial contents, allocations procedures, and a reasonable name.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Shepherd:
The new IANA registries will not require Designated Expert Review for future allocations.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2022-08-23
12 Qiufang Ma
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Shepherd:
The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments on the changes of the document.
WGLC has received some detailed reviews and other additional comments, there is no objection to publication.
Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netconf/lRVid8TdPOglKyHxfDxAHAlTUXE/

As such, the document has reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Shepherd:
There was no controversy about particular points, and the shepherd doesn't notice any decisions where the consensus was particularly rough.

This document has received enough review in both WG meeting and on the NETCONF WG mailing list, the authors and shepherd believe that all the comments and questions from that review have be incorporated into the document.

3. 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 threatened an appeal or otherwise indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Shepherd:
The shepherd knows that there is an existing implementation from INSA Unyte team, which is an open-sourced library for collecting HTTPS-notif protocol message available at https://github.com/insa-unyte/https-notif-c-collector.
No other existing implementations have been publicly reported.

The shepherd is unaware of any potential implementers indicating plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Shepherd:
The shepherd doesn't think the contents of this document closely interact with technologies in other fields, and therefore the shepherd doesn't believe this document needs review from other IETF working groups or external organizations.
The shepherd doesn't see any public review from other IETF working groups or external organizations occurred before.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process. Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netconf-https-notif-06-yangdoctors-lc-lindem-2021-01-27/

And here is the related discussion about the Yang doctor last call review on the NETCONF WG mailing list:
https://mailarchive.ietf.org/arch/msg/netconf/9dpwQHFIwhpPQxdKNLfLKOSNerE/

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Shepherd:
Yes,
Yes, the document contains two YANG modules. Both have passed through `pyang` and `yanglint` validation, no errors or warnings have been flagged out.
$pyang --ietf ietf-subscribed-notif-receivers@2022-08-22.yang
$yanglint  ietf-subscribed-notif-receivers@2022-08-22.yang

$pyang --ietf ietf-https-notif-transport@2022-08-22.yang
$yanglint  ietf-https-notif-transport@2022-08-22.yang

The shepherd also tested the formatting using the command:
$pyang -f yang --keep-comments --yang-line-length 69 ietf-subscribed-notif-receivers@2022-08-22.yang > test1.yang && diff ietf-subscribed-notif-receivers@2022-08-22.yang test1.yang

The following results are returned which the shepherd thinks is innocuous:
5c5
<  prefix "snr";
---
>  prefix snr;
15d14
<
22d20
<
59c57
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
70d67
<
73d69
<
80d75
<
97,98c92,93
<  augment
<    "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
---
>  augment "/sn:subscriptions/sn:subscription/sn:receivers"
>        + "/sn:receiver" {
101,102c96,97
<        path "/sn:subscriptions/snr:receiver-instances/" +
<              "snr:receiver-instance/snr:name";
---
>        path "/sn:subscriptions/snr:receiver-instances/"
>            + "snr:receiver-instance/snr:name";
112d106
<

$pyang -f yang --keep-comments --yang-line-length 69 ietf-https-notif-transport@2022-08-22.yang > test2.yang && diff ietf-https-notif-transport@2022-08-22.yang test2.yang

The following results are returned which the shepherd thinks is innocuous:
4c4
<  prefix "hnt";
---
>  prefix hnt;
11d10
<
17d15
<
24d21
<
33d29
<
40d35
<
67c62
<  revision "2022-08-22" {
---
>  revision 2022-08-22 {
113c108
<      if-feature receiver-identity;
---
>      if-feature "receiver-identity";
134,135c129,130
<  augment "/sn:subscriptions/snr:receiver-instances/" +
<          "snr:receiver-instance/snr:transport-type" {
---
>  augment "/sn:subscriptions/snr:receiver-instances/"
>        + "snr:receiver-instance/snr:transport-type" {


Note that DataTracker’s YANG validator reports 0 errors and 2 warnings which are ignored by me (I am using yanglint 2.0.112, whereas DataTracker is using yanglint 1.9.2).

Both of the YANG modules defined in this document comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342].


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:
The Shepherd has read the document, tested it against "idnits", and validated the syntactical correctness of both modules defined in the document using "pyang" and "yanglint", with neither returning any errors or warnings.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Shepherd:
The shepherd doesn't see any related issues that are listed at https://trac.ietf.org/trac/iesg/wiki/ExpertTopics.
There is nothing that would merit specific attention from subsequent reviews.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Shepherd:
This document is requested to published as a Proposed standard. In this case, it's the correct state because this documents defines a protocol for sending notifications over HTTPS.

This status is properly reflected on the title page and in the Datatracker (here is the direct link: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Shepherd:
No IPR disclosure has been filed that references this document.

The Area director(only because both chairs are listed as authors on this document) has requested an IPR call on the list.
Both authors confirmed that they are not aware of any IPR related to this document.
All responses indicated no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Shepherd:
There are 2 authors (no greater than 5) for this draft and no contributor being listed.
Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that both of the authors have been listed for a long time and their silence implies consent. Both of the authors have been actively involved in the discussion about this document both on the list and during WG meeting.
and their response to the IPR poll during WGLC( here is the direct link to the IPR call request: https://mailarchive.ietf.org/arch/msg/netconf/D1nXqZ3EJAzmugdoIvNTWz9Ehwg) implies that both authors are aware of their status on the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Shepherd:
I-D nits has been tested against v-12, and it reports 0 error (**), 0 flaws (~~), 3 warnings (==), 0 comments (--), which are innocuous.
Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Shepherd:
The shepherd has reviewed that all references within this document have been identified as either normative or informative, and all the informative and normative references are classified correctly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Shepherd:
None. All the normative references in the document are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Shepherd:
There is no normative downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Shepherd:
No. All normative references are published except [I-D.ietf-netconf-http-client-server] which needs to be published first before this document being progressed.
It has been planned to move [I-D.ietf-netconf-http-client-server] for publication first.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Shepherd:
The publication of this document will not change the status of any existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Shepherd:
The shepherd has reviewed the IANA considerations section. This document registers two URIs and two YANG modules. Besides that, the document also requests to define a "Capabilities for HTTPS Notification Receivers" registry.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries.
The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and the newly created "Capabilities for HTTPS Notification Receivers" IANA registry specifies its initial contents, allocations procedures, and a reasonable name.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Shepherd:
The new IANA registries will not require Designated Expert Review for future allocations.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2022-08-22
12 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-12.txt
2022-08-22
12 Mahesh Jethanandani New version accepted (logged-in submitter: Mahesh Jethanandani)
2022-08-22
12 Mahesh Jethanandani Uploaded new revision
2022-07-19
11 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-11.txt
2022-07-19
11 Jenny Bui Posted submission manually
2022-06-17
10 Robert Wilton Notification list changed to maqiufang1@huawei.com because the document shepherd was set
2022-06-17
10 Robert Wilton Document shepherd changed to Qiufang Ma
2022-06-15
10 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-10.txt
2022-06-15
10 Mahesh Jethanandani New version accepted (logged-in submitter: Mahesh Jethanandani)
2022-06-15
10 Mahesh Jethanandani Uploaded new revision
2022-04-27
09 (System) Document has expired
2022-01-10
09 Kent Watsen IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2022-01-10
09 Kent Watsen Changed consensus to Yes from Unknown
2022-01-10
09 Kent Watsen Intended Status changed to Proposed Standard from None
2021-10-24
09 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-09.txt
2021-10-24
09 (System) New version approved
2021-10-24
09 (System) Request for posting confirmation emailed to previous authors: Kent Watsen , Mahesh Jethanandani
2021-10-24
09 Mahesh Jethanandani Uploaded new revision
2021-08-26
08 (System) Document has expired
2021-02-22
08 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-08.txt
2021-02-22
08 (System) New version approved
2021-02-22
08 (System) Request for posting confirmation emailed to previous authors: Kent Watsen , Mahesh Jethanandani
2021-02-22
08 Mahesh Jethanandani Uploaded new revision
2021-02-02
07 Kent Watsen New version available: draft-ietf-netconf-https-notif-07.txt
2021-02-02
07 (System) New version accepted (logged-in submitter: Kent Watsen)
2021-02-02
07 Kent Watsen Uploaded new revision
2021-01-27
06 Acee Lindem Request for Last Call review by YANGDOCTORS Completed: Almost Ready. Reviewer: Acee Lindem. Sent review to list.
2021-01-12
06 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem
2021-01-12
06 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem
2021-01-12
06 Mehmet Ersue Closed request for Early review by YANGDOCTORS with state 'Withdrawn': Double request
2021-01-11
06 Kent Watsen Requested Last Call review by YANGDOCTORS
2021-01-11
06 Kent Watsen Requested Early review by YANGDOCTORS
2020-11-16
06 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-06.txt
2020-11-16
06 (System) New version accepted (logged-in submitter: Mahesh Jethanandani)
2020-11-16
06 Mahesh Jethanandani Uploaded new revision
2020-10-21
05 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-05.txt
2020-10-21
05 (System) New version approved
2020-10-21
05 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Kent Watsen
2020-10-21
05 Mahesh Jethanandani Uploaded new revision
2020-07-27
04 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-04.txt
2020-07-27
04 (System) New version accepted (logged-in submitter: Mahesh Jethanandani)
2020-07-27
04 Mahesh Jethanandani Uploaded new revision
2020-07-20
03 Mahesh Jethanandani Added to session: IETF-108: netconf  Tue-1100
2020-07-10
03 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-03.txt
2020-07-10
03 (System) New version accepted (logged-in submitter: Mahesh Jethanandani)
2020-07-10
03 Mahesh Jethanandani Uploaded new revision
2020-03-09
02 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-02.txt
2020-03-09
02 (System) New version approved
2020-03-09
02 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Kent Watsen
2020-03-09
02 Mahesh Jethanandani Uploaded new revision
2019-10-30
01 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-01.txt
2019-10-30
01 (System) New version accepted (logged-in submitter: Mahesh Jethanandani)
2019-10-30
01 Mahesh Jethanandani Uploaded new revision
2019-09-23
00 Kent Watsen IETF WG state changed to WG Document from In WG Last Call
2019-09-23
00 Kent Watsen IETF WG state changed to In WG Last Call from WG Document
2019-09-17
00 Mahesh Jethanandani This document now replaces draft-mahesh-netconf-https-notif instead of None
2019-09-17
00 Mahesh Jethanandani New version available: draft-ietf-netconf-https-notif-00.txt
2019-09-17
00 (System) WG -00 approved
2019-09-17
00 Mahesh Jethanandani Set submitter to "Mahesh Jethanandani ", replaces to (none) and sent approval email to group chairs: netconf-chairs@ietf.org
2019-09-17
00 Mahesh Jethanandani Uploaded new revision