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

Kent Watsen <kent+ietf@watsen.net> Fri, 08 November 2019 01:44 UTC

Return-Path: <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-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 45E781200CC; Thu, 7 Nov 2019 17:44:43 -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 C7pmSiqsE_qi; Thu, 7 Nov 2019 17:44:41 -0800 (PST)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB6B12004A; Thu, 7 Nov 2019 17:44:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573177479; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=WEYc926jcrQcUMag5iG5Zyr4hIitlpdSaGjdCMaJ9mk=; b=cI5RkN/cRPoUEusT1API1PM+0DocuiNpSNpZlLeXy6C7N5SWCafs0z8oPozmkQCc 4dGm2giwlS/RTuP5TyYpF6sWyRZO1D4PX1KFTvfu1o97MhFrCw28wVQkYfHo04ks9qH FL/oJMmjEEgbwVOTNUhODLMoKncrQKxToAR11I5s=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_92294D73-B8D3-449F-9F03-6A1D9F87DBF3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 8 Nov 2019 01:44:39 +0000
In-Reply-To: <20191107.205057.1889050828820990344.mbj@tail-f.com>
Cc: Juergen Schoenwaelder <J.Schoenwaelder@jacobs-university.de>, httpbis-chairs@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> <20191107.205057.1889050828820990344.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.08-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/HM2PurMssREN5-rpqblFLUKisUE>
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: Fri, 08 Nov 2019 01:44:43 -0000

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 that?"


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