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

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Feb 2021 12:52:03 -0800

Hi,

I reviewed draft-07 that was just published.

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.

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.

Andy

On Thu, Jan 14, 2021 at 5:12 AM Rob Wilton (rwilton) <rwilton=
[email-masked]> wrote:

> This message begins a two-week WGLC for draft-ietf-netconf-https-notif-06
> ending on Jan 28.  Here is a direct link to the HTML version of the draft:
>
>         https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06
>
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
>
> Please note, the reason that I am making this request rather than the
> WG chairs is because both chairs are listed as authors on this document.
>
> Thank you,
> Rob Wilton, OPS AD
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Feb 2021 21:23:35 +0000

Some updates for my comments for -07 based on the requests for -06.

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Eric Voit (evoit)
> Sent: Monday, January 25, 2021 9:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
> 
> I have reviewed this document.  I believe it close to being ready.  I do
have three
> comments:
> 
> (1) Section 1.1
> There was an interaction in July 2020 about describes why subscription
state
> change notifications are not included within the draft.
> https://mailarchive.ietf.org/arch/msg/netconf/K0jnMW3GZknxihnNjKL4UlFTfoY
> /
> https://mailarchive.ietf.org/arch/msg/netconf/CYOosxZy_-
> tKKsrCCoLmQeFvEuI/
> Actually, we are talking only about a subset of the subscription state
change
> notifications, as <Subscription-Started> is include within examples of
this
> document.
> 
> Per Alex and my earlier requests, it would be good to include which state
change
> notifications are included, and why,  so that others have this context.
This
> would allow receivers to understand that the control plane messages which
> identify the current state of the subscription on the subscriber are not
available.
> Perhaps it might even drive others who might want this functionality to
add this
> upon the current http-notif.  This might be worth including in Section
1.1,
> Applicability Statement.

The majority of examples showing <subscription-started> have been removed.
The last place where they are discussed in -07 is the end of Section 2.   I
still feel that describing the coverage or non-coverage of the set of
subscription state change notifications within a stream of event provides a
useful context.

> (2) Section 2.1
> Learning Receiver Capabilities is critical, as Configured Subscriptions
can DOS a
> receiver if adequate protections are not on the publisher.  It would be
useful to
> list this here so that the topic is not missed in an implementation.
Alternatively
> this could be addressed in Section 5.

Thank you for including this as a new section.
 
> (3)
> In Sections 1.5 and 8.3 there is a reference to
I-D.ietf-netconf-notification-
> messages.  I am not sure how this impacts the eventual completion of this
draft,
> but defer to others who know the IETF process better.

Thanks for the changes here.

Eric
 
> Thanks,
> Eric
> 
> > -----Original Message-----
> > From: netconf <[email-masked]> On Behalf Of Rob Wilton
> > (rwilton)
> > Sent: Thursday, January 14, 2021 8:12 AM
> > To: [email-masked]; [email-masked]
> > Subject: [netconf] WGLC: draft-ietf-netconf-https-notif-06
> >
> > This message begins a two-week WGLC for
> > draft-ietf-netconf-https-notif-06 ending on Jan 28.  Here is a direct
link to the
> HTML version of the draft:
> >
> ready for
> > publication", are welcome!  This is useful and important, even from
> authors.
> > Objections, concerns, and suggestions are also welcomed at this time.
> >
> > WG
> chairs
> > is because both chairs are listed as authors on this document.
> >
> > Thank you,
> > Rob Wilton, OPS AD
> >

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Feb 2021 22:28:46 +0000

Hi Eric,

> subscription state change notifications within a stream of event provides a

We’re unclear why this document should need or want to repeat what is defined in another RFC.  This document regards how to send notifications, regardless where they are defined.

As you note, Section 2 currently has the following statement:

      Note that, for RFC 8639 configured subscriptions, the very first
      notification must be the "subscription-started" notification.</t>

Perhaps we should remove this sentence too, or replace “must” with “would”, so it doesn’t should normative?   Please advise.

Thanks,
Kent and Mahesh

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Feb 2021 22:48:37 +0000

Hi Andy,

> 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)
> That is not the case here. Instead, the publisher sends an HTTPS POST for every notification
> 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

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.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Feb 2021 15:22:04 -0800

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

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2021 17:42:40 +0000

Hi Kent and Mahesh,

> > subscription state change notifications within a stream of event
> > provides a useful context.
> 
> We’re unclear why this document should need or want to repeat what is defined
> in another RFC.  This document regards how to send notifications, regardless
> where they are defined.
> 
> Perhaps we should remove this sentence too, or replace “must” with “would”,
> so it doesn’t should normative?   Please advise.

The intent of my comment was mainly to assist the understandability between drafts.   Subscription state change notifications are a part of RFC8639.  This draft's Section 1.1 Applicability statement *totally appropriately* notes that only a subset of RFC8639 constructs are applicable.  As a result subscription state change notifications are not required when leveraging this specification.  

If there is a minimum set of subscription state change notifications required or desired, it would be good to list them.   I suspect there are not (as per the Applicability Statement).  Based on this, I believe it be worth listing some implications of not having the subscription state change notifications in the Security Considerations section.  E.g., not sending a <subscription-modified> might mean a receiver can't be sure that a compliant publisher is sending the full set of events expected.   Such a statement would make it easily apparent to an implementer of the differences in functionality delivered as they choose which RFCs to support.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Fri, 19 Feb 2021 21:15:03 +0000

Hi Eric,

> The intent of my comment was mainly to assist the understandability between drafts.   Subscription state change notifications are a part of RFC8639.  

Assisting understandability is good!  :)

> This draft's Section 1.1 Applicability statement *totally appropriately* notes that only a subset of RFC8639 constructs are applicable.

The -06 "applicability statement” was removed in -07.

-07 also has an “applicability” section (Section 3.1), but it regards an entirely different matter.  That said, this “applicability” section has also been removed (or will be, when -08 is posted), per comments from Martin.

> As a result subscription state change notifications are not required when leveraging this specification.

RFC 8639 needs to state what notifications are required by valid implementations.  The notif drafts MUST NOT limit any notifications from being sent.  If there are Security Considerations related to certain notifications not being sent, they should be stated in RFC 8639.

Stated differently, the “notif” drafts define effectively *dumb* transport-level protocols.  If higher-level logic is layered on top of raw notifications, considerations for if certain notifications are *not* sent needs to be defined in the higher-level documents.

Does this make sense, or do you mean something else?  Please provide specific text that you are hoping to see included.

K.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2021 22:29:05 +0000

Hi Kent,

> Hi Eric,
> 
> 
> 
> The intent of my comment was mainly to assist the understandability between
> drafts.   Subscription state change notifications are a part of RFC8639.
> 
> This draft's Section 1.1 Applicability statement *totally appropriately* notes that
> only a subset of RFC8639 constructs are applicable.
> 

I still see "1.1.  Applicability Statement" in -v07 of
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07
 
> -07 also has an “applicability” section (Section 3.1), but it regards an entirely
> different matter.  That said, this “applicability” section has also been removed
> (or will be, when -08 is posted), per comments from Martin.
> 
> 
> 
> If there is a minimum set of subscription state change notifications required or
> desired, it would be good to list them.  I suspect there are not (as per the
> Applicability Statement).  Based on this, I believe it be worth listing some
> implications of not having the subscription state change notifications in the
> Security Considerations section.  E.g., not sending a <subscription-modified>
> might mean a receiver can't be sure that a compliant publisher is sending the full
> set of events expected.   Such a statement would make it easily apparent to an
> implementer of the differences in functionality delivered as they choose which
> RFCs to support.
> 
> RFC 8639 needs to state what notifications are required by valid
> implementations.  

RFC 8639 Section 2.7 "Subscription State Change Notifications" starts with "In addition to sending event records to receivers, a publisher MUST also send subscription state change notifications when events related to subscription management have occurred... The complete set of subscription state change notifications is described in the following subsections."   So the only optional ones are related to replay (if replay is supported) and suspension (if a publisher is capable of that.)  

> The notif drafts MUST NOT limit any notifications from being
> sent.  If there are Security Considerations related to certain notifications not
> being sent, they should be stated in RFC 8639.
> 
> Stated differently, the “notif” drafts define effectively *dumb* transport-level
> protocols.  If higher-level logic is layered on top of raw notifications,
> considerations for if certain notifications are *not* sent needs to be defined in
> the higher-level documents.

And the dumb transport is excellent.    All I was asking for is the differences in behavior between A.1 and A.2 to be noted somewhere.  The two are unlikely to be equivalent in functionality, however a reader new to the space could perceive equivalence. 

> Does this make sense, or do you mean something else?  Please provide specific
> text that you are hoping to see included.

Perhaps something like second paragraph in Section A.2 like:

Note that if the receiver requires:
* being fed metadata about the intended contents of the Event Stream,
* that changes to the publisher's configuration of Stream have occurred, or
* the publisher has temporarily suspended event transmission
then this application specific module should include functionality similar to that supported by the RFC-8639 Section 2.7 Subscription State Change Notifications. 

Eric