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

[Alex Huang Feng <[e-mail]>]

Hi Kent, 

Responses below. 

Alex Huang 


De: "Kent Watsen" <[e-mail]> 
À: "Alex Huang Feng" <[e-mail]> 
Cc: "draft-ietf-netconf-https-notif" <[e-mail]>, "pierre francois" <[e-mail]>, "Axel Rosenstiehl" <[e-mail]>, [e-mail] 
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.