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

[Kent Watsen <[e-mail]>]

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

K.


> On Nov 15, 2019, at 11:51 AM, Kent Watsen <[e-mail]> wrote:
> 
> 
> 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 adoption now, right?   Mahesh?
> 
> Kent // contributor (and recused chair)
> 
> 
> 
>> On Nov 15, 2019, at 7:48 AM, tom petch <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> ---- Original Message -----
>> From: "Kent Watsen" <[e-mail] <mailto:[e-mail]>>
>> To: "Martin Bjorklund" <[e-mail] <mailto:[e-mail]>>
>> Cc: <[e-mail] <mailto:[e-mail]>>; <[e-mail] <mailto:[e-mail]>>; <[e-mail] <mailto:[e-mail]>>;
>> <[e-mail] <mailto:[e-mail]>>; <[e-mail] <mailto:[e-mail]>>
>> Sent: Thursday, November 14, 2019 1:08 PM
>> 
>> Hi Martin,
>> 
>>> Personally I don't care; just pointing out a discussion that may be
>>> relevant.
>> 
>> 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
>> 
>> 
>>> 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!)
>> 
>> 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
>>> already have some "-types" modules.  Or even "ietf-http-server-types",
>>> if by "type" we mean "typedef and/or grouping".
>> 
>> ...and identities and features (and maybe something else I'm not
>> thinking about just now).
>> 
>>> 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.
>> 
>> 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
>> 
>> 
>