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

Kent Watsen <kent+ietf@watsen.net> Wed, 30 October 2019 18:57 UTC

Return-Path: <0100016e1e077c63-b847f803-c3f5-40b0-9e4d-d495936773a3-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 44EB612011F for <netconf@ietfa.amsl.com>; Wed, 30 Oct 2019 11:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 jnTtlweCbbzK for <netconf@ietfa.amsl.com>; Wed, 30 Oct 2019 11:57:19 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E1F120115 for <netconf@ietf.org>; Wed, 30 Oct 2019 11:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572461837; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=f07D3WqmjEku4oqASTFmDQYyQC7T1mMRqdorNNNk4mE=; b=fGQi48oaokcff1qpJA/6iSCGz2hQjnES858NN615VzygZbu5pHcwsn16EOEkn0M4 4xUS5dfsxu7uobL/U18rWRTQLH5Ew8e+XNhKS3vyuqLDjYobuJ78VVD8OMT7wy3MNgF ArVcUbXT6sh2/ONZc75yolOYYNDjQtTPleFmQmGQ=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20191030.093200.966070125623058715.mbj@tail-f.com>
Date: Wed, 30 Oct 2019 18:57:17 +0000
Cc: Mark Nottingham <mnot@mnot.net>, "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: 7bit
Message-ID: <0100016e1e077c63-b847f803-c3f5-40b0-9e4d-d495936773a3-000000@email.amazonses.com>
References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <802B82C7-56D8-4341-9416-2C2CFFECAA3C@mnot.net> <0100016df4ad340a-3b990c99-95f8-40c3-9ff0-6f627826bd94-000000@email.amazonses.com> <20191030.093200.966070125623058715.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.10.30-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/oVv-g_uXV69TPFsialNyEeYmMtg>
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: Wed, 30 Oct 2019 18:57:21 -0000

Hi Martin,


> I have searched the archives but couldn't find these messages.  Can
> you send a link to them?  

The messages were on the 'netconf-chairs- list, which has no 
archive.  I could attach the thread here, but I feel that I 
shouldn't without securing all party's consent first.

FWIW, the exchange took place during IETF 104, as the NETCONF
chairs wanted to solicit HTTPBIS-chair input on the 
http-client-server draft, in the same way the NETCONF chairs
reached out to the TCPM chairs on the tcp-client-server draft.



> I would like to understand Mark's concerns.

I'll try to summarize what I see:

  - There was a lot of context-setting.  Actually, I'm unsure
    if the context was ever fully understood, especially with 
    regards to limited scope and how models (like those found
    in the restconf-client-server and https-notif draft's) 
    can extend it as needed.

  - There were issues with the 'keepalives' node, which was
    since removed (in -01).

  - It was mentioned that other industry efforts to abstract
    out underlying protocols have failed (e.g., Web Services,
    and more recently TAPS). Presumably because attributes
    of the underlying protocols are "leaky" and hence affect
    things running above them, and so cannot be abstracted
    out and replaced at will.  So far we don't have an
    example for where this might occur here.

  - There was a concern for the model defining a 'protocol-
    version' field in that, generally, clients and servers
    should dynamically negotiate the version used. This never
    made sense to me, exactly, as I know many http-servers
    enable configuring which HTTP versions it supports
    (usually used to trim-out support for legacy versions),
    and http-clients (e.g., `curl`) can be configured to use
    a specific HTTP protocol version, though the practical
    application of this beyond debugging eludes me.  That
    being the case, the likely resolution is to remove 
    "leaf protocol-version" from ietf-http-client.

  - There was a concern that HTTP carries a variety of schemes
    beyond http:// and https:// and that probably needs to be
    explored.  I don't understand this or even if support is
    needed in the base model.

  - There was a concern that the line this model is trying to
    draw between protocol layers isn't as clear as one might
    hope.  This comment seemed to revolve around how HTTP/2
    cares very much about the cipher suites that TLS uses and
    hence may want to use mechanisms like TLS exported
    authenticators to manage things like the H2 level
    origin mechanism.  Presumably, it's even crazier in HTTP/3.

  - With regards to not statically configuring authentication
    schemes because "they are negotiated at request time", I
    don't think either model is doing that.  Rather, the client
    model enables configuring a client to use a specific combo
    of auth-scheme + credentials.  Similarly, the server model
    enables configuring a server to authenticate clients using
    a client-database, which may be either local and external
    and it is only when 'local' that the 'basic-auth' scheme
    is considered.


Kent // pick a hat