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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Tue, 09 April 2019 19:06 UTC

Return-Path: <eckelcu@cisco.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 CBE49120196; Tue, 9 Apr 2019 12:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Jx6JEjHN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EQuOjfHf
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 6V3NudJw66r6; Tue, 9 Apr 2019 12:06:49 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AAD120316; Tue, 9 Apr 2019 12:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20207; q=dns/txt; s=iport; t=1554836809; x=1556046409; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eFolRpL05dRL7j0GEox2HBVQF2kJHE0oRYLGqT5BGoI=; b=Jx6JEjHNPDA70uevcLT9HGOjWvW7svnQcs5AjRTZh+LDS307Jl68rDiD L0uCrVP4W9vqR4PE6NNTSjXoAOSXS84Px/YpRvV5zU0F8D0J8RbWsObpQ 7rwifiGDs1jhVsVgjwLX0eKt1FM4eaRpyyEVnxfxoDgsqaeE0EkVhhaGR c=;
IronPort-PHdr: =?us-ascii?q?9a23=3A68lyPRc61LnGf2r7xeibjdeXlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/Yic5EcBJSXdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAAAw7Kxc/5BdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBDi9QA2hUIAQLJ4QOg0cDjyiCV5JOhEqBLhS?= =?us-ascii?q?BEANUDgEBIwmDekYCF4VJIjYHDQEBAwEBCQECAQJtHAyFSgEBAQMBIx0BASk?= =?us-ascii?q?OAQQLAgEIEQMBAigDAgICMBQJCAIEAQ0FgyIBgRFMAw0IAQ6jOQKKFHGBL4J?= =?us-ascii?q?5AQEFgTEBg1QYggwDBYEwAYtGF4F/gREnH4JMPoJhAgKBLAESAQcCNg0JglQ?= =?us-ascii?q?xgiaLDoIIhC6HX4xmCQKIAoQeh2IaggaGFoxDi1OBGoNvgRmNWwIEAgQFAg4?= =?us-ascii?q?BAQWBVgEwZXFwFWUBgkGCCgwXg0yKU3KBKI0Ggj8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,330,1549929600"; d="scan'208,217";a="259332529"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2019 19:06:48 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x39J6maB029948 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2019 19:06:48 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 14:06:47 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 15:06:46 -0400
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 9 Apr 2019 15:06:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eFolRpL05dRL7j0GEox2HBVQF2kJHE0oRYLGqT5BGoI=; b=EQuOjfHf3dfINpgRU1jb+xLnBHPKoXtgHzfblGid66oLOvEWsVRNsu9GmiwAZhLRhZrufpTt1iqkXQGjNWHOLOHY4rgTfhmLhv/V5GD+XpCPu7/+fJRr+eYhRZSb/EdfRCxhf43CGUz9gFIR4Fo9FhLOFqFzl4dIrdDfv2mVKeQ=
Received: from MWHPR11MB0031.namprd11.prod.outlook.com (10.164.204.27) by MWHPR11MB1581.namprd11.prod.outlook.com (10.172.54.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Tue, 9 Apr 2019 19:06:44 +0000
Received: from MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b]) by MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b%6]) with mapi id 15.20.1771.016; Tue, 9 Apr 2019 19:06:44 +0000
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, Patrick McManus <mcmanus@ducksong.com>
CC: "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] time to meet today after 5pm
Thread-Index: AQHU6vCNgvMqKxW42UOukw8bvA9ZS6YsEPAAgAASFACAABgwAIAIHy0A
Date: Tue, 9 Apr 2019 19:06:43 +0000
Message-ID: <B21C3F25-221B-4EE3-A981-D4EE49864C06@cisco.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> <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com>
In-Reply-To: <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.1.190326
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eckelcu@cisco.com;
x-originating-ip: [2001:420:c0c0:1005::1d6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 18a07bd8-638a-4bce-3704-08d6bd1e81b8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR11MB1581;
x-ms-traffictypediagnostic: MWHPR11MB1581:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MWHPR11MB1581B1C66966AA9B344DFF86B22D0@MWHPR11MB1581.namprd11.prod.outlook.com>
x-forefront-prvs: 000227DA0C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(366004)(396003)(346002)(199004)(189003)(83716004)(6306002)(6116002)(54896002)(236005)(6512007)(4326008)(11346002)(6246003)(446003)(93886005)(71200400001)(106356001)(6436002)(256004)(105586002)(81166006)(14444005)(33656002)(58126008)(81156014)(82746002)(86362001)(54906003)(6486002)(229853002)(7736002)(606006)(8676002)(71190400001)(68736007)(36756003)(53936002)(8936002)(2616005)(478600001)(110136005)(46003)(316002)(476003)(966005)(5660300002)(97736004)(186003)(14454004)(25786009)(99286004)(486006)(76176011)(2906002)(6506007)(53546011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1581; H:MWHPR11MB0031.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cFZyNFPgpIGjoNbmXG4Z/DxfMiPDZD2WMPlU2wJO/ggGgFvnHLyMkEgqM6b469WcGve16HW7p3GNPC0DSeJV2AuY3Cgm75J/o15CqsCoZVUcOhzUFkKzNnhHIu42CIBQdduQ58Y7bDcFtPrKmC5+WxgxHtScZxtImcNM/egu8U+wqMfHUsvP/kpzvDA4dvQJpPC/dTy01ces91FstohZHtwMHbnVAUyWIVGedrvt65bnV8rR1pU7t7XOkwFDRMr7bxV1N5S2LixlD4ijSN0wria3wgoBOWlnAX+IR31iW9zTZPwpuwnE5Bz0GjZrRDmgxp0MQim3gDbDzLSyoxu3bMNuu7jFhEkU5dE+EwjNkptDxiTzEU0PFsmh4KmGwU5pCiG0JhGCra4giI6WYRUFk53d+AVN0Bxn0MKKZ1HuPQQ=
Content-Type: multipart/alternative; boundary="_000_B21C3F25221B4EE3A981D4EE49864C06ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 18a07bd8-638a-4bce-3704-08d6bd1e81b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 19:06:44.0894 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1581
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/aQcp7a_wivoIyU6Vl4v-rWP8kDI>
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: Tue, 09 Apr 2019 19:06:53 -0000

Please see inline.

From: netconf <netconf-bounces@ietf.org> on behalf of Kent Watsen <kent+ietf@watsen.net>
Date: Thursday, April 4, 2019 at 7:06 PM
To: Patrick McManus <mcmanus@ducksong.com>
Cc: "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>rg>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>rg>, "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [netconf] time to meet today after 5pm



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, 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.

I would recommend against adding any keepalive mechanism to RESTCONF. Strongly recommending the use of HTTPS when using RESTCONF is fine, but keep in mind that RESTCONF was created, and is viewed in the industry, as a “REST-like” alternative to NETCONF. The tradeoff is functionality built into the protocol vs. complexity of writing an application that uses the protocol. It is trivial to make individual RESTCONF requests but more difficult for an application to implement network transactions using RESTCONF than if using NETCONF. An application developer is free to choose the right protocol for the job. Adding complexity to RESTCONF that make it less REST-like would be a mistake, in my opinion.

Cheers,
Charles

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