Subject: Re: [netconf] RFC8639 capability on https-notif receiver implementation

From: Kent Watsen <[email-masked]>
Date: Thu, 27 May 2021 15:07:46 +0000

[CC-ing NETCONF WG mailing list]

Hi Alex,

Thanks for reaching out!

> I am part of Unyte team and we are now implementing and testing the https-notif protocol on the draft https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-08 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-08>
Always good to know about independent implementations in the works.

> We have implemented a library in C for the receiver and are planning to publish it as an open-source receiver implementation soon.

Nice contribution  - which capabilities will it support?

[be aware that there is an ongoing discussion regarding how capabilities should be supported: https://mailarchive.ietf.org/arch/msg/netconf/JmjttafVmRDaFzeLLNlYgrqfZWw <https://mailarchive.ietf.org/arch/msg/netconf/JmjttafVmRDaFzeLLNlYgrqfZWw>]

> We have some questions about the rfc-8639 capability (supporting the state machine defined in the rfc 8639).
> As I understood in the draft, https-notif receiver is not assumed to be a netconf/restconf server

Correct.

> and as I read in the rfc-8639, the state machine is implemented in the publisher.
> I'd like to know how does this capability impacts the receiver implementation.

Hopefully the RFC 8639 authors can chime in, but my understanding is that the various notifications (subscription-started, subscription-modified, etc.) enable the receiver to maintain a local copy of the state machine, in order to know how to internally-dispatch notifications?

> In the draft: 
> Note that, for RFC 8639 <https://datatracker.ietf.org/doc/html/rfc8639> configured subscriptions, the very first
>    notification must be the "subscription-started" notification.
> 
> Does this mean that on the receiver side, the first "/relay-notification" notification we receive is the "subscription-started" rpc body ?

Yes.

> Do we need to save a state in the receiver for later interaction ? Or the RFC 8639 support is just the first notification with the rpc ?

See previous comment, but my understanding is tenuous and hope others to chime in.

> Another observation on the draft, in the example 3.4, the json body for the GET capabilities is not valid (a colon is missed after the "receiver-capabilities").

Thanks!  Normally we run all code blocks through validation, but some of the code blocks in this draft elude that given the use of a pseudo YANG module...

> Looking forward to hearing from you,
> 
> Alex Huang Feng
> INSA de Lyon | INSA Télécom

K.