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

Kent Watsen <> Thu, 14 November 2019 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 140A012086C; Thu, 14 Nov 2019 05:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BzIseajYEIDD; Thu, 14 Nov 2019 05:08:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E7F2120868; Thu, 14 Nov 2019 05:08:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1573736928; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=K9FXkeB+WAQu4Y2urZK8zdAi9Am4B6/LV7QDqfMpx0c=; b=Br46vlWVlploICgKgCsql+pn5Qdzxi3nKJvTIbw/x7+AZIO+sIu/6Xlj9M7lCb6x +ohaXjXSqSIrmju4W65pepxt8EXQ8VQnJkoUrbq7Du8+27IDuRBREht3jSqX3VfMpmg 1S6Xnv1sjwQncI2+RH+Aqsxm7NAiFOhY4HHCERAY=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_004D935A-E7E9-4540-9C3B-EF4E57123789"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 14 Nov 2019 13:08:48 +0000
In-Reply-To: <>
Cc:,,,, "" <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.14-
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 13:08:51 -0000

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.

> 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:



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

Kent // contributor