[netconf] Lars Eggert's Discuss on draft-ietf-netconf-https-notif-13: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-netconf-https-notif-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/



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


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