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

From: Alex Huang Feng <[email-masked]>
Date: Wed, 2 Jun 2021 12:13:39 +0200 (CEST)

Hi Kent, 

Responses below. 

Alex Huang 

De: "Kent Watsen" <[email-masked]> 
À: "Alex Huang Feng" <[email-masked]> 
Cc: "draft-ietf-netconf-https-notif" <[email-masked]>, "pierre francois" <[email-masked]>, "Axel Rosenstiehl" <[email-masked]>, [email-masked] 
Envoyé: Jeudi 27 Mai 2021 17:07:46 
Objet: Re: RFC8639 capability on https-notif receiver implementation 

[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. 

[Alex]: Are there any others https-notif independent implementations apart from us ? Any vendor or existant publisher/receiver ? 

BQ_BEGIN

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

BQ_END

Nice contribution - which capabilities will it support? 
[Alex]: We are now supporting both encodings json and xml. I am still trying to understand the rfc-8639 state machine capability but still not understand why should we save a copy of the state machine on the receiver side. Moreover, for configured notifications, the rfc-8539 capability is not necessary right ? 

[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 ] ] 

[Alex]: In my opinion, the capabilities export should be independent from the "transport" notifications draft. Let's discuss it on the other thread. 

BQ_BEGIN

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 

BQ_END

Correct. 

BQ_BEGIN

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. 

BQ_END

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? 
[Alex]: Internally dispatch to whom ? The receiver/client has already received the notification at this moment right ? So it has to "deal" with at this moment ? Or I misunderstood the notification flow ? 

BQ_BEGIN

In the draft: 
Note that, for [ https://datatracker.ietf.org/doc/html/rfc8639 | RFC 8639 ] 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 ? 

BQ_END

Yes. 

BQ_BEGIN

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 ? 

BQ_END

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

BQ_BEGIN

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"). 

BQ_END

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... 

BQ_BEGIN

Looking forward to hearing from you, 

Alex Huang Feng 
INSA de Lyon | INSA Télécom 

BQ_END

K.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 2 Jun 2021 14:39:48 +0000

[CC-ing Eric Voit]

> [Alex]: Are there any others https-notif independent implementations apart from us ? Any vendor or existant publisher/receiver ?

Not that I’m aware of.

> [Alex]: We are now supporting both encodings json and xml. I am still trying to understand the rfc-8639 state machine capability but still not understand why should we save a copy of the state mach…

Maybe Eric can say?

> We have some questions about the rfc-8639 capability (supporting the state machine defined in the rfc 8639).

It’s beginning to look at way to me as well, but the other thread is discussing it…

> [Alex]: Internally dispatch to whom ? The receiver/client has already received the notification at this moment right ? So it has to "deal" with at this moment ? Or I misunderstood the notification…

Hopefully Eric can explain.

K.