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

From: Qin Wu <[email-masked]>
Date: Wed, 13 Nov 2019 01:28:23 +0000

Hi,
-----邮件原件-----
发件人: netconf [mailto:[email-masked]] 代表 tom petch
发送时间: 2019年11月12日 18:28
收件人: Rob Wilton (rwilton) <[email-masked]>; Kent Watsen <[email-masked]>; Martin Bjorklund <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

----- Original Message -----
From: "Rob Wilton (rwilton)" <[email-masked]>
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 <[email-masked]> On Behalf Of Kent Watsen
Sent: 08 November 2019 01:45
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]; [email-masked]
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

_______________________________________________
netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 03:46:02 +0000

Folks,

It seems that the rough consensus is to rename the draft.   Being a WG document and me, a dutiful Editor, I'm happy to oblige.   Assuming adoption can proceed with this understanding, I'll make the change when submitting the -00.  As for the specific name, there is no great fallback, but perhaps s/http/web/ or s/http/rest/ (i.e., draft-ietf-netconf-web-client-server)?   We can decide in Singapore.

As the dissenter in the rough, let the record show that there is no concrete technical reason to rename anything, and efforts to get clarifications have be left unanswered.  If there are issues, renaming won't make them go away and, in any case, renaming to anything other than the name of the protocol layer is both unhelpful and confusing.  I hereby request that the shepherd writeup captures this sentiment as well.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 10:14:06 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> 
> Folks,
> 
> It seems that the rough consensus is to rename the draft.  Being a WG
> document and me, a dutiful Editor, I'm happy to oblige.  Assuming
> adoption can proceed with this understanding, I'll make the change
> when submitting the -00.  As for the specific name, there is no great
> fallback, but perhaps s/http/web/ or s/http/rest/ (i.e.,
> draft-ietf-netconf-web-client-server)?  We can decide in Singapore.

There's a thread in opsawg about renaming drafts...  Conclusion (I
think): keep the name of the draft, but change the title and name of
the module.

> As the dissenter in the rough, let the record show that there is no
> concrete technical reason to rename anything, and efforts to get
> clarifications have be left unanswered.  If there are issues, renaming
> won't make them go away

If the name is too generic, and the issue is that the content is more
specific than the name suggests, then renaming can help resolving the
issue.

> and, in any case, renaming to anything other
> than the name of the protocol layer is both unhelpful and confusing.
> I hereby request that the shepherd writeup captures this sentiment as
> well.
> 
> Kent // contributor

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 11:35:00 +0000

> think): keep the name of the draft, but change the title and name of

I saw but didn't read the thread.  Did it cover crossing from an individual draft to a WG draft (i.e., kwatsen-05 --> ietf-00)?   The draft name must change, right?  If this is a Datatracker history issue, is it understood that the replace-by behavior enables diffs to cross the individual to WG draft boundary, and it really doesn't matter what names are used?

> specific than the name suggests, then renaming can help resolving the

In principle, yes, but for this case, how is the "http" name too generic?  Do we have a single concrete reason that has been vetted?  How can the draft explain to readers why the most obvious name wasn't used?   What is the distinguishing characteristic that potential consumers should use to ascertain if the modules are [in]appropriate for them?

As for the title and module name, it seems the simplest thing is:

	OLD:
		title: 	Groupings for HTTP Clients and Servers
		module: 	ietf-http-client
		module: 	ietf-http-server

	NEW:
		title: 	Groupings for RESTful HTTP Clients and Servers
		module: 	ietf-restful-http-client
		module: 	ietf-restful-http-server

But isn't there also an issue of names being overly specific?  Some may ask why the draft is limited to RESTful HTTP, being that it only configures endpoints and has nothing to do with if the application is RESTful or not.

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 14 Nov 2019 12:01:13 +0000

> But isn't there also an issue of names being overly specific?  Some may ask why the draft is limited to RESTful HTTP, being that it only configures endpoints and has nothing to do with if the appli…

I do not think we should open the door to discussions what is RESTful
and what is not... Perhaps we need something like "RESTCONF and
similar" - not a serious proposal. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 13:03:28 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> I saw but didn't read the thread.  Did it cover crossing from an
> individual draft to a WG draft (i.e., kwatsen-05 --> ietf-00)?

Yes.

> The
> draft name must change, right?  If this is a Datatracker history
> issue, is it understood that the replace-by behavior enables diffs to
> cross the individual to WG draft boundary, and it really doesn't
> matter what names are used?

Personally I don't care; just pointing out a discussion that may be
relevant.

> In principle, yes, but for this case, how is the "http" name too
> generic?

I think it is the name "ietf-http-server" that seems to indicate that
this a module that can be used to configure any HTTP server.  (See
below!)

> Do we have a single concrete reason that has been vetted?
> How can the draft explain to readers why the most obvious name wasn't
> used?  What is the distinguishing characteristic that potential
> consumers should use to ascertain if the modules are [in]appropriate
> for them?
> 
> But isn't there also an issue of names being overly specific?  Some
> may ask why the draft is limited to RESTful HTTP, being that it only
> configures endpoints and has nothing to do with if the application is
> RESTful or not.

I wonder if the names should be "ietf-http-server-groupings" instead?
(and same for tcp / ssh / tls, but not netconf / restconf).  We
already have some "-types" modules.  Or even "ietf-http-server-types",
if by "type" we mean "typedef and/or grouping".

This could also be a way to make the name less problematic.  It makes
it more obvious that these modules provide building blocks, rather
than a complete solution.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 12:41:32 +0000

Hi Juergen,

> and what is not...

No need, there are a ton of answers on stack overflow.  The only question is if its proper to put ourselves in that box.

> Perhaps we need something like "RESTCONF and similar" - not a serious proposal. ;-)

Kek.  The thing is that the "https-notif" draft isn't RESTCONF-based, but it's "similar"!  ;)

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 13:08:48 +0000

Hi Martin,

> Personally I don't care; just pointing out a discussion that may be

Ack.  Let's focus on the module names, the draft name will fall out from that discussion.

> this a module that can be used to configure any HTTP server.  (See

It's more like a possible basis to configure any HTTP server, which to me still seems like the right thing to do, until someone can provide a concrete technical reason why it cannot be so.

> I wonder if the names should be "ietf-http-server-groupings" instead?

Hmmm, this is an interesting idea...

> (and same for tcp / ssh / tls, but not netconf / restconf).  

I see why you might say this, but the netconf/restconf drafts also define groupings, which are (IMO) more important than the containers, which we added under questionable conditions (i.e., the "client" containers make almost no sense, and the "server" containers have limited use, especially without the ability to augment/refine things when "implemented").   

> We

...and identities and features (and maybe something else I'm not thinking about just now).

> than a complete solution.

I truly appreciate the intention behind this idea and love the idea of sticking with an undiluted "http", but I question if putting "grouping" into the module name is ideal, perhaps "base" or "basis" would be better?   Even for the NC/RC modules, they are merely a base/basis for higher-level business logic.  [note: I also thought about "params", but the (IMO useless) containers in the NC/RC modules don't lend themselves well to being called "params"]

To help visualize these options:

	ietf-http-server-base
	ietf-http-server-basis
	ietf-http-server-params

	ietf-restconf-server-base
	ietf-restconf-server-basis
	ietf-restconf-server-params

To be clear, I'm not yet agreeing to or promoting this approach yet, though it seems promising.

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 14 Nov 2019 13:26:08 +0000

Hi Kent,

From: Kent Watsen <[email-masked]>
Sent: 14 November 2019 13:09
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]; [email-masked]; Rob Wilton (rwilton) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

Hi Martin,

It's more like a possible basis to configure any HTTP server, which to me still seems like the right thing to do, until someone can provide a concrete technical reason why it cannot be so.
[RW]
Do we require consensus from the httpbis WG if we want to use ietf-http-server.yang?  If we do, then how long will that take?  We really want to get these drafts and YANG modules finished (even if they are not perfect).

We

...and identities and features (and maybe something else I'm not thinking about just now).
[RW]
Probably also extensions.

It is worth noting that iana-if-type.yang defines identities.  Other "-types" YANG modules define some groupings.

So, perhaps by type it really means a YANG module that does not define any data-nodes (outside groupings), RPC, notifications, or actions.

               ietf-http-server-base
               ietf-http-server-basis
               ietf-http-server-params

To be clear, I'm not yet agreeing to or promoting this approach yet, though it seems promising.
[RW]
I quite like the idea of "ietf-http-server-types.yang" ...

Thanks,
Rob

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 15:26:57 +0000

Hi Rob,

> [RW]
> Do we require consensus from the httpbis WG if we want to use ietf-http-server.yang?

As I understand it, WGs are allowed to standardize anything within their charter without the need to consult other working groups, unless the work falls within the scope of another WG's charter.  Here is the httpbis charter: https://datatracker.ietf.org/wg/httpbis/charter <https://datatracker.ietf.org/wg/httpbis/charter>.

> If we do, then how long will that take?  We really want to get these drafts and YANG modules finished (even if they are not perfect).

In my opinion, the very limited scope of the existing http-client-server draft is right-sized and likely applies to *all* HTTP implementations.  I feel that the HTTP-chairs were/are (depending on how much of this thread they're reading) simply unclear with regards to intention.  Had the clear majority of the NETCONF WG said that the existing name was best, then the chairs could've declared "rough consensus" (and pass it to the IESG in the shepherd writeup).

Folks keep thinking that this one draft is going to delay things, but forget that it is not the proverbial long pole in the tent.  One thing that would help things go faster would be to parallelize the effort.  Me driving everything isn't good.  Does somebody want to drive running the http-client-server draft by HTTP experts?  Does anyone know an HTTP-expert that has YANG-clue?

Kent // contributor

---

From: tom petch <[email-masked]>
Date: Fri, 15 Nov 2019 12:48:11 +0000

---- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, November 14, 2019 1:08 PM

Hi Martin,

> Personally I don't care; just pointing out a discussion that may be

Ack.  Let's focus on the module names, the draft name will fall out from
that discussion.

<tp>

Kent

I see this thread conflating names with names and names.

Module name I see as the most important; it is permanent, will be seen
by many people in many contexts and so must be an accurate reflection of
the contents.  If, during the development of the I-D, the contents
change, then change the name!  Yes, those with early implementations
will have to change but that is always the price of implementing an I-D

RFC Title also matters; it is permanent, widely seen in many contexts
and should tell people whether or not to go further, to read the
abstract.

But the name of the I-D is quite different.  It vanishes when the RFC
appears and ceases to be of any relevance but must change
from -<author>- to -ietf- when an I-D is adopted.  Otherwise it is just
a string, an identifier and subject to the requirements of an
identifier - like, stabillity.   So any other change than the one I just
mentioned I think a bad idea, which is what I said on OPSAWG; there the
title is good, no need to change, the I-D name is just an identifier,
leave it alone, do not try to give it semantic significance.

Tom Petch

> this a module that can be used to configure any HTTP server.  (See

It's more like a possible basis to configure any HTTP server, which to
me still seems like the right thing to do, until someone can provide a
concrete technical reason why it cannot be so.

> (and same for tcp / ssh / tls, but not netconf / restconf).

I see why you might say this, but the netconf/restconf drafts also
define groupings, which are (IMO) more important than the containers,
which we added under questionable conditions (i.e., the "client"
containers make almost no sense, and the "server" containers have
limited use, especially without the ability to augment/refine things
when "implemented").

> if by "type" we mean "typedef and/or grouping".

...and identities and features (and maybe something else I'm not
thinking about just now).

> than a complete solution.

I truly appreciate the intention behind this idea and love the idea of
sticking with an undiluted "http", but I question if putting "grouping"
into the module name is ideal, perhaps "base" or "basis" would be
better?   Even for the NC/RC modules, they are merely a base/basis for
higher-level business logic.  [note: I also thought about "params", but
the (IMO useless) containers in the NC/RC modules don't lend themselves
well to being called "params"]

ietf-http-server-base
ietf-http-server-basis
ietf-http-server-params

To be clear, I'm not yet agreeing to or promoting this approach yet,
though it seems promising.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Nov 2019 16:51:48 +0000

At first I thought that there wouldn't be need to respond to this message, as it retraces ground we covered before, but latching onto the "the name of the draft doesn't matter" theme as opportunistically as possible, I hereby recommend that we name the adopted draft "draft-ietf-netconf-http-client-server" (yes, "http", as it I think it should be), whilst having potentially different names for modules and groupings inside and, of course, a title that makes everyone happy.

With this understanding in place, it should be okay to close the WGLC now, right?   Mahesh?

Kent // contributor (and recused chair)

> On Nov 15, 2019, at 7:48 AM, tom petch <[email-masked]> wrote:
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Nov 2019 16:53:17 +0000

Sorry, I meant s/WGLC/adoption/   (edited below).

K.

> On Nov 15, 2019, at 11:51 AM, Kent Watsen <[email-masked]> wrote:
> 
> 
> With this understanding in place, it should be okay to close the adoption now, right?   Mahesh?
> 
>> On Nov 15, 2019, at 7:48 AM, tom petch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: "Kent Watsen" <[email-masked] <mailto:[email-masked]>>
>> To: "Martin Bjorklund" <[email-masked] <mailto:[email-masked]>>
>> Cc: <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>>;
>> <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>>