Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft

Kent Watsen <kent+ietf@watsen.net> Tue, 26 March 2019 14:20 UTC

Return-Path: <01000169ba5f9050-5d5f75b7-3aef-4803-9d62-85b3c207c254-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 CB166120341 for <netconf@ietfa.amsl.com>; Tue, 26 Mar 2019 07:20:45 -0700 (PDT)
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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 aSCrJXLLd-fI for <netconf@ietfa.amsl.com>; Tue, 26 Mar 2019 07:20:43 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB6412030B for <netconf@ietf.org>; Tue, 26 Mar 2019 07:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553610019; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=mYW9fSCc80IegpY2U/hLWVDZOjm6TrTyA+Bs/7wIbfw=; b=YxqvyYDqBGIf5YLzMbrAP/gPi2kfXWhfLU47fi2O7dkiVQZ3IWKf1tMwv2Fvdm+1 gtoc/tj4piZSqZK4CBXOnqmdOpky6iAR3pO1v3WajumN7n9B24emcp4GpSMJUU4wxtj SE9YUQuHwCO8yZgSvWsEdps5o/6XnVN1MWrCS528=
Content-Type: multipart/alternative; boundary=Apple-Mail-F1121915-964E-40AA-951E-809E41640D7D
Mime-Version: 1.0 (1.0)
From: Kent Watsen <kent+ietf@watsen.net>
X-Mailer: iPad Mail (16D57)
In-Reply-To: <20190326115527.wssyesioa5oghy5t@anna.jacobs.jacobs-university.de>
Date: Tue, 26 Mar 2019 14:20:18 +0000
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
Content-Transfer-Encoding: 7bit
Message-ID: <01000169ba5f9050-5d5f75b7-3aef-4803-9d62-85b3c207c254-000000@email.amazonses.com>
References: <ED12BA39-09E6-4436-B759-625434D197D6@gmail.com> <20190326115527.wssyesioa5oghy5t@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-SES-Outgoing: 2019.03.26-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yg1UmyALcusZwR_Ka04YP6dUwco>
Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft
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: Tue, 26 Mar 2019 14:20:46 -0000

Hi Juergen,

> I am seeing several grouping definitions spread out over a growing set
> of documents but there is a lack of explanation how all this fits
> together. For example, why do we really need tcp-client-grouping and
> ip-params-grouping and keepalives-grouping? Same question for
> tcp-server-grouping and ip-params-grouping and keepalives-grouping.
> Perhaps they can be collapsed into just one?
> 
> A similar question could be asked for http-client-grouping and the
> helpers (?) http-client-identity-grouping and http-keepalives-grouping
> and the same for the server groupings. Is it really useful to define a
> grouping that only uses another grouping? It is also unclear to me
> what HTTP level keep alive messages are that a server sends to a
> client to check whether the client is still alive.

Agreed.  This was issue #6 on slide 16 here [1] as well on-list here [2].  The TL;DR; is that these breakout-groupings will be collapsed.

[1] https://datatracker.ietf.org/meeting/104/materials/slides-104-netconf-crypto-types-clientserver-suite-of-drafts-00.pdf
[2] https://mailarchive.ietf.org/arch/msg/netconf/4IqxP5kZAqQjP6BFmiHOTuPQJao


> Does it make sense to support a long list of client auth schemes or
> are we better supporting only basic ones and we add stuff later once
> we have experience with these models? HTTP servers usually have tons
> of other things you can configure that we do not cover and given the
> complexity we already have reached, perhaps it is fine to limit
> functionality in order to get something finished that can be used and
> then there is a time for a -bis to add what is missing.

This was issue #5 also on slide 16 [1] (link above).  

RFC 8040, Section 2.5 says “...one of the HTTP authentication schemes defined in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" (Section 5.1 in [RFC7235]) MUST be used.”  Following the pointer, that section says:

    The "Hypertext Transfer Protocol (HTTP) Authentication Scheme 
    Registry" defines the namespace for the authentication schemes in
    challenges and credentials. It has been created and is now maintained
    at  <http://www.iana.org/assignments/http-authschemes>.

Going to the IANA site, you’ll find the complete list of HTTP auth schemes listed in the ietf-http-client module.  I’m only explaining how the list came to be.    

From the presentation yesterday, you know that the configuration for some of these schemes is TBD.  I started filling them in, but I didn’t have the time to figure them out.  Yesterday’s presentation was really a call for help (please, co-authors are welcomed!).  Another way to resolve the issue is to do as you say, just support the most popular auth schemes, though 1) is that okay given RFC 8040 and 2) I don’t know which auth schemes are most popular.

I agree that we only want to do the bare minimum to have a viable release, but I’m of the opinion that, if you do something, do it right.  For HTTP, the only things I think we need to consider are: client auth, keepalives, and HTTP proxy.  I do not think we should attempt to cover any other parameters common with HHTP servers.  Note: this was issue #4 on slide 16 in [1] (link above)


> I support this work and the adoption of these drafts but we should set
> a clear target to get this work finished. I do very much appreciate
> Kent's continued work on this over the years in order to develop
> models for the relatively complex infrastructure needed to configure
> servers. But it may also be time to be pragmatic and to wrap this up,
> leaving things that can be added in later for future revisions and/or
> augmentations.

Absolutely, let’s get this done.  As mentioned in the meeting yesterday, we hope to get these to LC in a couple month’s time (though the TCPM issue just raised might cause delay).

Kent // contributor


> The original WG document, draft-ietf-netconf-server-model-00, was
> posted in May 2014.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf