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

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 21 Oct 2019 15:52:40 -0700

Hi WG,

The author has posted a -04 version of the draft, and believes that it ready for WG adoption.

This starts a 2 week poll ending on November 4, to decide whether this document should be made a WG document or not. Please reply to this email whether or not you support adoption of this draft by the WG. Indications that the draft has been read will be also be appreciated.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Oct 2019 10:34:51 +1100

Mahesh,

I've had a quick look at the draft, and I don't think it substantially addresses the feedback we gave earlier. It appears to create an arbitrary profile of HTTP and embodies several anti-patterns for its use.

As a result, I personally do not support the adoption of this draft.

Regards,

> On 22 Oct 2019, at 9:52 am, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi WG,
> 

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Oct 2019 00:07:13 +0000

As co-author, I support this adoption, especially given how it is a normative dependency for both:

    draft-ietf-netconf-restconf-client-server

and:

    draft-mahesh-netconf-https-notif

Kent

> On Oct 21, 2019, at 7:31 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi WG,
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Oct 2019 18:14:14 +0000

Hi Mark,

I just re-read all your (and Patrick's) messages from before and was unable to see anything actionable that wasn't addressed.  Can you please provide concrete examples for the concerns you have?

Since last time, there is now a second consumer of this draft: draft-ietf-netconf-https-notif.  Hopefully, now looking at both consumers (the other being draft-ietf-netconf-restconf-client-server) you will get a clearer picture of what is trying to be accomplished here.  

While not stated anywhere, the goal is somewhat restricted to support HTTP-based APIs (e.g., RESTful protocols) more so than webservers or browsers.  Maybe this is what you're perceiving as being "an arbitrary profile"?   FWIW, there are implementations (running code), which suggests the model here is close to what is needed for HTTP-based APIs.

This draft defines only YANG "grouping" statements.  Grouping statements don't define protocol-accessible nodes, just a potential for its nodes to exist.  The grouping statements MUST be "used" by another YANG module, which MAY augment/refine the grouping as needed.  The model is purposely incomplete for this reason.

As an example, assume a higher-level model wishes to define configuration for an HTTP client, but wishes to use some other (potentially proprietary) authentication scheme, not Basic.   To achieve this, the higher-level model could 1) "use" the `ietf-http-client` grouping,  2) NOT define the "basic-auth" feature (and hence Basic is not configurable), while 3) augmenting-in the data model for configuring the client-specific authentication scheme (enabling that authentication model to be configured).

Kent // contributor

> On Oct 21, 2019, at 7:34 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Mahesh,
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Oct 2019 09:32:00 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> Hi Mark,
> 
> I just re-read all your (and Patrick's) messages from before and was
> unable to see anything actionable that wasn't addressed.

I have searched the archives but couldn't find these messages.  Can
you send a link to them?  I would like to understand Mark's concerns.

/martin

> Can you
> please provide concrete examples for the concerns you have?
> 
> Since last time, there is now a second consumer of this draft:
> draft-ietf-netconf-https-notif.  Hopefully, now looking at both
> consumers (the other being draft-ietf-netconf-restconf-client-server)
> you will get a clearer picture of what is trying to be accomplished
> here.
> 
> While not stated anywhere, the goal is somewhat restricted to support
> HTTP-based APIs (e.g., RESTful protocols) more so than webservers or
> browsers.  Maybe this is what you're perceiving as being "an arbitrary
> profile"?  FWIW, there are implementations (running code), which
> suggests the model here is close to what is needed for HTTP-based
> APIs.
> 
> This draft defines only YANG "grouping" statements.  Grouping
> statements don't define protocol-accessible nodes, just a potential
> for its nodes to exist.  The grouping statements MUST be "used" by
> another YANG module, which MAY augment/refine the grouping as needed.
> The model is purposely incomplete for this reason.
> 
> As an example, assume a higher-level model wishes to define
> configuration for an HTTP client, but wishes to use some other
> (potentially proprietary) authentication scheme, not Basic.  To
> achieve this, the higher-level model could 1) "use" the
> `ietf-http-client` grouping, 2) NOT define the "basic-auth" feature
> (and hence Basic is not configurable), while 3) augmenting-in the data
> model for configuring the client-specific authentication scheme
> (enabling that authentication model to be configured).
> 
> Kent // contributor
> 
> 
> 
> > I've had a quick look at the draft, and I don't think it substantially
> > addresses the feedback we gave earlier. It appears to create an
> > arbitrary profile of HTTP and embodies several anti-patterns for its
> > use.
> > 
> >> This starts a 2 week poll ending on November 4, to decide whether this
> >> document should be made a WG document or not. Please reply to this
> >> email whether or not you support adoption of this draft by the
> >> WG. Indications that the draft has been read will be also be
> >> appreciated.
> >> 
> >> Thanks.
> >> 
> >> Mahesh Jethanandani
> >> [email-masked]
> >> 
> >> 
> >> 
> > 
> > --

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Oct 2019 18:57:17 +0000

Hi Martin,

> 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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 31 Oct 2019 13:51:09 -0700

I support the adoption of this draft.

> On Oct 21, 2019, at 3:52 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi WG,
> 

Mahesh Jethanandani (contributor hat on)
[email-masked]