Re: [netconf] time to meet today after 5pm

Kent Watsen <kent+ietf@watsen.net> Thu, 04 April 2019 17:05 UTC

Return-Path: <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@amazonses.watsen.net>
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 A3CB7120104; Thu, 4 Apr 2019 10:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 ArIxsRU6dvLn; Thu, 4 Apr 2019 10:05:15 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F96E120642; Thu, 4 Apr 2019 10:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554397503; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LyMnICVBrIBaE6hETiJBdMMUtfv2oxr7GRYsHdoDvOs=; b=TQLHmmuXd1/63lijmgmgH2ErAloRQ2aj6dk8l/FxHs8R3WmH4ZSA2qLdw1RB7lmI n01D81Of85MoleGF9B6w9gzLso+cuTgaSDpnq8r/7Kz/cB/5D/MPEzBdpIC3F0aQx3n iiKmwaeD4vXnFe5jYQkOrPhpG1uXQnwI44MvCqwo=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1714681-2C8F-47AC-B660-D84677E432D8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 4 Apr 2019 17:05:02 +0000
In-Reply-To: <CAOdDvNq4bLXtdDD7WdXbH-e14-i_yy50ADm59YtOKW5buaCjOg@mail.gmail.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, httpbis-chairs@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Patrick McManus <mcmanus@ducksong.com>
References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <CAOdDvNoDFoa30tJ8XDz482_38rw8+ajwW4+dSx7s_psoFY7ukQ@mail.gmail.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> <CAOdDvNq4bLXtdDD7WdXbH-e14-i_yy50ADm59YtOKW5buaCjOg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.04-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/2za5zx_gqHhrTlps10FdFhVCjGI>
Subject: Re: [netconf] time to meet today after 5pm
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: Thu, 04 Apr 2019 17:05:18 -0000


> I don't think this is correct.  In what way do you think RESTCONF
> tries to use HTTP as a stateful transport?
> 
> 
> below
>  
> 
> > >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <kent+ietf@watsen.net <mailto:kent%2Bietf@watsen.net>>
> 
> > >> Actually, "managing persistence" is exactly what we're trying to
> > >> achieve here.  Our show-stopping driving use-case regards RESTCONF
> > >> Call Home (RFC 8071) and, in particular, point "S7" on page 8 of that
> > >> document, without which a remote device may become a "brick" and
> > >> require a technician to perform on-site repair.
> 
> also, in an exchange that wasn't copied to the wg,:
> 
> > To give a concrete example, there may be a device, deployed behind a NAT, requiring a persistent management connection to its controller application.  Because the device is behind a NAT, it MUST initiate the connection (the controller cannot) and, thus the device MUST ensure aliveness of the connection to the controller (the controller *needs* the device-initiated connection to be up in order to send commands to the device).   In case the controller disappears, perhaps due to its data-center being hit by a meteor, the device must promptly detect to loss and initiate reconnection to another controller.


To be clear, RESTCONF is not trying to use HTTP as a stateful protocol, but it is ideal to try to keep RESTCONF Call Home connections up, as described above.   Per the "S7" reference, devices SHOULD use RFC 6520 (the TLS heartbeat extension).   This would keep the *stateful* transport (TLS) up but, unfortunately, OpenSSL doesn't want to implement it (worst, they just removed the DTLS code, https://github.com/openssl/openssl/issues/4856 <https://github.com/openssl/openssl/issues/4856>, despite Ben Kaduk and myself stating value).

The thinking behind this thread is that maybe some traffic could run on top of TLS (i.e., at the HTTP layer), to do the same and, if not, then maybe we could do it at the RESTCONF layer.  [FWIW, you might recall NETCONF/RESTCONF keepalives discusseded at the IETF 103 meeting.]

Patrick, if HTTP keepalive is not possible, then lets strike the "keepalive" parts from the ietf-http-client and ietf-http-server models, leaving it to implementations to lean more heavily on their TLS suppliers to implement RFC 6520, or fallback to unprotected TCP keepalives (which is what the BBF/Nokia said they would be doing for expediency).  Regarding the rest, let me clean the remaining bits (i.e., post a -01) and present them to you again then.

For everyone else, this email thread is from last week when Mahesh and I were trying to meet with the HTTPBIS chairs to discuss the http-client-server draft under adoption poll.  We wanted to proactively engage HTTPBIS rather than have any surprises, such as the exchange with TCPM.   Our hope is that we can come to an agreement, like the one struck with TCPM, whereby domain experts in each WG co-author a bare-minimum grouping that enables our 5-year chartered work effort to come to an end.  With regards to Last Call, we can do it joint Last Call, if desired.   For longterm maintenance of the YANG model, we're happy to turn it over to the domain-specific WG, though we don't have any need or expectation for an update, the bare-minimum is sufficient.

Kent // pick a hat