Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif)
Martin Bjorklund <mbj@tail-f.com> Tue, 24 September 2019 16:48 UTC
Return-Path: <mbj@tail-f.com>
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 E1C28120133 for <netconf@ietfa.amsl.com>; Tue, 24 Sep 2019 09:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uDMI2HTGvZDB for <netconf@ietfa.amsl.com>; Tue, 24 Sep 2019 09:48:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3012013C for <netconf@ietf.org>; Tue, 24 Sep 2019 09:48:15 -0700 (PDT)
Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 288561AE018A; Tue, 24 Sep 2019 18:48:14 +0200 (CEST)
Date: Tue, 24 Sep 2019 18:48:14 +0200
Message-Id: <20190924.184814.1432116348522595319.mbj@tail-f.com>
To: evoit@cisco.com
Cc: mjethanandani@gmail.com, kent@watsen.net, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <BN7PR11MB26271822672E8BAD99387030A1840@BN7PR11MB2627.namprd11.prod.outlook.com>
References: <BN7PR11MB262795493DD8079F2A3D02EDA1840@BN7PR11MB2627.namprd11.prod.outlook.com> <20190924.155545.1143100128662277152.mbj@tail-f.com> <BN7PR11MB26271822672E8BAD99387030A1840@BN7PR11MB2627.namprd11.prod.outlook.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FGOg2fkQxe4laG7sPf4rA7uOVhU>
Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif)
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: Tue, 24 Sep 2019 16:48:27 -0000
"Eric Voit (evoit)" <evoit@cisco.com> wrote: > > From: Martin Bjorklund, September 24, 2019 9:56 AM > > > > "Eric Voit (evoit)" <evoit@cisco.com> wrote: > > > > > > > > > > > From the email I sent Martin on Sep 9th, each POST MAY contain > > > > > more than one notification: > > > > > > > > .... to which I replied: > > > > > > > > I'm not so sure about the streaming though. > > > > Perhaps pipelining is the right mechanism. For "bulk" sending, the > > > > "bundled-message" defined in > draft-ietf-netconf-notification-messages > > > > seems right. > > > > > > > > To clarify: if the client just sends a stream of notifs it becomes a > > > variant of > > > > SSE. The server doesn't know when the stream will end, and thus > > > > cannot simply close the session. You probably want to indicate > > > > end-of-message somehow (like in SSE). And the content type in the > > > > example below cannot be "application/yang-data+xml", since it is not > > > > a valid XML instance document; you'd have to invent a new media type > > to indicate the streaming. > > > > > > > > I think we should stick to simple HTTP where each notif is POSTed, > > > > as in > > > your > > > > diagaram above. With HTTP pipelining you can do: > > > > > > > > ------> establish TCP > > > > ------> establish TLS > > > > ------> Send HTTPS POST message with YANG defined notification 1 > > > > ------> Send HTTPS POST message with YANG defined notification 2 > > > > <-----Send 204 (No Content) for 1 > > > > <-----Send 204 (No Content) for 2 > > > > > > > > ------> Send HTTPS POST message with YANG defined notification 3 > > > > <-----Send 204 (No Content) for 3 > > > > > > > > > > > > If the server wants to send multiple notifs at once, it can use > > > > "bundled- message". > > > > > > This seems a reasonable approach. > > > draft-ietf-netconf-notification-messages > > > has several advantages: > > > (1) can push multiple YANG notifications at once > > > (2) can include the subscription-id in notifications when subscribing > > > to a stream. (Right now including an explicit subscription-id is only > > > available when subscribing to a datastore.) > > > (3) includes methods to discover lost/dropped notifications > > > > > > Two things which would need to be worked: > > > (1) discovering receiver support for bundled notifications. (As some > > > form of understanding/verifying configured receiver support over HTTP > > > is already needed, this is a topic which perhaps can be merged into > > > that.) > > > > This can be configured or auto-detected. For auto-detection, perhaps we > > can use HTTP OPTIONS with the server returning a special body or header to > > indicate capabilities such as this one? > > The method previously proposed for HTTP configured subscriptions was an "OK" > to the POST of a <subscription-started>. The "OK" had to be received prior > to sending YANG notifications. If the authors want to build upon > this This is now a WG document, so it should be discussed in the WG. > , I > could see HTTP OPTIONS as a way to provide receiver capabilities. Or perhaps simply do a GET to the same URI as you POST to, and in return get a sx:structure with the capabilities of the server. > Some > discussion about what capabilities would be advertisable as options would be > worthwhile. Yes. > Also worth discussion would be any intersections with > NETCONF/RESTCONF capabilities discovery/exchange. Sure. But this is a new protocol, with a new (limited, hopefully) set of capabilities. /martin > > Eric > > > > (2) Completion of draft-ietf-netmod-yang-data-ext > > > > Yes! IMO it is ready for WGLC; I'll ping the chairs again. > > > > > > /martin > > > > > > > > > > > > Eric > > > > > > > /martin > > > > > > > > > > > > > > > > > > POST /some/path HTTP/1.1 > > > > > Host: my-receiver.my-domain.com <http://my-receiver.my- > > > > domain.com/> > > > > > Content-Type: application/yang-data+xml > > > > > > > > > > <notification > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > <eventTime>2019-03-22T12:35:00Z</eventTime> > > > > > <foo xmlns="https://example.com > > > > > <https://example.com/>/my-foobar-module"> > > > > > ... > > > > > </foo> > > > > > </notification> > > > > > > > > > > <notification > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > <eventTime>2019-03-22T12:35:00Z</eventTime> > > > > > <bar xmlns="https://example.com > > > > > <https://example.com/>/my-foobar-module"> > > > > > ... > > > > > </bar> > > > > > </notification> > > > > > > > > > > <notification > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > <eventTime>2019-03-22T12:35:00Z</eventTime> > > > > > <baz xmlns="https://example.com > > > > > <https://example.com/>/my-foobar-module"> > > > > > ... > > > > > </baz> > > > > > </notification> > > > > > > > > > > > > > > > With response: > > > > > > > > > > HTTP/1.1 204 No Content > > > > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > > > > Server: my-receiver.my-domain.com > > > > > <http://my-receiver.my-domain.com/> > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf
- [netconf] HTTPS notifications (draft-ietf-netconf… Balázs Lengyel
- Re: [netconf] HTTPS notifications (draft-ietf-net… Kent Watsen
- Re: [netconf] HTTPS notifications (draft-ietf-net… Martin Bjorklund
- Re: [netconf] HTTPS notifications (draft-ietf-net… Eric Voit (evoit)
- Re: [netconf] HTTPS notifications (draft-ietf-net… Martin Bjorklund
- Re: [netconf] HTTPS notifications (draft-ietf-net… Eric Voit (evoit)
- Re: [netconf] HTTPS notifications (draft-ietf-net… Martin Bjorklund
- Re: [netconf] HTTPS notifications (draft-ietf-net… Balázs Lengyel