IETF Logo Mail Archive

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

Kent Watsen <kent+ietf@watsen.net> Thu, 14 November 2019 03:46 UTC

Return-Path: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-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 1A57E1200B1; Wed, 13 Nov 2019 19:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=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 0U-2-yKBgKxS; Wed, 13 Nov 2019 19:46:06 -0800 (PST)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC95E120048; Wed, 13 Nov 2019 19:46:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573703162; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=TZTU7vPYXYMA/VtFd5CpmvmX3K8c7SDyCXJb47psUtQ=; b=lnqRu20BkTuXUcXFtOcyU+vAKl0Xng+QCLAxvlZFiN3+XN3Nfk06OqF68wx9BZnX pzVjLrYskCidqFHiCZMPtUdWHB7f3JvGTvsCJ1UkbZVRO6BCSBizNPGOJkOrxpEHzaS ldxu54V2gsTBj03j2GaTvJY/Mqc6xL3UrtINszxg=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_371952EF-E87C-4A69-B753-73B32BF1194A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 14 Nov 2019 03:46:02 +0000
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA94180FF@dggeml511-mbx.china.huawei.com>
Cc: tom petch <ietfc@btconnect.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
To: Qin Wu <bill.wu@huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAA94180FF@dggeml511-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.14-54.240.8.64
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vQJ5TfYal_FdzvJkJrhUOdIueIY>
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: Thu, 14 Nov 2019 03:46:08 -0000

Folks,

It seems that the rough consensus is to rename the draft.   Being a WG document and me, a dutiful Editor, I'm happy to oblige.   Assuming adoption can proceed with this understanding, I'll make the change when submitting the -00.  As for the specific name, there is no great fallback, but perhaps s/http/web/ or s/http/rest/ (i.e., draft-ietf-netconf-web-client-server)?   We can decide in Singapore.

As the dissenter in the rough, let the record show that there is no concrete technical reason to rename anything, and efforts to get clarifications have be left unanswered.  If there are issues, renaming won't make them go away and, in any case, renaming to anything other than the name of the protocol layer is both unhelpful and confusing.  I hereby request that the shepherd writeup captures this sentiment as well.

Kent // contributor

v2.23.0 | Report a Bug | By Email