Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06

[Andy Bierman <[e-mail]>]

On Thu, Feb 18, 2021 at 2:48 PM Kent Watsen <[e-mail]> wrote:

> Hi Andy,
>
> > It seems too much of the language is limited to XML or JSON encoding.
> > The media type extensibility should be well-defined so this draft
> > does not have unintended limitations later on.
>
> We believe the defines an extensibility mechanism via the “capabilities”
> resource target, which we recently modified in our local copy in response
> to Martin’s comment enabling the capabilities to use any URI.   Please
> advise.
>
>
> > There is a significant architectural change made without any real
> mention (sec. 4)
> > In NETCONF and RESTCONF, a notification is a one-way message, meaning
> there
> > is no application layer response whatsoever.
> >
> > That is not the case here. Instead, the publisher sends an HTTPS POST
> for every notification
> > and expects a "204 No Content" response for each one.
> > The draft should explain the reasons for this change.
> > HTTP client implementations tend to wait for a response to a POST.
> > That is probably not what is intended here, but no text explains the
> details.
> >
> > Sec. 4 does not mention what the publisher is supposed to do if the
> receiver does not
> > send a response or sends something other than 204.  It seems like this
> redundant ACK
> > adds complexity and network traffic for no benefit.
>
>
> It is agreed that notifications have historically not entailed having any
> response from the receiver.  However, the HTTP protocol defines that there
> be a response, and since there is no content for a receiver to return, we
> suppose it to be 204 (No Content).
>
> That said, please note that HTTP is a sessionless/stateless protocol and
> authentication MAY be conveyed via HTTP headers, which might necessitate a
> 401 (No Authentication) response.  There may be other possible reasons to
> return other values too (though we don’t have any examples to share).
>
> To be clear, by no means are we suggesting that YANG “notification”
> statements introduce application-level responses.
>


I do not think anyone suggested redefinition of the YANG notification-stmt.
The notification delivery mechanisms are protocol-specific.
In this case the application is HTTPS and 204 No Content is a normal
response to a POST request.

IMO notification delivery is not a good use-case for HTTP POST.


> It is unclear how HTTP responses cannot be returned; the only options seem
> to be for the draft to explicitly enumerate all possible responses, or
> leave it open.  Thoughts on what text should added?
>
>
> Kent and Mahesh
>
>
>
Andy