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

[Kent Watsen <[e-mail]>]

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