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

In a previous ballot position, Murray Kucherawy questioned if the SHOULD in Section 2 is better off as a MUST. My reading of section 2 is that it is an overview of the protocol operation, and the section is informative rather than normative. Just a suggestion, but the authors may want to lowercase the 2119 words in section 2.

Thanks for this work.

Thanks for the work done and for addressing my previous DISCUSS position at:
https://mailarchive.ietf.org/arch/msg/netconf/rx2nrr9MZRR3sXsOzERl5eWQ9UI/

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

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 ?

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.

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.

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.

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.

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?

I support Lars', Roman's and Eric's DISCUSS positions, but have nothing useful to add, other than my thanks to the authors and WG.

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.