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

Martin Bjorklund <> Thu, 14 November 2019 09:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44333120232; Thu, 14 Nov 2019 01:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yYu3HKe9oRnK; Thu, 14 Nov 2019 01:14:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 36FE01200E5; Thu, 14 Nov 2019 01:14:38 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id BCE681AE0312; Thu, 14 Nov 2019 10:14:36 +0100 (CET)
Date: Thu, 14 Nov 2019 10:14:06 +0100
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <> <>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2019 09:14:39 -0000


Kent Watsen <> wrote:
> 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.

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.

> 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

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

> 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