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

Qin Wu <> Wed, 13 November 2019 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FBAD120103; Tue, 12 Nov 2019 17:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3qH_hj916cy6; Tue, 12 Nov 2019 17:28:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD8191200F1; Tue, 12 Nov 2019 17:28:32 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 9186CF039DD4B346F1C4; Wed, 13 Nov 2019 01:28:29 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Nov 2019 01:28:28 +0000
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Wed, 13 Nov 2019 09:28:24 +0800
From: Qin Wu <>
To: tom petch <>, "Rob Wilton (rwilton)" <>, Kent Watsen <>, Martin Bjorklund <>
CC: "" <>, "" <>
Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04
Thread-Index: AdWZwaIxhgQXPPYEQrG4WcDrav91fA==
Date: Wed, 13 Nov 2019 01:28:23 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Wed, 13 Nov 2019 01:28:37 -0000

发件人: netconf [] 代表 tom petch
发送时间: 2019年11月12日 18:28
收件人: Rob Wilton (rwilton) <>; Kent Watsen <>; Martin Bjorklund <>
主题: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

----- Original Message -----
From: "Rob Wilton (rwilton)" <>
Sent: Monday, November 11, 2019 2:26 PM

Hi Kent,

I broadly agree with Martin here, in that I think that we want to get all of the "Client-Server" drafts finished.

Defining groupings in one place is probably beneficial and I as such as support the adoption of this draft, but not if it going to cause the other drafts that depend on these modules to end up being blocked for another 8 months, or a year.

Well, my view of groupings and similar constructs in a variety of languages is that they are mostly harmful, making the code more complex and harder to understand, requiring a reader to keep having to branch off and look up something else somewhere else.

[Qin]: I prefer these grouping can be blended into client server series draft if we can not find other consumer for this draft besides ones in the OPS area.

They are beneficial only when they encompass a well-defined meaningful entity, object, idea, collection of data.  When the boundaries are ill-defined, I find them harmful.

What I see is the same 'n' lines of code, where 'n' is a small, even very small, integer, appearing in more than one place and then those 'n'
lines being taken out of context, given a wrapping, a name, a separate evolutionary path just to save <<n lines of code.  As I say, mostly harmful.

I do agree that any further delay in the base modules that depend on this module is to be avoided.

[Qin]:+1, my preference is to prioritize some of client server drafts and move forward, if further delay can not be resolved.

Tom Petch

Can we quickly find a name for these modules that is good enough for us, and would also be acceptable to the httpbis WG?

Perhaps "http-rest" instead of "http" or "restful"?


From: netconf <> On Behalf Of Kent Watsen
Sent: 08 November 2019 01:45
To: Martin Bjorklund <>
Subject: Re: [netconf] Adoption call for

Hi Martin,

I think it is quite clear that the WG doesn't want more delays.

Is it?   I only know that Balazs K. wishes to have the first three
drafts (crypto-types, truststore, and keystore) completed soon.  The Nokia/BBF folks were interested in netconf-server, but forked long ago.
Otherwise, I'm unaware of anyone stating a preference.   For myself, I
only hope to achieve a good result.

So I think that either we simply don't add this grouping *at this point*, and define the necessary nodes in the higher-level modules, even though it is not perfect; or we define the "restful" module with these groupings, even though that is also perhaps not perfect.

ietf-restful-client and ietf-restful-server sound nice, but not so much in a stack:

    tcp-server-parameters : { ... },
    tls-server-parameters : { ... },
    restful-server-parameters : { .... },        <---- end-user says
"what's that?"
    restconf-server-parameters : { ... }

or (for https-notif)

    tcp-client-parameters : { ... },
    tls-client-parameters : { ... },
    restful-client-parameters : { .... }    <---- end-user says "what's

Actually, the above is purposely inaccurate.   If you recall, we
switched to having container-less groupings, thus the consuming module can name the container whatever it wants, so the net-net is no impact
other than changing the import and uses statements.   Though I still
don't know why we should do even this, given the lack of any response to my Oct 30th message.

Kent // contributor


> _______________________________________________
> netconf mailing list

netconf mailing list