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

Alex Huang Feng <alex.huang-feng@insa-lyon.fr> Wed, 02 June 2021 10:13 UTC

Return-Path: <alex.huang-feng@insa-lyon.fr>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25463A3DAF; Wed, 2 Jun 2021 03:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5xCkZBe90AP; Wed, 2 Jun 2021 03:13:47 -0700 (PDT)
Received: from smtpout01-ext1.partage.renater.fr (smtpout01-ext1.partage.renater.fr [194.254.240.32]) by ietfa.amsl.com (Postfix) with ESMTP id 895FE3A3D9B; Wed, 2 Jun 2021 03:13:45 -0700 (PDT)
Received: from zmtaout01.partage.renater.fr (zmtaout01.partage.renater.fr [194.254.240.30]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id 907B061A4B; Wed, 2 Jun 2021 12:13:39 +0200 (CEST)
Received: from zmtaout01.partage.renater.fr (localhost [127.0.0.1]) by zmtaout01.partage.renater.fr (Postfix) with ESMTPS id 835671A0051; Wed, 2 Jun 2021 12:13:39 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zmtaout01.partage.renater.fr (Postfix) with ESMTP id 7C82F1A006E; Wed, 2 Jun 2021 12:13:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at zmtaout01.partage.renater.fr
Received: from zmtaout01.partage.renater.fr ([127.0.0.1]) by localhost (zmtaout01.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ILs70hmuiKZa; Wed, 2 Jun 2021 12:13:39 +0200 (CEST)
Received: from zstore-b0-031.partage.renater.fr (zstore-b0-031.partage.renater.fr [10.254.241.115]) by zmtaout01.partage.renater.fr (Postfix) with ESMTP id 465D21A0051; Wed, 2 Jun 2021 12:13:39 +0200 (CEST)
Date: Wed, 2 Jun 2021 12:13:39 +0200 (CEST)
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: draft-ietf-netconf-https-notif <draft-ietf-netconf-https-notif@ietf.org>, pierre francois <pierre.francois@insa-lyon.fr>, Axel Rosenstiehl <axel.rosenstiehl@insa-lyon.fr>, netconf@ietf.org
Message-ID: <218761490.2312562.1622628819191.JavaMail.zimbra@insa-lyon.fr>
In-Reply-To: <01000179ae5debf2-86973cf9-70d7-4601-b901-962d8ca86334-000000@email.amazonses.com>
References: <1448778391.413238.1622108131158.JavaMail.zimbra@insa-lyon.fr> <01000179ae5debf2-86973cf9-70d7-4601-b901-962d8ca86334-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_994973cb-c199-485d-9219-e90d094edda2"
X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - SAF14.1 (Mac)/8.8.8_GA_1703)
Thread-Topic: RFC8639 capability on https-notif receiver implementation
Thread-Index: JsbndvkKWUEAgqSQcQsURgEmZ63qFA==
X-Renater-Ptge-SpamState: clean
X-Renater-Ptge-SpamScore: -100
X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeljedgvdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecutffgpfetvffgtfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffkjghfufggtgfothesrgdttgerredtjeenucfhrhhomheptehlvgigucfjuhgrnhhgucfhvghnghcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqnecuggftrfgrthhtvghrnhepteevteeiheegjeevudehhfduteffheetuddvgeeiudefvdffuedvffdugeevjeeunecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepuddtrddvheegrddvgedurdduudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddtrddvheegrddvgedurdduudehpdhhvghlohepiihsthhorhgvqdgstddqtdefuddrphgrrhhtrghgvgdrrhgvnhgrthgvrhdrfhhrpdhmrghilhhfrhhomheptehlvgigucfjuhgrnhhgucfhvghnghcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqpdhrtghpthhtohepkhgvnhhtodhivghtfhesfigrthhsvghnrdhnvghtpdhrtghpthhtohepughrrghfthdqihgvthhfqdhnvghttghonhhfqdhhthhtphhsqdhnohhtihhfsehivghtfhdrohhrghdprhgtphhtthhopehpihgvrhhrvgdrfhhrrghntghoihhssehinhhsrgdq lhihohhnrdhfrhdprhgtphhtthhopegrgigvlhdrrhhoshgvnhhsthhivghhlhesihhnshgrqdhlhihonhdrfhhrpdhrtghpthhtohepnhgvthgtohhnfhesihgvthhfrdhorhhg
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bYH-79e5Y52IMELPMUvYLdYI31c>
Subject: Re: [netconf] RFC8639 capability on https-notif receiver implementation
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 10:14:00 -0000

Hi Kent, 

Responses below. 

Alex Huang 


De: "Kent Watsen" <kent+ietf@watsen.net> 
À: "Alex Huang Feng" <alex.huang-feng@insa-lyon.fr> 
Cc: "draft-ietf-netconf-https-notif" <draft-ietf-netconf-https-notif@ietf.org>rg>, "pierre francois" <pierre.francois@insa-lyon.fr>fr>, "Axel Rosenstiehl" <axel.rosenstiehl@insa-lyon.fr>fr>, netconf@ietf.org 
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.