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

This document is dependent on draft-ietf-netconf-http-client-server. Once the DISCUSS of that document is addressed, this document will have to be updated with the new tree diagram and any updates related to the changes in the other document.

[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.

[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.

[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?

[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.

[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").

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

[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.

[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?

[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").

[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").

[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").

[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 ?

[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.

[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.

[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.

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

[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 ?

[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

[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.

[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

[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.

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.

(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

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.

# 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/

# 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/

# 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/

# 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/