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

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

Return-Path: <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-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 C42FB120047; Thu, 14 Nov 2019 03:35:03 -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 iFGDEHZZkt9o; Thu, 14 Nov 2019 03:35:02 -0800 (PST)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9836120046; Thu, 14 Nov 2019 03:35:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573731300; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=em1oVJt//TEI3GtDpB9beL4Yln29lFuM08QVPHFcMMw=; b=VWbBjnahBrz6ywDII8rq3VvFTd0iLnhrgPOOIGL+hNUL6L1UyenlpcCdv1FGrfue YndaxNfL9wzzfrSpZogPtIOIt0m5Rn7VPLIWUFivnKHJr2VBflCMm/cMbbhy9MxY1W+ NwilbeIRQ5O/LjHCUBAkrDae3ZI7VHXNiK989YdY=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_01CB5C8E-42CB-4F1B-AB86-853824E0D318"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 14 Nov 2019 11:35:00 +0000
In-Reply-To: <20191114.101406.2087098792700938588.mbj@tail-f.com>
Cc: bill.wu@huawei.com, ietfc@btconnect.com, rwilton@cisco.com, httpbis-chairs@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <B8F9A780D330094D99AF023C5877DABAA94180FF@dggeml511-mbx.china.huawei.com> <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.14-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3aMxWmGa-rv_g0pyCqwSgIQPswc>
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 11:35:04 -0000

> There's a thread in opsawg about renaming drafts...  Conclusion (I
> think): keep the name of the draft, but change the title and name of
> the module.

I saw but didn't read the thread.  Did it cover crossing from an individual draft to a WG draft (i.e., kwatsen-05 --> ietf-00)?   The draft name must change, right?  If this is a Datatracker history issue, is it understood that the replace-by behavior enables diffs to cross the individual to WG draft boundary, and it really doesn't matter what names are used?


> If the name is too generic, and the issue is that the content is more
> specific than the name suggests, then renaming can help resolving the
> issue.

In principle, yes, but for this case, how is the "http" name too generic?  Do we have a single concrete reason that has been vetted?  How can the draft explain to readers why the most obvious name wasn't used?   What is the distinguishing characteristic that potential consumers should use to ascertain if the modules are [in]appropriate for them?

As for the title and module name, it seems the simplest thing is:

	OLD:
		title: 	Groupings for HTTP Clients and Servers
		module: 	ietf-http-client
		module: 	ietf-http-server

	NEW:
		title: 	Groupings for RESTful HTTP Clients and Servers
		module: 	ietf-restful-http-client
		module: 	ietf-restful-http-server

But isn't there also an issue of names being overly specific?  Some may ask why the draft is limited to RESTful HTTP, being that it only configures endpoints and has nothing to do with if the application is RESTful or not.



Kent // contributor