Subject: Re: [netconf] Capability-fetching mechanisms

From: Qin Wu <[email-masked]>
Date: Wed, 12 May 2021 01:51:33 +0000

Hi, Kent:
Sorry for late follow up.
On Apr 19, 2021, at 5:39 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG,

One of the outcomes from “https-notif” presentation during the NETCONF 110 session was to what extent all the notif (e.g., https, udp, etc.) drafts should define their own capability-fetching mechanism, or use the mechanism defined by the "data-export-capabilities” draft.

As authors, Mahesh and I discussed some of the PROs and CONs of the approaches as follows:
[Qin]:I am under impression that shared-mechanism has a lot of benefit.:-)

  *   PROs (for having a shared-mechanism):

     *   Enables a common mechanism spanning multiple notif transports to exist

  *   CONs (against having a shared mechanism):

     *   Entails each receiver also needing to be a NETCONF and/or RESTCONF server
                                [Qin]:Is receiver in this context NETCONF/RESTCONF server or client?
                                  I think we mix two things,

a.       one is the server advertise its capability to the client , (i.e., server capability advertisement)

b.       the other is server send the capability query request the client and get capability response from the client. (client capability fetching)
                                I think data-export-capabilities right now focuses on (a), the question you ask here is whether (b) can be defined as shared mechanism which can be part of
                                the "data-export-capabilities” draft. If my understanding is correct, I think it will be nice to have (b) such shared mechanism, i.e., Defining (a) and (b) in a single place.

        *   Whereas a notif-specific solution can be optimized on a per-protocol basis.
        *   FWIW, if RC, the receiver COULD minimally support *just* the single GET request (i.e., not a complete RC server)
        *   Still, networking/firewall would have to support the outbound NC/RC flow, in addition to the base notification flow
                   [Qin]: "data-export-capabilities " draft uses draft-ietf-netconf-notification-capabilities-16 as basis or foundation. If my understanding is correct, draft-ietf-netconf- notification-capabilities-16 doesn’t
require receiver to support NETCONF or   RESTCONF.

     *   Potentially extends the number of capabilities to be more than minimally necessary

        *   e.g., the current "data-export-capabilities” modules define dozens of capabilities supporting RFC 8639 and RFC 8641 that are not needed for https-notif,
                                     [Qin] Dozens of capabilities defined by the current "data-export-capabilities” modules are all optional capability. It doesn’t require all the capabilities to be supported.
when RFC 8639 is not in use.

           *   HTTPS-Notif seems to need only three capabilities:

              *   What encodings are supported (json, xml, binary)
              *   If the RFC 8639 state machine is supported.
              *   If bundled messages is supported.
                                  [Qin]: So HTTPs-notif can pick those three capabilities and ignore other capabilities.  I believe HTTP has mechanism to deal with these unhandled capabilities advertised by the network device.  One of such example is unhandled
Namespace defined in (https://datatracker.ietf.org/doc/html/draft-ietf-regext-unhandled-namespaces-07)

           *   Presumably, UDP-Notif would similarly have a small set of capacities.

              *   In fact, it may be less, as UDP may be unable to support RFC 8639
             [Qin]: See clarification above. For UDP notif, it doesn’t require all the capability to be supported.

Thoughts?

Kent and Mahesh  // as authors

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

---

From: "Wei Wang" <[email-masked]>
Date: Wed, 12 May 2021 13:31:51 +0800

Hi, Qin and kent：

&nbsp; &nbsp; Thanks for clarification, I feel it will be useful to have one common model to support both pull and push approach and help both the server and client know each other’s capability.

Wei
China Telecom

------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Qin Wu"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Wed, May 12, 2021 09:51 AM
To:&nbsp;"Kent Watsen"<[email-masked]&gt;;"[email-masked]"<[email-masked]&gt;;

Subject:&nbsp;Re: [netconf] Capability-fetching mechanisms

Hi, Kent:

On Apr 19, 2021, at 5:39 PM, Kent Watsen <[email-masked]&gt; wrote:

&nbsp;
   
Dear WG,
  
&nbsp;

&nbsp;

 PROs (for having a shared-mechanism):
   
 Enables a common mechanism spanning multiple notif transports to exist 
   
 CONs (against having a shared mechanism):
   
 Entails each receiver also needing to be a NETCONF and/or RESTCONF server
  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin]:Is receiver in this context NETCONF/RESTCONF server  or client? 
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think we mix two things, 
 
 a.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  one is the server advertise its capability to the client , (i.e., server capability advertisement)
 
 b.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  the other is server send the capability query request the client and get capability response from the client. (client capability fetching)
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think data-export-capabilities right now focuses on  (a), the question you ask here is whether (b) can be defined as shared mechanism which can be part of 
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the "data-export-capabilities” draft. If my understanding is correct, I think it will be nice to have (b) such shared  mechanism, i.e., Defining (a) and (b) in a single place.
    
 Whereas a notif-specific solution can be optimized on a per-protocol basis.

 FWIW, if RC, the receiver COULD minimally support *just* the single GET request (i.e., not a complete RC server)

 Still, networking/firewall would have to support the outbound NC/RC flow, in addition to the base notification flow
   
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin]: "data-export-capabilities " draft uses draft-ietf-netconf-notification-capabilities-16  as basis or foundation. If my understanding is correct, draft-ietf-netconf- notification-capabilities-16 doesn’t 
 
 require receiver to support NETCONF or &nbsp; RESTCONF.
   
 Potentially extends the number of capabilities to be more than minimally necessary
     
 e.g., the current "data-export-capabilities” modules define dozens of capabilities supporting RFC 8639 and RFC 8641 that are not needed for https-notif, 
   
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin] Dozens of capabilities defined by the current "data-export-capabilities” modules are all optional capability. It doesn’t require  all the capabilities to be supported.

 HTTPS-Notif seems to need only three capabilities:
         
 What encodings are supported (json, xml, binary)

 If the RFC 8639 state machine is supported.

 If bundled messages is supported.
     
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin]: So HTTPs-notif can pick those three capabilities  and ignore other capabilities. &nbsp;I believe HTTP has mechanism to deal with these unhandled capabilities advertised by the network device.&nbsp; One of such example is unhandled

 Presumably, UDP-Notif would similarly have a small set of capacities.
         
 In fact, it may be less, as UDP may be unable to support RFC 8639

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; [Qin]: See clarification above. For UDP notif, it doesn’t require all the capability  to be supported.

&nbsp;

Thoughts?

&nbsp;

Kent and Mahesh &nbsp;// as authors

&nbsp;

&nbsp;

 [email-masked]

&nbsp;

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 12 May 2021 06:54:39 +0000

Hi, folks,

Since data-export-capability draft defines a mechanism to discover a set of capabilities supported by the NETCONF/RESTCONF server(the network device, actually).

But in the http-notif draft, what we need to discover is the receiver's capabilities, rather than the device’s.

So I think the reason Kent said that the receiver must also be a NETCONF and/or RESTCONF server is that only in this case can the data-export-capability draft be used as capability discovery on the http-receiver side.

Please correct me if there exists any misunderstanding.-:)

From my perspective, The data-export-capability does not have to require the receiver to function as a NETCONF/RESTCONF server. The capability discovery mechanism in these two drafts can complement each other in this case. In other cases, data-export-capability provides the receiver with an overall  acquisition of the transport capabilities about the device.

From: netconf [mailto:[email-masked]] On Behalf Of Wei Wang
Sent: Wednesday, May 12, 2021 1:32 PM
To: Qin Wu <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: [netconf] Capability-fetching mechanisms

Hi, Qin and kent：

    Thanks for clarification, I feel it will be useful to have one common model to support both pull and push approach and help both the server and client know each other’s capability.

Wei
China Telecom

------------------ Original ------------------
From: "Qin Wu" <[email-masked]<mailto:[email-masked]>>;
Date: Wed, May 12, 2021 09:51 AM
To: "Kent Watsen"<[email-masked]<mailto:[email-masked]>>;"[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>;
Subject: Re: [netconf] Capability-fetching mechanisms

Hi, Kent:

Dear WG,

Thoughts?

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 12 May 2021 17:13:18 -0700

Hi Qin,

When Kent and I started working on the HTTPs notif draft we wanted to make sure that it was lightweight as it relates to setting it up. That means that if the publisher and receiver are HTTPS capable, that in most cases that is all that isneeded to establish the notification channel. To quite an extent that is still true. With default values (JSON encoding), one can setup a HTTPS notification channel by configuring the *publisher* where the receiver resides (its IP address) and any credentials that are needed to setup the channel. The receiver does not need to be configured, and as such does not need to be a NETCONF/RESTCONF server (or a client for that matter).

Cheers.

> On May 11, 2021, at 6:51 PM, Qin Wu <[email-masked]> wrote:
> 
> Hi, Kent:
> On Apr 19, 2021, at 5:39 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Dear WG,
>  
> Namespace defined in (https://datatracker.ietf.org/doc/html/draft-ietf-regext-unhandled-namespaces-07 <https://datatracker.ietf.org/doc/html/draft-ietf-regext-unhandled-namespaces-07>)
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Mon, 17 May 2021 22:00:13 +0000

Hi Qiufang Ma,

> Please correct me if there exists any misunderstanding.-:)

I think that your understanding of the https-notif draft is correct.

> From my perspective, The data-export-capability does not have to require the receiver to function as a NETCONF/RESTCONF server. The capability discovery mechanism in these two drafts can complement…

I’m unclear on each of your sentences above.  Could you, for for sentence, provide more context regarding what you mean?  For instance, how could the data-export-capability draft not imply the receiver be a NC/RC server?  Likewise, how could the two drafts compliment each other?  Also, by mentioning “other cases”, but what is the ”first” case that this contrasts to?  

Thanks

K.

---

From: "maqiufang (A)" <[email-masked]>
Date: Tue, 18 May 2021 13:53:35 +0000

Hi, Kent,
Please see my reply inline.

From: Kent Watsen [mailto:[email-masked]]
Sent: Tuesday, May 18, 2021 6:00 AM
To: maqiufang (A) <[email-masked]>
Cc: Wei Wang <[email-masked]>; Qin Wu <[email-masked]>; [email-masked]
Subject: Re: [netconf] Capability-fetching mechanisms

Hi Qiufang Ma,

[Qiufang Ma] Thanks.

I’m unclear on each of your sentences above.  Could you, for for sentence, provide more context regarding what you mean?  For instance, how could the data-export-capability draft not imply the receiver be a NC/RC server?  Likewise, how could the two drafts compliment each other?  Also, by mentioning “other cases”, but what is the ”first” case that this contrasts to?
[Qiufang Ma] Sorry for being unclear.
On the one hand, data-export-capability draft  focuses more on discovering a set of capabilities supported by the publisher, and the publisher can learn the capabilities of the receiver through the mechanism defined in http-notif draft. Therefore the capability discovery mechanisms of these two drafts complement each other to realize the capability discovery of both receiver and publisher.
On the other hand, as Qin has clarified, maybe we can define a shared mechanism to fetch the receiver capability in the data-export-capability draft that does not need the receiver to be a NC/RC server.
So I do not think it would be necessary for the receiver to be a NC/RC server.

Other cases refer to cases other than capability discovery at the receiver side. For example, the receiver learns capability supported by the publisher(e.g., encoding format), which helps (e.g., in the selection of the encoding format) when establishing a dynamic subscription.

Thanks

K.