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

Kent Watsen <kent@watsen.net> Thu, 07 November 2019 00:04 UTC

Return-Path: <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-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 2907C1200CC; Wed, 6 Nov 2019 16:04:16 -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 ruzEMpshpT_Z; Wed, 6 Nov 2019 16:04:14 -0800 (PST)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4CC120169; Wed, 6 Nov 2019 16:04:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573085053; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=zRVeprWI7wdNZZThSoObf5qiTa87Tcq+6la5CsLOFVk=; b=OC4vNq9qYLg4riinEP2CIGwZaHwZDHBkfUgsaRmMy30bel5i48UN9EoECzFrr9kb dVQO8v2Z+hzkqu9X1Z66pWUnXQ/cORCj26fE8d0/YYMRo6xtx6aa8YC6dPihM7OqC5e mY2c0mgm2qPJ/+05w3Dz93TdZgsBd6aRtUSnGH7s=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_28247C3C-B748-4374-BC1D-DC8B54B5ED39"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 7 Nov 2019 00:04:13 +0000
In-Reply-To: <20191104.093427.842126049822749848.mbj@tail-f.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, httpbis-chairs@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.07-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Mbrct43FD4ojKjalv7UPopgm7pc>
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, 07 Nov 2019 00:04:16 -0000

Hi Martin,

> In principle I wouldn't mind a document like this.  But if the HTTP
> experts have concerns, and based on the contents of the model (*)
> perhaps it is better to add the necessary nodes directly to the
> higher-level modules (e.g, ietf-restconf-server for the server nodes).

Adding the nodes into the higher-level modules seems incorrect, as it would effectively cause the same content to be replicated into a multiplicity of higher-level modules leading to user-confusion and maintenance-complexity.

It seems more appropriate to understand what the concerns are and try to address them.   

Noteworthily, the HTTP experts additionally said that they would have no issue if the module were called something else (ietf-restful-http-client/server?) as then it wouldn't appear to intending to be an all-encompassing HTTP definition and it would no longer require involvement of the HTTP experts to ensure correctness.


> (*) The grouping for the server doesn't really add much, imo.
> Basically it has a seemingly arbitrary selection of headers to control
> (in fact just 'Server'), which protocol version to support, and a
> per-server list of "basic" username/passwords (which is probably not
> a common way to configure authentication).

True, but it is still meaningful, even if only for the protocol version, and providing a target for higher-level modules to augment into.


> The client grouping also doens't add much, with the possible exception
> of the proxy settings; perhaps these nodes could be specified in a
> generic grouping.

The "client-identity" container is important.  Note that "basic-auth" is under an "if-feature" statement in anticipation that higher-level models will want to augment into the "auth-type" choice statement other (potentially proprietary) auth schemes.


Kent // contributor