Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif)
Martin Bjorklund <mbj@tail-f.com> Tue, 24 September 2019 06:46 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 E755612010C for <netconf@ietfa.amsl.com>; Mon, 23 Sep 2019 23:46: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 NGQHrc-X7lmW for <netconf@ietfa.amsl.com>; Mon, 23 Sep 2019 23:46:25 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D335712001E for <netconf@ietf.org>; Mon, 23 Sep 2019 23:46:24 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id EED2F1AE018A; Tue, 24 Sep 2019 08:46:22 +0200 (CEST)
Date: Tue, 24 Sep 2019 08:45:58 +0200
Message-Id: <20190924.084558.420273240258823379.mbj@tail-f.com>
To: kent@watsen.net
Cc: balazs.lengyel=40ericsson.com@dmarc.ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com>
References: <VI1PR0701MB22862DB97D9F2389D859270FF0850@VI1PR0701MB2286.eurprd07.prod.outlook.com> <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.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/Tj5hb8gOoU61o04Z6fbFmfUIFSI>
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 06:46:27 -0000
Hi, Kent Watsen <kent@watsen.net> wrote: > > Hi Balazs, > > > > The draft should discuss how long the HTTPS connection is held open > > for the next notification. Or is it open/closed for each notification? > > Should it? Perhaps it should say "Implementations must determine how > long the HTTPS connection is held open for subsequent notifications, > or if it is open/closed for each notification." This is somewhat dependent on how notifs are streamed, see below. > > The draft should include a sequence diagram showing the message flow > > something like: > > Server Client > > <------- establish TCP > > <------- establish SSH (or TLS) > > <------- establish Netconf session > > <------- <edit-config> configure subscription over Netconf > > <-------- <close-session> > > <-------- tear down Netconf/SSH/TCP > > I don't think the draft needs to include this diagram, as it's > standard NETCONF. +1 > > Later > > > > ------> establish TCP > > ------> establish TLS > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send OK > > > > The last 2 or 4 steps repeat until the subscription is removed by > > another <edit-config> > > > Assuming the TLS session is help open, it might look like this? > > > ------> establish TCP > > ------> establish TLS > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send 204 (No Content) > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send 204 (No Content) > > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send 204 (No Content) > > > > 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". /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] 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