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

[Kent Watsen <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf