Subject: [netconf] Configured receiver capability exchange

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Jan 2020 20:23:12 +0000

Hi Mahesh,

During the IETF 106 session, there was discussion on how both a publisher
might know if there is receiver support for
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?
include_text=1> draft-ietf-netconf-notification-messages.  Section 6
highlights several of the considerations.   Relevant are the following:

(a) Remote device capability discovery from the point of view of the
Publisher needs to be enhanced to know if the far end can interpret
notification messages type beyond RFC-5277, Section 4.

(b) This capability discovery question is relevant for both configured
subscription receivers and dynamic subscribers.  

(c) The capability discovery question can be generalized beyond
subscriptions, as there are many reasons to know the available capabilities
of the far end.   

(d) Capability discovery advertisement has traditionally been discussed
within transport documents (e.g. RFC-6241 Section 8.1).   

Based on (a)-(d), coming up with a transport independent point-solution
within
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?
include_text=1> draft-ietf-netconf-notification-messages *just* to discover
this single element of client functionality seems overkill/heavyweight.

I was fine with letting this remote capabilities discovery question sit for
a while.   However draft-ietf-netconf-https-notif
<https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01>  shows that
we now must address this question.  Specifically should the diagram section
1.4.1 show this capability exchange?  

It turns out that independent of draft-ietf-netconf-notification-messages,
there several questions in draft-ietf-netconf-https-notif which need to be
answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with
YANG defined notification #1" anyway.  These questions are:

  (1) Does the targeted HTTPS receiver support configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a new subscription as described
in a <subscription-started>?

Only if these questions are "yes", should the <subscription-started> be
responded to with an "OK".

Add to this a third question driven from (a)-(d):

  (3) Does the receiver support the message type within
"draft-ietf-netconf-notification-messages"?

A strawman way to handle the all three questions within
draft-ietf-netconf-https-notif would be to respond to a
<subscription-started> notification with an HTTP Status 202 (Accepted)"
acknowledgement.  This 202 would include body elements listing supported
receiver resources.  Maybe something YANG encoded via
ietf-yang-structure-ext containing:

      <foo xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

        <capabilities>

          <capability>

            urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

          </capability>

        </capabilities>

      </foo>

What do you think of this approach?

Eric

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 17 Jan 2020 12:27:09 +0000

Hello,

I would like a discovery mechanism that does not include a mandatory
additional message roundtrip. 

Most of the times the subscriber will be aware of the receivers
capabilities, in these cases so discovery is not needed; so don’t add
overhead.

Customers also indicated that they anticipate that TCP/TLS will often be
used only for a few notifications broken down and later reestablished so any
overhead we add will be added for each (many) session setup. 

Regards Balazs

From: netconf <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: 2020. január 15., szerda 21:23
To: Mahesh Jethanandani <[email-masked]>
Cc: [email-masked]
Subject: [netconf] Configured receiver capability exchange

Hi Mahesh,

 

        <capabilities>

          <capability>

          </capability>

        </capabilities>

      </foo>

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 Jan 2020 15:14:35 +0000

> Hi,
> 
> Mahesh Jethanandani <[email-masked]> wrote:
> > Hi Eric,
> >
> > Specifically to your suggestion towards
> > draft-ietf-netconf-https-notif, and its ability to learn the receiver
> > capabilities …
> >
> > As you might have seen, we had suggested a rather simple mechanism to
> > learn the capabilities of the receiver that involved a GET with a
> > specific Content-Type to invoke a response that returns the metadata
> > we desire. All the method requires is a HTTP(S) server at the other
> > end. If the Content-Type is not supported by the server, the server
> > will return an error. We like it for its simplicity.
> 
> I prefer this over the proposal to (mis?)use <subscription-started>.
> 
> First of all, one thing you want to discover is the encoding for notifications.
> <subscription-started> is a notification.  So which encoding should be used
> to send it?

<subscription-started> is just for configured subscriptions.  The encoding is set as part of the publisher configuration.
 
> Second, there is no "reply" defined for <subscription-started> since it is a
> one-way notification, so adding that seems a bit out of place.

With configured subscriptions, there is a need the receiver to confirm acceptance of the subscription.  Otherwise, configured subscriptions becomes a denial-of-service risk.  As a result of this need, there is the following text in the Security Considerations of RFC-8639:

  With configured subscriptions, one or more publishers could be used
   to overwhelm a receiver.  To counter this, notification messages
   SHOULD NOT be sent to any receiver that does not support this
   specification.  Receivers that do not want notification messages need
   only terminate or refuse any transport sessions from the publisher.

This is one reason we already need to do an "ok" is in reply to the HTTP, even without capability exchange.   I am just thinking we can use the already needed "OK" message for additional information on receiver capabilities.

Eric

> /martin
> 
> 
> 
> >
> > Your suggestion is of using <subscription-started>. Does that not
> > involve having a RESTCONF/NETCONF server support on the receiver? If
> > <subscription-started> is supported, does it mean
> > <subscription-modified> or <subscription-terminated> also needs to be
> > supported? If we do not/cannot support modification of subscription,
> > and instead require establishment of a new subscription to learn of
> > modifications, what would we be missing out with the GET method? Could
> > subscription be terminated simply by terminating the session?
> >
> > Thanks.
> >
> > > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <[email-masked]>
> > > wrote:
> > >
> > > Hi Mahesh,
> > >
> > > During the IETF 106 session, there was discussion on how both a
> > > publisher might know if there is receiver support for
> > > draft-ietf-netconf-notification-messages
> > > <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-
> messages/?include_text=1>.
> > > Section 6 highlights several of the considerations.  Relevant are
> > > the
> > > following:
> > >
> > > (b) This capability discovery question is relevant for both
> > > configured subscription receivers and dynamic subscribers.
> > >
> > > subscriptions, as there are many reasons to know the available
> > > capabilities of the far end.
> > >
> > > (d) Capability discovery advertisement has traditionally been
> > > discussed within transport documents (e.g. RFC-6241 Section 8.1).
> > >
> > >
> > > Based on (a)-(d), coming up with a transport independent
> > > point-solution within draft-ietf-netconf-notification-messages
> > > <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-me
> > > ssages/?include_text=1>
> > > *just* to discover this single element of client functionality seems
> > > overkill/heavyweight.
> > >
> > > I was fine with letting this remote capabilities discovery question
> > > sit for a while.  However draft-ietf-netconf-https-notif
> > > <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01>
> > > shows that we now must address this question.  Specifically should
> > > the diagram section 1.4.1 show this capability exchange?
> > >
> > > It turns out that independent of
> > > draft-ietf-netconf-notification-messages, there several questions in
> > > draft-ietf-netconf-https-notif which need to be answered prior to
> > > the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined
> > > notification #1" anyway.  These questions are:
> > >   (2) Can the targeted HTTP@ receiver accept a new subscription as
> > >   described in a <subscription-started>?
> > > Only if these questions are "yes", should the <subscription-started>
> > > be responded to with an "OK".
> > >
> > > <subscription-started> notification with an HTTP Status 202
> > > (Accepted)" acknowledgement.  This 202 would include body elements
> > > listing supported receiver resources.  Maybe something YANG encoded
> > > via ietf-yang-structure-ext containing:
> > >
> > Mahesh Jethanandani
> > [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 28 Jan 2020 17:27:18 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> <subscription-started> is just for configured subscriptions.  The
> encoding is set as part of the publisher configuration.

My bad (but perhaps unfortunate that this needs to be manually
configured, rather than dynamically agreed upon).

Anyway, the <subscription-started> notification must be sent in some
message format.  Should it be 5277-style or
draft-ietf-netconf-notification-messages-style?

> With configured subscriptions, there is a need the receiver to confirm
> acceptance of the subscription.  Otherwise, configured subscriptions
> becomes a denial-of-service risk.  As a result of this need, there is
> the following text in the Security Considerations of RFC-8639:
> 
> This is one reason we already need to do an "ok" is in reply to the
> HTTP, even without capability exchange.  I am just thinking we can use
> the already needed "OK" message for additional information on receiver
> capabilities.

Not sure I follow how this is a need to do an "ok" and what that would
be.  In my understanding, when the publisher needs to send a
notification to a configured receiver that is doing https-notif, it
will open an HTTPS session (unless there already is one active) and
POST the notification in some format, with some encoding.  The HTTPS
server will reply 200 OK or an error, or perhaps close the session.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 Jan 2020 17:05:44 +0000

> From: Martin Bjorklund, January 28, 2020 11:27 AM
> 
> > > > draft-ietf-netconf-https-notif, and its ability to learn the
> > > > receiver capabilities …
> > > >
> > > > As you might have seen, we had suggested a rather simple mechanism
> > > > to learn the capabilities of the receiver that involved a GET with
> > > > a specific Content-Type to invoke a response that returns the
> > > > metadata we desire. All the method requires is a HTTP(S) server at
> > > > the other end. If the Content-Type is not supported by the server,
> > > > the server will return an error. We like it for its simplicity.
> > >
> > > <subscription-started> is a notification.  So which encoding should
> > > be used to send it?
> >
> My bad (but perhaps unfortunate that this needs to be manually configured,
> rather than dynamically agreed upon).
> 
> message format.  Should it be 5277-style or draft-ietf-netconf-notification-
> messages-style?

To me it seems that 5277-style makes sense if the publisher is unsure of draft-ietf-netconf-notification-messages support.  That way the Publisher then has an option to move further YANG notifications to draft-ietf-netconf-notification-messages should the receiver indicate capability support. 

> > > Second, there is no "reply" defined for <subscription-started> since
> > > it is a one-way notification, so adding that seems a bit out of
> > > place.
> >
> Not sure I follow how this is a need to do an "ok" and what that would be.
> In my understanding, when the publisher needs to send a notification to a
> configured receiver that is doing https-notif, it will open an HTTPS session
> (unless there already is one active) and POST the notification in some
> format, with some encoding.  The HTTPS server will reply 200 OK or an error,
> or perhaps close the session.

In the beginning of this thread, I suggest some thoughts on this for Section 1.4.1.  Hopefully a future draft version can clarify these specifics.

Eric

> > > > involve having a RESTCONF/NETCONF server support on the receiver?
> > > > If <subscription-started> is supported, does it mean
> > > > <subscription-modified> or <subscription-terminated> also needs to
> > > > be supported? If we do not/cannot support modification of
> > > > subscription, and instead require establishment of a new
> > > > subscription to learn of modifications, what would we be missing
> > > > out with the GET method? Could subscription be terminated simply by
> terminating the session?
> > > >
> > > > Thanks.
> > > >
> > > > > Section 6 highlights several of the considerations.  Relevant
> > > > > are the
> > > > > following:
> > > > >
> > > > > (a) Remote device capability discovery from the point of view of
> > > > > the Publisher needs to be enhanced to know if the far end can
> > > > > interpret notification messages type beyond RFC-5277, Section 4.
> > > > >
> > > > > *just* to discover this single element of client functionality
> > > > > seems overkill/heavyweight.
> > > > >
> > > > > I was fine with letting this remote capabilities discovery
> > > > > question sit for a while.  However
> > > > > draft-ietf-netconf-https-notif
> > > > > shows that we now must address this question.  Specifically
> > > > > should the diagram section 1.4.1 show this capability exchange?
> > > > >
> > > > > draft-ietf-netconf-notification-messages, there several
> > > > > questions in draft-ietf-netconf-https-notif which need to be
> > > > > answered prior to the section 1.4.1 arrow: "Send HTTPS POST
> > > > > message with YANG defined notification #1" anyway.  These
> questions are:
> > > > > Only if these questions are "yes", should the
> > > > > <subscription-started> be responded to with an "OK".
> > > > >
> > > > > (Accepted)" acknowledgement.  This 202 would include body
> > > > > elements listing supported receiver resources.  Maybe something
> > > > > YANG encoded via ietf-yang-structure-ext containing:
> > > > >

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Jan 2020 10:13:09 -0800

On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani <[email-masked]>
wrote:

> Hi Eric,
>
> This e-mail triggers two responses. Let us deal with
> draft-ietf-netconf-notification-messages here, and I will bring up
> comments/questions related to draft-ietf-netconf-https-notif in the other
> thread.
>
> You have indicated a desire that receiver capabilities should be
> documented by the transport specific draft, e.g.
> draft-ietf-netconf-https-notif, and not this draft. As such you believe
> that the draft is ready.
>
> To the WG, the authors have indicated a desire to wrap up this draft, and
> would like us, the chairs, to issue a WGLC on it. Before we do that, we
> wanted to ask if the WG believes that the document is ready, and that there
> are no more issues that need to discussed/addressed by
> draft-ietf-netconf-notification-messages document at this time.
>
>

I would like to see clear and consistent text wrt to RFC 5277.
There is this confusing text:

      YANG one-way exchanges currently use a non-extensible header and

   encoding defined in section 4 of RFC-5277
<https://tools.ietf.org/html/rfc5277#section-4>.  These RFCs MUST be
   updated to enable this draft.  These RFCs SHOULD be updated to
   provide examples

This seems inconsistent with this text:

  Backwards Compatibility

   With this specification, there is no change to YANG's 'notification'
   statement

   Legacy clients are unaffected, and existing users of [RFC5277
<https://tools.ietf.org/html/rfc5277>],
   [RFC7950 <https://tools.ietf.org/html/rfc7950>], and [RFC8040
<https://tools.ietf.org/html/rfc8040>] are free to use current
behaviors until all
   involved device support this specification.

It is rather odd to see RFC 2119 language used for a directive to a WG
to take on some sort of work item. (RFCs MUST be updated)

I think this draft needs some sort of Applicability Statement. Why are
servers supposed
to use this header and stop using the RFC 5277 header?  The mandatory info
like subscription-id
is redundant since the payload already has this info.

This new header can make it much more difficult for a client to write code
to process a notification,
since the header itself would be modeled with YANG and subject to change.
The processing
may also be slower because the added complexity.  It does not seem that
every server needs
this added complexity.

Cheers.
>
> Mahesh and Kent (as co-chairs).
>
>

Andy

> On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <[email-masked]> wrote:
>
> Hi Mahesh,
>
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1>.
> Section 6 highlights several of the considerations.   Relevant are the
> following:
>
> within draft-ietf-netconf-notification-messages
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1>
> I was fine with letting this remote capabilities discovery question sit
> for a while.   However draft-ietf-netconf-https-notif
> <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> shows
> that we now must address this question.  Specifically should the diagram
> section 1.4.1 show this capability exchange?
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 31 Jan 2020 18:04:00 +0000

Hi Andy,

From: Andy Bierman, January 28, 2020 1:13 PM

On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani <[email-masked] 
<mailto:[email-masked]> > wrote:

Hi Eric,

You have indicated a desire that receiver capabilities should be documented by 
the transport specific draft, e.g. draft-ietf-netconf-https-notif, and not 
this draft. As such you believe that the draft is ready.

To the WG, the authors have indicated a desire to wrap up this draft, and 
would like us, the chairs, to issue a WGLC on it. Before we do that, we wanted 
to ask if the WG believes that the document is ready, and that there are no 
more issues that need to discussed/addressed by 
draft-ietf-netconf-notification-messages document at this time.

   encoding defined in section <https://tools.ietf.org/html/rfc5277#section-4> 
4 of RFC-5277.  These RFCs MUST be
   updated to enable this draft.  These RFCs SHOULD be updated to
   provide examples

  Backwards Compatibility

   Legacy clients are unaffected, and existing users of [RFC5277 
<https://tools.ietf.org/html/rfc5277> ],
   [RFC7950 <https://tools.ietf.org/html/rfc7950> ], and [RFC8040 
<https://tools.ietf.org/html/rfc8040> ] are free to use current behaviors 
until all
   involved device support this specification.

<eric> I don't see these as inconsistent.  The YANG notification statement is 
defined in RFC-7950 Section 7.16.   And legacy clients do not need to change.

<eric>  I agree that RFC 2119 language is not proper here.  Perhaps the 
specific changes should be framed as notes to RFC editor.

I think this draft needs some sort of Applicability Statement. Why are servers 
supposed

to use this header and stop using the RFC 5277 header?

<eric> Makes sense, I will put together some text on this.

The mandatory info like subscription-id is redundant since the payload already 
has this info.

<eric> The subscription-id is only in the notifications defined in RFC-8641. 
I.e. "push-update" and " push-change-update".  This is the biggest gap which 
needs to be remedied.

This new header can make it much more difficult for a client to write code to 
process a notification,

since the header itself would be modeled with YANG and subject to change.  The 
processing

may also be slower because the added complexity.  It does not seem that every 
server needs

this added complexity.

<eric> This is one reason that this specification isn't ready to obsolete 
RFC-5277 notifications.

Eric

Cheers.

Andy

On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <[email-masked] 
<mailto:[email-masked]> > wrote:

Hi Mahesh,

During the IETF 106 session, there was discussion on how both a publisher 
might know if there is receiver support for 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> 
draft-ietf-netconf-notification-messages.  Section 6 highlights several of the 
considerations.   Relevant are the following:

(a) Remote device capability discovery from the point of view of the Publisher 
needs to be enhanced to know if the far end can interpret notification 
messages type beyond RFC-5277, Section 4.

(c) The capability discovery question can be generalized beyond subscriptions, 
as there are many reasons to know the available capabilities of the far end.

(d) Capability discovery advertisement has traditionally been discussed within 
transport documents (e.g. RFC-6241 Section 8.1).

Based on (a)-(d), coming up with a transport independent point-solution within 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> 
draft-ietf-netconf-notification-messages *just* to discover this single 
element of client functionality seems overkill/heavyweight.

I was fine with letting this remote capabilities discovery question sit for a 
while.   However 
<https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> 
draft-ietf-netconf-https-notif shows that we now must address this question. 
Specifically should the diagram section 1.4.1 show this capability exchange?

It turns out that independent of draft-ietf-netconf-notification-messages, 
there several questions in draft-ietf-netconf-https-notif which need to be 
answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG 
defined notification #1" anyway.  These questions are:

A strawman way to handle the all three questions within 
draft-ietf-netconf-https-notif would be to respond to a <subscription-started> 
notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 
would include body elements listing supported receiver resources.  Maybe 
something YANG encoded via ietf-yang-structure-ext containing:

        <capabilities>

          <capability>

          </capability>

        </capabilities>

      </foo>

Eric

Mahesh Jethanandani

[email-masked] <mailto:[email-masked]>

_______________________________________________
netconf mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jan 2020 11:13:36 -0800

Hi Eric,

All these changes sound good to me.

How about changing the cited text:

OLD:
These RFCs MUST be updated to enable this draft.
These RFCs SHOULD be updated to provide examples

NEW:
These RFCs need to be updated to enable this draft and provide examples.

Andy

On Fri, Jan 31, 2020 at 10:04 AM Eric Voit (evoit) <[email-masked]> wrote:

> Hi Andy,
>
>
>
> *From:* Andy Bierman, January 28, 2020 1:13 PM
>
> On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani <
> [email-masked]> wrote:
>
> Hi Eric,
>
>
>
>    encoding defined in section 4 of RFC-5277 <https://tools.ietf.org/html/rfc5277#section-4>.  These RFCs MUST be
>
>    Legacy clients are unaffected, and existing users of [RFC5277 <https://tools.ietf.org/html/rfc5277>],
>
>    [RFC7950 <https://tools.ietf.org/html/rfc7950>], and [RFC8040 <https://tools.ietf.org/html/rfc8040>] are free to use current behaviors until all
>
> <eric> I don't see these as inconsistent.  The YANG notification statement
> is defined in RFC-7950 Section 7.16.   And legacy clients do not need to
> change.
>
>
> The mandatory info like subscription-id is redundant since the payload
> already has this info.
>
> <eric> The subscription-id is only in the notifications defined in
> RFC-8641.   I.e. "push-update" and " push-change-update".  This is the
> biggest gap which needs to be remedied.
>
>
>
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> *just*
> to discover this single element of client functionality seems
> overkill/heavyweight.
>
>
>