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 (CEST)
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
> 
>