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

["Eric Voit (evoit)" <[e-mail]>]

Hi Alex,

> From: [e-mail], July 30, 2021 5:17 AM
> 
> Hi Eric and Rob,
> 
> I am still a bit confused on the draft HTTPS-notif.
> I have developed a collector for the receiver in C for the HTTPS-notif protocol
> but I still do not understand how the rfc-8639 support would work on the
> protocol. What should the collector do to support this capability? It is
> mandatory to fully support HTTPS-notif protocol?

Initially I thought draft-ietf-netconf-https-notif would require RFC-8639.  However this is not the final scope.  The authors added the Section 1,1 to clarify this:

   While the YANG modules have been defined as an augmentation of
   Subscription to YANG Notifications [RFC8639], the notification method
   defined in this document MAY be used outside of Subscription to YANG
   Notifications [RFC8639] by using some of the definitions from this
   module along with the grouping defined in Groupings for HTTP Clients
   and Servers [I-D.ietf-netconf-http-client-server].  For an example on
   how that can be done, see Section A.2.

As RFC-8650 *doesn't* define Configured Subscriptions for HTTP transport.  This means there is a gap-to-be-filled in the NETCONF specifications.  I suspect this is what you are missing in your searches.

The good news is that there is unofficial/unvalidated guidance on how this could be done.  Earlier versions of RFC-8650 did provide some text here.  See:
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-notif-06#section-4
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-notif-06#appendix-B.2

It would be great if someone from the WG picked up and completed/finalized these definitions in a new draft :-).
 
> Looking to hearing from you,
> 
> Alex Huang Feng
> INSA Lyon
> 
> > On 2 Jun 2021, at 16:39, Kent Watsen <[e-mail]> wrote:
> >
> > [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 machine on the receiver side. Moreover, for
> configured notifications, the rfc-8539 capability is not necessary right ?
> >
> > Maybe Eric can say?

It is very useful to support the RFC-8639 configured subscription state machine
https://datatracker.ietf.org/doc/html/rfc8639#section-2.5.1
and associated state change notifications.

Without these two, you are far less sure that your receiver is in sync with the publisher.  But if there is no loss in an implementation, perhaps things are will be ok.   Discussions on the implications can be seen in earlier WG mailer discussions. 


> >> [Alex]: In my opinion, the capabilities export should be independent from the
> "transport" notifications draft. Let's discuss it on the other thread.
> >> 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 flow ?
> >
> > Hopefully Eric can explain.

I am not sure if I completely understand the question.  Where RFC-8639 support is included, yes you need to react to changes in the Subscription State Change Notifications as they happen.

There is some unofficial/unvalidated guidance for this in places like:
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-notif-06#appendix-B.2

Eric

> >> Alex Huang Feng
> >> INSA de Lyon | INSA Télécom
> >
> > K.
> >