Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

tom petch <ietfc@btconnect.com> Fri, 15 November 2019 12:48 UTC

Return-Path: <ietfc@btconnect.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 CC40D120841 for <netconf@ietfa.amsl.com>; Fri, 15 Nov 2019 04:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 SnzhVNObrKHm for <netconf@ietfa.amsl.com>; Fri, 15 Nov 2019 04:48:14 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40119.outbound.protection.outlook.com [40.107.4.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C556120838 for <netconf@ietf.org>; Fri, 15 Nov 2019 04:48:13 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B/yUTf4zLTSr2SnUYcfXzz1S0EKmAgnFycaG5ItpBkZFAjGFtyJOndsVu+7xdotjVCc5QgTtzDKLvXlVTkKTV6gKw8aOuv49qNMqxAMsFsMDgtP7tyTBOKWe4OVMtEOBKifoyFGGh9M/1SLJIcevEHYh4/98ek1NboVMIaZwg9CRncBXHv5VdN3vt8Lolf04+PO1FX1DVL3yh3TOJ4FZM15G43O9mGdIbuZRAGNX6vtxAEPqYnDbsBKPM90UxH1rsze+tWda9GWKp15vIy8nSLhz6xm41l2N2jutCJyZyopa0Fwz7cc6cUqmzL9wh+Wkow5q4Q+l+dHuhp9pj4kqhw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Wc9E8JYICRZdk41a2RVNp6OThfTCIl4bn9NZOfE5VI=; b=ROJXeGJS83J+6xYWkFBQ/IRs4Ae6Y4zvq5GKYxRQYCso9rBVIvwOdfGvu9vimMMndBKDpHi+JyGS362Gd9B4+tCbhiGRFeB/tyrKE96rSR8mNs27gr5U5rXpvniEE6bsX1LmhGUD559nqXWC1ccyzd+nM2N/OgnN5d/s17Vq4B/1WgoZHDiz7dwYAuRP+rrlRzg1ovYqllnom2wiFUs6czbRpWo3tQEvmATJsDr/sHgzWAWSaNjURieuCbTgVP7rKkCjOdfu+4/nIHu5OwAn5KOSuYPVUFb36cvn/PBFjtT0yajeP3M6F53IwU3mx4smVvvCekqpIY3Gtvrhe+8xCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Wc9E8JYICRZdk41a2RVNp6OThfTCIl4bn9NZOfE5VI=; b=f8JpxoXJUwJ5bKSChf6ezZ0ycCsMc1vSK9yA97Ngb7N1qs9NF9aoCqEhFoj1YNGhonViGXLQc/dOM4hwodgOuK35aiBaQ3VuQHOdZRdQiUTZK0zaKTXhki4biwHNcGz+nyFB9Zf6Np3vKPDJlN7zwtE7XzxKkncMh4MHyqMx3tA=
Received: from DB7PR07MB5147.eurprd07.prod.outlook.com (20.178.42.32) by DB7PR07MB6091.eurprd07.prod.outlook.com (20.178.106.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.17; Fri, 15 Nov 2019 12:48:11 +0000
Received: from DB7PR07MB5147.eurprd07.prod.outlook.com ([fe80::e5bf:72e6:a66c:401a]) by DB7PR07MB5147.eurprd07.prod.outlook.com ([fe80::e5bf:72e6:a66c:401a%3]) with mapi id 15.20.2451.029; Fri, 15 Nov 2019 12:48:11 +0000
From: tom petch <ietfc@btconnect.com>
To: Kent Watsen <kent+ietf@watsen.net>, Martin Bjorklund <mbj@tail-f.com>
CC: "bill.wu@huawei.com" <bill.wu@huawei.com>, "rwilton@cisco.com" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04
Thread-Index: AQHVm7LwuMip8QrCR0uFvhT7rV9RMA==
Date: Fri, 15 Nov 2019 12:48:11 +0000
Message-ID: <02e801d59bb2$e43a2f00$4001a8c0@gateway.2wire.net>
References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0136.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::28) To DB7PR07MB5147.eurprd07.prod.outlook.com (2603:10a6:10:68::32)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.211.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 43d3f265-fa39-4a3a-4069-08d769ca129a
x-ms-traffictypediagnostic: DB7PR07MB6091:
x-microsoft-antispam-prvs: <DB7PR07MB609177242EA0232E7A83BE0DA0700@DB7PR07MB6091.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02229A4115
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(366004)(346002)(396003)(54094003)(13464003)(189003)(199004)(66946007)(62236002)(44716002)(229853002)(81686011)(81816011)(76176011)(66556008)(64756008)(66446008)(9686003)(6512007)(44736005)(6486002)(6436002)(25786009)(86362001)(478600001)(50226002)(7736002)(4720700003)(256004)(186003)(6116002)(2906002)(3846002)(14454004)(14444005)(476003)(446003)(99286004)(14496001)(486006)(71190400001)(81156014)(8936002)(52116002)(305945005)(81166006)(66066001)(71200400001)(110136005)(8676002)(54906003)(316002)(386003)(5660300002)(6246003)(102836004)(6506007)(4326008)(66476007)(26005)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB6091; H:DB7PR07MB5147.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: slL7qSpwAioZI/6ufnz+qRUaSq4YuhxlrM5wFfWZgXPOQeW+GolOCnFILaOl2uRwFWI0NV7g8hDzi7Wq4n969S2Bo+vqolBlel47k+9a+0DT/TF52uY4D94h3RWm+O+zCpnsxjEsFPQRpwQ9WnzH1hVUBjMx6AHfqPYIpBElTKSd6LAyVVsN1OPfMLjKsaXw3n7sQw3aPlQK16wyXMxDlvMVFH3HxlZT04BeFbdUybvggVOBRKH98+ZZRba6pM0vzvczCVVPeQLbnoHap50uiKW289WkxiAK4zs8Keg1V2qKOCJ50TOt8c1iuFtJV1VNpze29qbo8ECkRsD1pTJmZ5au/xWGL0JygEhSSlTjPoVVRG2vK+8OoG+KToFezXyNZdH74ujOMlot87Gccp+5gQ60C4xE8L0vrQj2rV04fBxJbcdS/w4SmUbukxmGWMjO
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <0EAC99015A3EB947A367D4ED5BF1584E@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43d3f265-fa39-4a3a-4069-08d769ca129a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2019 12:48:11.4002 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: o8JiViMvvucNmg+2ZRPye1YmwX9lpaK0RLiwJMtbo7izgMSnDhrGnTfEDrVTw8TX6aBzOG3i4f7q7a+BE6Xiew==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6091
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/hMOf937bD2kLzM42N0EAPLKzqmg>
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04
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: Fri, 15 Nov 2019 12:48:17 -0000

---- Original Message -----
From: "Kent Watsen" <kent+ietf@watsen.net>
To: "Martin Bjorklund" <mbj@tail-f.com>
Cc: <bill.wu@huawei.com>om>; <ietfc@btconnect.com>om>; <rwilton@cisco.com>om>;
<httpbis-chairs@ietf.org>rg>; <netconf@ietf.org>
Sent: Thursday, November 14, 2019 1:08 PM

Hi Martin,

> Personally I don't care; just pointing out a discussion that may be
> relevant.

Ack.  Let's focus on the module names, the draft name will fall out from
that discussion.

<tp>

Kent

I see this thread conflating names with names and names.

Module name I see as the most important; it is permanent, will be seen
by many people in many contexts and so must be an accurate reflection of
the contents.  If, during the development of the I-D, the contents
change, then change the name!  Yes, those with early implementations
will have to change but that is always the price of implementing an I-D

RFC Title also matters; it is permanent, widely seen in many contexts
and should tell people whether or not to go further, to read the
abstract.

But the name of the I-D is quite different.  It vanishes when the RFC
appears and ceases to be of any relevance but must change
from -<author>- to -ietf- when an I-D is adopted.  Otherwise it is just
a string, an identifier and subject to the requirements of an
identifier - like, stabillity.   So any other change than the one I just
mentioned I think a bad idea, which is what I said on OPSAWG; there the
title is good, no need to change, the I-D name is just an identifier,
leave it alone, do not try to give it semantic significance.

Tom Petch


> I think it is the name "ietf-http-server" that seems to indicate that
> this a module that can be used to configure any HTTP server.  (See
> below!)

It's more like a possible basis to configure any HTTP server, which to
me still seems like the right thing to do, until someone can provide a
concrete technical reason why it cannot be so.


> I wonder if the names should be "ietf-http-server-groupings" instead?

Hmmm, this is an interesting idea...

> (and same for tcp / ssh / tls, but not netconf / restconf).

I see why you might say this, but the netconf/restconf drafts also
define groupings, which are (IMO) more important than the containers,
which we added under questionable conditions (i.e., the "client"
containers make almost no sense, and the "server" containers have
limited use, especially without the ability to augment/refine things
when "implemented").

> We
> already have some "-types" modules.  Or even "ietf-http-server-types",
> if by "type" we mean "typedef and/or grouping".

...and identities and features (and maybe something else I'm not
thinking about just now).

> This could also be a way to make the name less problematic.  It makes
> it more obvious that these modules provide building blocks, rather
> than a complete solution.

I truly appreciate the intention behind this idea and love the idea of
sticking with an undiluted "http", but I question if putting "grouping"
into the module name is ideal, perhaps "base" or "basis" would be
better?   Even for the NC/RC modules, they are merely a base/basis for
higher-level business logic.  [note: I also thought about "params", but
the (IMO useless) containers in the NC/RC modules don't lend themselves
well to being called "params"]

To help visualize these options:

ietf-http-server-base
ietf-http-server-basis
ietf-http-server-params

ietf-restconf-server-base
ietf-restconf-server-basis
ietf-restconf-server-params

To be clear, I'm not yet agreeing to or promoting this approach yet,
though it seems promising.

Kent // contributor