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

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke 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:
----------------------------------------------------------------------


# É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 ?


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