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

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 2 Nov 2019 15:22:35 -0700

Just a reminder. This adoption call is still open.

> On Oct 21, 2019, at 3:52 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi WG,
> 
> The author has posted a -04 version of the draft, and believes that it ready for WG adoption.
> 
> This starts a 2 week poll ending on November 4, to decide whether this document should be made a WG document or not. Please reply to this email whether or not you support adoption of this draft by the WG. Indications that the draft has been read will be also be appreciated.
> 
> Thanks.
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Nov 2019 09:34:27 +0100 (CET)

Hi,

In principle I wouldn't mind a document like this.  But if the HTTP
experts have concerns, and based on the contents of the model (*)
perhaps it is better to add the necessary nodes directly to the
higher-level modules (e.g, ietf-restconf-server for the server nodes).

(*) The grouping for the server doesn't really add much, imo.
Basically it has a seemingly arbitrary selection of headers to control
(in fact just 'Server'), which protocol version to support, and a
per-server list of "basic" username/passwords (which is probably not
a common way to configure authentication).

The client grouping also doens't add much, with the possible exception
of the proxy settings; perhaps these nodes could be specified in a
generic grouping.

/martin

Mahesh Jethanandani <[email-masked]> wrote:
> This starts a 2 week poll ending on November 4, to decide whether this
> document should be made a WG document or not. Please reply to this
> email whether or not you support adoption of this draft by the
> WG. Indications that the draft has been read will be also be
> appreciated.
> 
> Thanks.
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Nov 2019 00:04:13 +0000

Hi Martin,

> higher-level modules (e.g, ietf-restconf-server for the server nodes).

Adding the nodes into the higher-level modules seems incorrect, as it would effectively cause the same content to be replicated into a multiplicity of higher-level modules leading to user-confusion and maintenance-complexity.

It seems more appropriate to understand what the concerns are and try to address them.   

Noteworthily, the HTTP experts additionally said that they would have no issue if the module were called something else (ietf-restful-http-client/server?) as then it wouldn't appear to intending to be an all-encompassing HTTP definition and it would no longer require involvement of the HTTP experts to ensure correctness.

> a common way to configure authentication).

True, but it is still meaningful, even if only for the protocol version, and providing a target for higher-level modules to augment into.

> of the proxy settings; perhaps these nodes could be specified in a

The "client-identity" container is important.  Note that "basic-auth" is under an "if-feature" statement in anticipation that higher-level models will want to augment into the "auth-type" choice statement other (potentially proprietary) auth schemes.

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 7 Nov 2019 07:37:56 +0000

> Noteworthily, the HTTP experts additionally said that they would have no issue if the module were called something else (ietf-restful-http-client/server?) as then it wouldn't appear to intending to…

Changing the module name to ietf-restful-http-client/server makes any
reuse of the definitions look back. I also think that the module
should ensure correctness, perhaps not completeness.

/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: Kent Watsen <[email-masked]>
Date: Thu, 7 Nov 2019 15:10:41 +0000

Hi Juergen,

> reuse of the definitions look back.

Can you clarify what you mean by "look back"?

Thanks,
Kent

> I also think that the module

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 7 Nov 2019 15:33:43 +0000

> Can you clarify what you mean by "look back"?

The name just looks odd: Do I want to import something that is labeled
as a restconf specific grouping? The HTTP people do not want us to
define something that may look generic but do we want to define
something that looks like a solution just for restconf? Well, perhaps
we should just put the -restconf- thing in the name and future will
tell us whether people reuse this or attempt to roll their own.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Nov 2019 17:24:16 +0000

> tell us whether people reuse this or attempt to roll their own.

I see, but note that I wrote "restfull" (not "restconf"), which is important since the "https-notif" draft is NOT using RESTCONF (just HTTP).

That said, I don't see why we shouldn't proceed with "http", as that is what the protocol layer is called.   At one point the HTTP chairs said that, if we wanted to use "http", then we should involve the httpbis WG, which makes sense, but shouldn't (in my mind) block an adoption.   I suggest that we take the draft to the httpbis list and (maybe) present it in the httpbis session.  

A couple days ago I looked for the httpbis list, but couldn't find it.  Their agenda [1] looks packed, so probably too late for a new request, but if the HTTP chairs are reading this and think we could squeeze in a quick preso, that would be great, otherwise, pointers to the httpbis list would be appreciated.

[1] https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.html <https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.html>

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Nov 2019 20:50:57 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> 
> >>>> Noteworthily, the HTTP experts additionally said that they would have
> >>>> no issue if the module were called something else
> >>>> (ietf-restful-http-client/server?) as then it wouldn't appear to
> >>>> intending to be an all-encompassing HTTP definition and it would no
> >>>> longer require involvement of the HTTP experts to ensure correctness.
> >>>> 
> >>> 
> I see, but note that I wrote "restfull" (not "restconf"), which is
> important since the "https-notif" draft is NOT using RESTCONF (just
> HTTP).
> 
> That said, I don't see why we shouldn't proceed with "http", as that
> is what the protocol layer is called.  At one point the HTTP chairs
> said that, if we wanted to use "http", then we should involve the
> httpbis WG, which makes sense, but shouldn't (in my mind) block an
> adoption.  I suggest that we take the draft to the httpbis list and
> (maybe) present it in the httpbis session.

I think it is quite clear that the WG doesn't want more delays.  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.

/martin

> A couple days ago I looked for the httpbis list, but couldn't find it.
> Their agenda [1] looks packed, so probably too late for a new request,
> but if the HTTP chairs are reading this and think we could squeeze in
> a quick preso, that would be great, otherwise, pointers to the httpbis
> list would be appreciated.
> 
> [1]
> https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.html
> <https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.html>
> 
> Kent
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 8 Nov 2019 01:44:39 +0000

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*,

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 11 Nov 2019 14:22:35 +0000

Hi Kent,

According to https://datatracker.ietf.org/wg/httpbis/charter/, it looks like the list address is: [email-masked]<mailto:[email-masked]>

Thanks,
Rob

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 07 November 2019 17:24
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04

[1] https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.html

Kent

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 11 Nov 2019 14:26:17 +0000

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.

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,

    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?"

Kent // contributor

---

From: tom petch <[email-masked]>
Date: Tue, 12 Nov 2019 10:28:16 +0000

----- 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.

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.

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?

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,

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

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 16 Nov 2019 11:50:41 +0700

This adoption call was supposed to close last week, but as the discussion was still ongoing, I wanted to let it play out. 

It is apparent from the thread that the consensus to adopt was rough, with the lone dissent came from Mark, the httpbis chair. That dissent has been duly noted. It is also clear from the thread that this draft is needed, and that the WG does not want to see any more delays. Adopting the draft only means that the work now happens in the WG, and that there will be plenty of time to debate any more name changes.

In addition, I am going to encourage the author(s) to present the document in httpbis WG and for the httpbis chairs to invite him for that presentation, by giving him a slot.

This draft is adopted. Author(s), please publish the existing draft as draft-ietf-netconf-http-client-server with no other changes as soon as datatracker opens up for submission.

Thanks.

Mahesh Jethanandani (as co-chair)
[email-masked]

> On Nov 3, 2019, at 5:22 AM, Mahesh Jethanandani <[email-masked]> wrote:
>