Re: I-D for a YANG data model to configure HTTP clients and servers

Mark Nottingham <mnot@mnot.net> Sun, 10 May 2020 01:50 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E413A0764 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 9 May 2020 18:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nV33Pj/C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uFaBmNy4
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 gwYx5NOGZMGy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 9 May 2020 18:50:16 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE053A0755 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 9 May 2020 18:50:15 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jXb3s-0006ph-Hg for ietf-http-wg-dist@listhub.w3.org; Sun, 10 May 2020 01:47:24 +0000
Resent-Date: Sun, 10 May 2020 01:47:24 +0000
Resent-Message-Id: <E1jXb3s-0006ph-Hg@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jXb3r-0006ov-HE for ietf-http-wg@listhub.w3.org; Sun, 10 May 2020 01:47:23 +0000
Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jXb3l-0001qs-DT for ietf-http-wg@w3.org; Sun, 10 May 2020 01:47:23 +0000
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A43465C00CE; Sat, 9 May 2020 21:47:00 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 09 May 2020 21:47:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Q 16/tIS7hV27zbNde4bBds5kAK1TP+TSnhAd3Uzn3ks=; b=nV33Pj/CfmIDCF3SB tmxdefpy9Im2XsdNtcz7VILBSxQ5/YwwwSuR9DbCHHAHIhhF4m/NL+DonfE0O6zT Z3WOJjcJrRJtctHUldvENzyHQlczME+5rJeagt/huTnSjLk4TlU6sKHUjkOj8KbY NtVArg9TeMeVjQf1CGWZXMxXmUIhgdSVRXSpp1PXNHI4iAzLR+1K+o+N1dmlirhR ysi986CUbCoKg2gnoInk8pfm47nmFnM5AkrGJfSozVU/7aWBUD9XYnvz1M/KO3hU u9Pe8Fz/UPRWTeJ9jEjGVtfPFv4qOm/s9LxHvv6uYUMACiKdd2AQzL6jS/inKqDh tLwPA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Q16/tIS7hV27zbNde4bBds5kAK1TP+TSnhAd3Uzn3 ks=; b=uFaBmNy4hZLIw207o4qnwqQc0bvBMZ4k6wLwWJzcLe9eSZ7dPD6cBub6Z dE85QqiuJxZ/Y/XS5E/2fvi2bTGe8ruNM3ZmyMDEyrIS6Jvi5DpOkJ15bSZvDqWQ 2x+SkeVqQOWEAvTqX/FJCJr8pZqtJTKs7S+jvsDsJXgSYvP76abp9dd66dJJ/jiY Eab/xtJlJDAY+ldoeuoZhLcBybA9eELejie4Ydpro5jTYF9REIXhpOpzBIXloMXJ HZ69oxSOP3ZXjoW+Qj47o8dRdSTd1oLpnweFGqVGzJg/5uwR78mxBO036seTvciu MYoUCnP7/boqJ3UmfVwYSJAPDd9Fw==
X-ME-Sender: <xms:E123XhyQCYI6InNykXwUIp7Gzd0tpfqrB8Y5MkWVgkLOOuavdSFZrg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeeigdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeefvefgleetudeufffgkeffvdejvdevve duieelhfejkeefleduueeviedvvddthfenucffohhmrghinhepihgrnhgrrdhorhhgpdhi vghtfhdrohhrghdphhhtthhpqdgtlhhivghnthdqghhrohhuphhinhhgrdhpshdpvgigrg hmphhlvgdrtghomhdphhhtthhpqdhsvghrvhgvrhdqghhrohhuphhinhhgrdhpshdpmhhn ohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:E123XvIg6lUNwVf0Bw_V9Wi0NmKpgxgR7ZEE1knylEuXF5hfGO-0sA> <xmx:E123XrBGNbGK3XeWvQcuBlVhVkNgvjQzIjLYGI2-Xd2Q-9wQAXCDAA> <xmx:E123Xhg1ZJe636onbk1MY3RbV7LAhVprdCjCqfiEjFno4mAc_g_btA> <xmx:FF23XiJSsAiuGNut8dpCeSHBwWXsSSWbrbOHbBz_bMsJI9hWOySADw>
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 546953280059; Sat, 9 May 2020 21:46:57 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <01000171eaff2503-d978e760-f03b-416b-9208-f9a95d1ecadb-000000@email.amazonses.com>
Date: Sun, 10 May 2020 11:46:54 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <41183D9D-6287-416D-B160-F67E0B40916C@mnot.net>
References: <01000171e5dd76ed-e0bb6d02-faa5-4672-93ab-74bc96ae9775-000000@email.amazonses.com> <CC4173EC-67BB-4652-885E-4C50564CB05A@mnot.net> <01000171eaff2503-d978e760-f03b-416b-9208-f9a95d1ecadb-000000@email.amazonses.com>
To: Kent Watsen <kent+ietf@watsen.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Received-SPF: pass client-ip=66.111.4.28; envelope-from=mnot@mnot.net; helo=out4-smtp.messagingengine.com
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jXb3l-0001qs-DT b7b325476aa4c21c85b9ad61a1ec7e5e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <https://www.w3.org/mid/41183D9D-6287-416D-B160-F67E0B40916C@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37589
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Kent,

Thanks, that's extremely helpful.

Just to be clear, these artefacts are only for configuring their respective components (e.g., http-server-grouping is for interacting with the server to configure it, not for consumption by clients), correct?

Regarding the http-server-grouping - I'm not sure I understand why it's important to configure the version that the server supports. Wouldn't a server just support all of the versions it implements?

Also, what are you using for the values of <protocol-version/>? "HTTP/2.0" is a valid version, but the specification that you're probably referring to is "http/2".

These days, people tend to use ALPN protocol identifiers (which isn't without problem, but it is populated and widely understood): 
  https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Cheers,


> On 7 May 2020, at 3:18 am, Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> Hi Mark.
> 
>> To help people understand what they're looking at, do you have any pointers to documents explaining what RESTCONF is, at a high level? Also, some context on what the model is intended to be used for would be really helpful.
> 
> Yes, of course, silly me!  ;)
> 
> RESTCONF (RFC 8040) is an HTTP-variant of NETCONF (RFC 6241, RFC 4741), which is the network management protocol IETF defined roughly 15 years ago to replace SNMP.   Whereas SNMP uses MIBs to define message structures, RESTCONF and NETCONF use YANG (RFC 7950, RFC 6020).   NETCONF is purely an XML-based protocol, whereas RESTCONF uses media-types to define encodings, with current media-types including both JSON and XML.
> 
> For years now the IETF has been defining YANG “modules” to describe how to configure and monitor various aspects of a system, with primary emphasis on networking/routing protocols, firewall/ACLs, and the like.  More recently there has been interest in also defining standard modules for system-level management (i.e., how to configure users, access control, Syslog, etc.).  
> 
> Thus the desire to define YANG modules for configuring the RESTCONF/NETCONF servers (and clients) running on said networking gear was born.  This is a problem that the NETCONF WG has been working on for nearly 5 years now and, thankfully, it seems that we’re now close to the end of that effort, with the suite of documents nearing a WG last call.
> 
> My previous message mentioned how there is a suite of drafts that define “groupings”, snippets of configuration that can be mixed-in to define all the configuration for a protocol stack.  The below diagram depicts the relationship for all 9 IETF drafts in the suite of drafts (simply prefix “draft-ietf-netconf-“ to the name below to get the full draft name).  Notice that the “restconf-client-server” draft depends on the “http-client-server” draft (what this email to the HTTP WG is about).
> 
> 
>                                         crypto-types
>                                           ^      ^
>                                          /        \
>                                         /          \
>                               trust-anchors       keystore
>                                  ^      ^------+    ^
>                                  |              \   |
>                                  |      +-----------+
>                                  |     /          \
>  tcp-client-server     ssh-client-server      tls-client-server     http-client-server
>        ^      ^              ^                  ^           ^               ^
>        |      |              |                  |           |               |
>        |      |              |       +----------+           |               |
>        |      |              |       |                      |               |
>        |      |              |       |                      |               |
>        |      +--------------|-------|------------+         |               |
>        |                     |       |            |         |               |
>        |                     |       |            |         |               |
>        +--------------+      |       |            |         |      +--------+
>                       |      |       |            |         |      |
>                       |      |       |            |         |      |
>                    netconf-client-server        restconf-client-server
> 
> 
> That’s likely enough context setting.  Of course, please ask questions if there is a desire to know more at this level.   What I think would be more interesting to you all is to see some examples, i.e., where the rubber hits the road…. ;)
> 
> Snippet from https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-3.2 (please visit to see full example):
> 
>    <http-client>
>      <client-identity>
>        <basic>
>          <user-id>bob</user-id>
>          <password>secret</password>
>        </basic>
>      </client-identity>
>    </http-client>
> 
> This example illustrates how the “http-client-grouping” enables the client’s identity to be configured.  Please recall from my previous message that “basic” is the *only* HTTP authentication scheme supported by the YANG module.  If folks want to use others, whether standards-based or proprietary, they can be “augmented” (a YANG term) as needed. 
> 
> Not depicted by this example, is that the “http-client-grouping” also supports the optional configuration of HTTP proxy server settings, in case it is necessary for the HTTP-client to egress thru a proxy server.
> 
> And that’s it!  Just the "client-identity" and a "proxy-server” values can be configured in the “http-client-grouping".
> 
> PS: in case you’re wondering how the client knows what server to connect to, please note that the remote address/port (which can be a hostname) is configured in the “tcp-client-grouping” mix-in grouping and, likewise, an TLS-level client certificate would be configured in the “tls-client-grouping” mix-in grouping.
> 
> 
> Snippet from https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-4.2 (please visit to see full example):
> 
>    <http-server>
>      <server-name>foo.example.com</server-name>
>      <protocol-versions>
>        <protocol-version>HTTP/1.1</protocol-version>
>        <protocol-version>HTTP/2.0</protocol-version>
>      </protocol-versions>
>    </http-server>
> 
> This example illustrates how the “http-server-grouping” enables the HTTP server’s name and supported protocol  versions to be configured.
> 
> Not depicted by this example, is that the “http-client-grouping” also supports the optional configuration of HTTP client accounts in order to authenticate incoming HTTP clients against.  Consistent with what was mentioned before, only the “Basic” scheme is supported, while others can be augmented in if needed.
> 
> And that’s it!  Just the “server-name”, “protocol-version”, and "client-authentication” values can be configured in the “http-server-grouping".
> 
> PS: in case you’re wondering how the server knows what address/port to listen on, please note that the local address/port is configured in the “tcp-server-grouping” mix-in grouping and, likewise, an TLS-level server certificate would be configured in the “tls-server-grouping” mix-in grouping.
> 
> Hope that helps!
> 
> Kent
> 
> 
> 
>> On May 6, 2020, at 1:07 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> Hi Kent,
>> 
>> Thanks for that. 
>> 
>> To help people understand what they're looking at, do you have any pointers to documents explaining what RESTCONF is, at a high level? Also, some context on what the model is intended to be used for would be really helpful.
>> 
>> Cheers,
>> 
>> 
>>> On 6 May 2020, at 3:23 am, Kent Watsen <kent+ietf@watsen.net> wrote:
>>> 
>>> Hi Folks,
>>> 
>>> This I-D should be of interest to you: draft-ietf-netconf-http-client-server.   It would be great to get some feedback from the HTTP group!
>>> 
>>> Mark had asked me to present this work to the HTTP WG @ IETF 107, but I never saw a call for presentations for that meeting.  Upon seeing the recent HTTP virtual interim announcement, I again reached out to Mark, but noting that the VI agenda is packed, he asked me to send an email to the list, which is what this message is about.
>>> 
>>> Please note that the I-D is being run out the NETCONF WG because it is part of a suite of drafts that have been in progress to configure NETCONF and RESTCONF clients and servers…and HTTP is a base protocol for RESTCONF.  
>>> 
>>> The NETCONF WG’s goal is for this I-D to be minimally viable.  A previous version had more things in it (e.g., all HTTP authentication schemes), but has since been stripped down to the core.  Its current scope is minimally sufficient for the NETCONF WG's goal…there is no desire to increase its scope on our side.
>>> 
>>> To get a feel for how the configuration model defined in this draft ties in with the suite of a drafts mentioned above, please see the simplified YANG tree diagrams (RFC 8340) below, pulled from the draft-ietf-netconf-restconf-client-server draft.   [Pro tip: the ‘u’ in the diagram stands for “uses”, i.e., where a YANG model pulls in a definition from a grouping.]
>>> 
>>> FWIW, RESTCONF MUST be layered on top of TLS, as depicted in the “restconf-client” model below but, as a RESTCONF server MAY be fronted by a TLS-terminator (i.e., a load balancer), the “restconf-server” model supports both cases with and 
>>> without the "tls-server-grouping” grouping mixed in.  Important: the ability to mix-in protocol layers as needed is a key aspect of the general approach taken by the NETCONF WG.
>>> 
>>> 
>>>   grouping restconf-client
>>>     +-- (transport)
>>>        +--:(https)
>>>           +-- https
>>>              +-- tcp-client-parameters
>>>              |  +---u tcpc:tcp-client-grouping
>>>              +-- tls-client-parameters
>>>              |  +---u tlsc:tls-client-grouping
>>>              +-- http-client-parameters
>>>              |  +---u httpc:http-client-grouping   <-- defined by this I-D
>>>              +-- restconf-client-parameters
>>>                 +---u rcs:restconf-client-grouping
>>> 
>>> 
>>>   grouping restconf-server
>>>     +-- (transport)
>>>        +--:(http)
>>>        |  +-- http
>>>        |     +-- external-endpoint!
>>>        |     |  +-- address    inet:ip-address
>>>        |     |  +-- port?      inet:port-number
>>>        |     +-- tcp-server-parameters
>>>        |     |  +---u tcps:tcp-server-grouping
>>>        |     +-- http-server-parameters
>>>        |     |  +---u https:http-server-grouping   <-- defined by this I-D
>>>        |     +-- restconf-server-parameters
>>>        |        +---u rcs:restconf-server-grouping
>>>        +--:(https)
>>>           +-- https
>>>              +-- tcp-server-parameters
>>>              |  +---u tcps:tcp-server-grouping
>>>              +-- tls-server-parameters
>>>              |  +---u tlss:tls-server-grouping
>>>              +-- http-server-parameters
>>>              |  +---u https:http-server-grouping   <-- defined by this I-D
>>>              +-- restconf-server-parameters
>>>                 +---u rcs:restconf-server-grouping
>>> 
>>> 
>>> PS:  I’ve CC-ed the NETCONF chairs for visibility, rather than CC the NETCONF list.  If needed, I’ll be the liaison between the two WGs if needed, or we can cross-post if that is deemed better...
>>> 
>>> Kent (the author of the I-D)
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
> 

--
Mark Nottingham   https://www.mnot.net/