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

Hi,
-----邮件原件-----
发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 tom petch
发送时间: 2019年11月12日 18:28
收件人: Rob Wilton (rwilton) <rwilton@cisco.com>; Kent Watsen <kent+ietf@watsen.net>; Martin Bjorklund <mbj@tail-f.com>
抄送: httpbis-chairs@ietf.org; netconf@ietf.org
主题: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

----- Original Message -----
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Sent: Monday, November 11, 2019 2:26 PM

Hi Kent,

I broadly agree with Martin here, in that I think that we want to get all of the "Client-Server" drafts finished.

Defining groupings in one place is probably beneficial and I as such as support the adoption of this draft, but not if it going to cause the other drafts that depend on these modules to end up being blocked for another 8 months, or a year.

<tp>
Well, my view of groupings and similar constructs in a variety of languages is that they are mostly harmful, making the code more complex and harder to understand, requiring a reader to keep having to branch off and look up something else somewhere else.

[Qin]: I prefer these grouping can be blended into client server series draft if we can not find other consumer for this draft besides ones in the OPS area.

They are beneficial only when they encompass a well-defined meaningful entity, object, idea, collection of data.  When the boundaries are ill-defined, I find them harmful.

What I see is the same 'n' lines of code, where 'n' is a small, even very small, integer, appearing in more than one place and then those 'n'
lines being taken out of context, given a wrapping, a name, a separate evolutionary path just to save <<n lines of code.  As I say, mostly harmful.

I do agree that any further delay in the base modules that depend on this module is to be avoided.

[Qin]:+1, my preference is to prioritize some of client server drafts and move forward, if further delay can not be resolved.

Tom Petch

Can we quickly find a name for these modules that is good enough for us, and would also be acceptable to the httpbis WG?

Perhaps "http-rest" instead of "http" or "restful"?

Thanks,
Rob

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 08 November 2019 01:45
To: Martin Bjorklund <mbj@tail-f.com>
Cc: httpbis-chairs@ietf.org; netconf@ietf.org
Subject: Re: [netconf] Adoption call for
draft-kwatsen-netconf-http-client-server-04

Hi Martin,

I think it is quite clear that the WG doesn't want more delays.

Is it?   I only know that Balazs K. wishes to have the first three
drafts (crypto-types, truststore, and keystore) completed soon.  The Nokia/BBF folks were interested in netconf-server, but forked long ago.
Otherwise, I'm unaware of anyone stating a preference.   For myself, I
only hope to achieve a good result.

So I think that either we simply don't add this grouping *at this point*, and define the necessary nodes in the higher-level modules, even though it is not perfect; or we define the "restful" module with these groupings, even though that is also perhaps not perfect.

ietf-restful-client and ietf-restful-server sound nice, but not so much in a stack:

    tcp-server-parameters : { ... },
    tls-server-parameters : { ... },
    restful-server-parameters : { .... },        <---- end-user says
"what's that?"
    restconf-server-parameters : { ... }

or (for https-notif)

    tcp-client-parameters : { ... },
    tls-client-parameters : { ... },
    restful-client-parameters : { .... }    <---- end-user says "what's
that?"

Actually, the above is purposely inaccurate.   If you recall, we
switched to having container-less groupings, thus the consuming module can name the container whatever it wants, so the net-net is no impact
other than changing the import and uses statements.   Though I still
don't know why we should do even this, given the lack of any response to my Oct 30th message.

Kent // contributor

------------------------------------------------------------------------
--------

> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf