Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

[Qin Wu <[e-mail]>]

Hi, Mahesh:
I am thinking whether rfc8639<https://datatracker.ietf.org/doc/html/rfc8639>-enabled should be listed as encoding related capability, which is a little weird to me and I think it is different xml encoding, json ecoding, I believe this has been brought up in yesterday meeting at the end of presentation.
Also for Publisher to receiver interaction it is not clear why the second target resource is called “relay-notification”? What relay means in this HTTP notif context?

As for capability discovery and advertisement proposed in draft-ietf-netconf-https-notif-08 and draft-tao-netconf-data-export-capabilities<https://tools.ietf.org/id/draft-tao-netconf-data-export-capabilities-03.txt>, I believe I raised issues for discussion when both work are under progress, my impression, is
Both are one way message, used in different scenario which can be complementary. Now this issue has been brought up again in yesterday netconf session. The question is whether should take holistic way to handle the capability.

I think
1.http notif  defines receiver capability discovery which allow publisher discover what encoding is supported by the receiver,
2.data export capabilities define data export capability advertisement which is built on top of server capability advertisement
specified in draft-ietf-netconf-notification-messages<https://tools.ietf.org/wg/netconf/draft-ietf-netconf-notification-messages/>. Data export capability draft allow the receiver to learn the server capability
including transport protocol, encoding format.
Commonality for these capability discovery or advertisement is both are one way message.
The difference is data export capabilities define generic mechanism can work together with RFC8639 and UDP Notif draft,
RFC8639 “2.4.2.  Establishing a Dynamic Subscription” said:
“
If the transport used by the RPC supports multiple encodings, an
      optional "encoding" for the event records pushed.  If no
      "encoding" is included, the encoding of the RPC MUST be used.
”
So data export capabilities advertise multiple encodings from the server to the client, the client can use RFC8639 Dynamic subscription to select the encoding advertised by the server or configure the client favored encoding on the server.
So does the UDP notif, the server advertises multiple encoding support the client, the client use RFC8639 Dynamic Subscription to select encoding advertised by the server or configure client favored encoding on the server.

If we consider to use server capability advertisement in data export capability draft together with receiver capability in http notif together, I think we should focus on non-RFC8639 capability case, in such case,
The server can use a single message not only advertise the what encoding is supported by the server but also request the encoding supported by the client, This seems to provide more control to the publisher to control the encoding to be used rather than provide control to the client and allow the client configure encoding support for the transport designed for publisher. I am not sure whether this case makes sense, this needs to be investigated.

-Qin
发件人: netconf [mailto:[e-mail]] 代表 Mahesh Jethanandani
发送时间: 2021年2月23日 7:39
收件人: [e-mail]
主题: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

Hi WG,

The authors believe that this version of the draft addresses comments received during LC.

Thanks.


On Feb 22, 2021, at 3:33 PM, [e-mail]<mailto:[e-mail]> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

       Title           : An HTTPS-based Transport for YANG Notifications
       Authors         : Mahesh Jethanandani
                         Kent Watsen
  Filename        : draft-ietf-netconf-https-notif-08.txt
  Pages           : 27
  Date            : 2021-02-22

Abstract:
  This document defines a protocol for sending notifications over
  HTTPS.  YANG modules for configuring publishers are also defined.
  Examples are provided illustrating how to configure various
  publishers.

  This document requires that the publisher is a "server" (e.g., a
  NETCONF or RESTCONF server), but does not assume that the receiver is
  a server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-08
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>