Re: [netconf] Configured receiver capability exchange

["Eric Voit (evoit)" <[e-mail]>]

Hi Balazs,

 

The proposal below wouldn't have another roundtrip.  Basically the 'OK'
response to a <subscription-started> would include the receiver
capabilities.

 

As there could be multiple configured subscriptions, these receiver
capabilities could end up being delivered a number of times.  I guess we
might then only include the receiver capabilities for the first configured
subscription established to that receiver.

 

Eric

 

From: Balázs Lengyel <[e-mail]
<mailto:[e-mail]> > 
Sent: Friday, January 17, 2020 7:27 AM
To: Eric Voit (evoit) <[e-mail] <mailto:[e-mail]> >; Mahesh
Jethanandani <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: RE: Configured receiver capability exchange

 

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 <[e-mail] <mailto:[e-mail]> >
On Behalf Of Eric Voit (evoit)
Sent: 2020. január 15., szerda 21:23
To: Mahesh Jethanandani <[e-mail]
<mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: [netconf] Configured receiver capability exchange

 

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