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

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/

Received on Wednesday, 6 May 2020 05:07:33 UTC