Subject: Re: [netconf] time to meet today after 5pm

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 4 Apr 2019 07:12:36 -0700

What started as a thread to figure out how to handle Kent’s I-D on HTTP configuration for RESTCONF, has resulted in an extensive discussion on the model itself. This discussion belongs to the WG mailing list, and as such I am adding the WG to the discussion.

See inline

> On Apr 4, 2019, at 6:09 AM, Patrick McManus <[email-masked]> wrote:
> 
> Hi Kent, I am indeed a YANG novice. I apologize if that continues to add to the confusion. At least I know a thing or two about HTTP :)
> 
> it seems one of the high level problems we have is that restconf is using HTTP as a stateful connection oriented transport, when you simply cannot define an http application that way. see 4.10 of bcp56bis https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/?include_text=1 .. this in turn creates your need for tcp keep alive configurations.. because restconf state resides at least partially in the connection rather than statelessly in the exchanges, do I have that right?
> 
> I would strongly advise staying away from the term keep-alive. It is a deprecated term of art that is not exactly what you are trying to do at the HTTP level. In the past it has both been a header field as well as a token on the Connection header - and it seems you are describing some kind of message exchange?
> 
> on the client side..   module ietf-http-client {
> [..]
>             the aliveness of the HTTP server.  An unresponsive
>             HTTP server is dropped after approximately max-wait
>             * max-attempts seconds.";
> 
>  what is the point of max-attempts? In what scenarios does N+1 generate a reply that N does not due to connectivity timeout?
> isn't the server dropped after max-wait * (max-attempts + 1) seconds.. because you use the max-wait timeout to trigger the first test
> as well as timeout the final test?
> 
>              "Sets the amount of time in seconds after which if no
>               data has been received from the HTTP server, a HTTP
> 
> what is data? TCP? HTTP protocol elements like HTTP/2 SETTINGS frames? HTTP headers? HTTP message bodies in all or part? HTTP
> message bodies to a particular one of your keep-alive requests? any of them? all of them?  The answers are different if you're trying to
> test e2e.
> 
> what message is supposed to the sent to the server? any guidance? and for the server:
> 
>              "Sets the amount of time in seconds after which if no
>               data has been received from the HTTP client, a HTTP
>               level message will be sent to test the aliveness of
>               the HTTP client.";
> 
> I don't understand what kind of message is initiated by the HTTP server, at least in a version portable fashion, to accomplish this.
> 
> 
>> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <[email-masked]> wrote:
>> 
>> 
>> But we must do something, this is a real issue.  We have to be able to configure RESTCONF clients and servers.
> 
> It sounds like this is a restconf yang model, not a base http yang model.

The intent has been to describe the minimum number of HTTP parameters for the explicit configuration of RESTCONF client/server. 

But based on this thread, I am assuming that the chairs for httpbis WG do not regard the parameters or the approach to achieve “persistence” either correct or part of the HTTP protocol. While it casts doubt on the proposed solution, it is now a decision for the NETCONF WG to decide whether they want to recast the draft as a RESTCONF HTTP module or go back to the drawing board.

Thanks.

> 
>>> Keepalives as well are a really tricky topic.. the mechanism you are using is not really used on the Internet much these days and when it is used it is used to manage persistence, not really timeouts and NAT rebindings which I think is what you're getting at... I can think of 3 other techniques that are used to try and manage rebindings.
>> 
>> Actually, "managing persistence" is exactly what we're trying to achieve here.  Our show-stopping driving use-case regards RESTCONF Call Home (RFC 8071) and, in particular, point "S7" on page 8 of that document, without which a remote device may become a "brick" and require a technician to perform on-site repair.
> 
> please see the bcp56bis reference I made as well as the opening to 7230. HTTP is a stateless protocol, applications that are using it cannot be built around other assumptions about the thransport - they lack version portability and don't survive integration into the ecosystem of libraries, firewalls, routers, load balancers, etc that are the strongest reason to base applications on http.
>  
>> 
>>> I'm also a little concerned about the thinking in the other protocols discussion - http the protocol carries a variety of schemes beyond http:// and https:// and that probably needs to be explored.
>> 
>> Could you provide an example?  I'm aware that there are many other URI schemes (ldap, mailto, etc.), but they are not HTTP.  Are you saying there are some URI schemes (e.g., "myhttp:") that are like an application-layer protocol on top of HTTP?   Or do you mean that HTTP may have different transport bindings besides TCP and TLS?   
> 
> ftp:// ws:// wss:// are the most common schemes carried on http other than http:// and https://. but the protocol is can carry most of what you can structure as a URI and content.
>  
>> 
>>> Which brings me to my question about what HTTP implementations might want to co-author. That wasn't meant as some kind of Not-Invented-Here comment.. rather it was trying to see if we are solving an interop problem or engaging in hope based standardization. HTTPbis tries hard to pursue work that enables interoperation between at least 2 parties that wish to interoperate and that at least some part of that group of implementations is driving the standard. I'm having trouble figuring out who those HTTP parties are here and I'm cautious about proceeding without that.
>> 
>> As mentioned before, this work began as an effort to define the configuration models for RESTCONF clients and servers.  The desire to have a *standards-based* way to do this is especially supported when thinking about deploying networks of heterogeneous devices to perform zerotouch bootstrapping (think autonomic networking).  
>> 
> 
> then perhaps a restconf yang model is what you are defining?
>  
>> 
>> With regards to the HTTP configuration model, it's not so much *if* there will be an HTTP model, but to what extent you (your WG) would like to or demand to be part of the effort to define it.   As the HTTP domain experts, and we being the YANG experts, the ideal scenario is for us to strike a collaboration.   In particular, given that we're trying to put an end to this nearly 5-year long effort, we politely request that you give us the blessing to proceed roughly as planned (i.e., defining a minimal skeleton with as many "feature" statements as needed).   We envision this as a very short engagement (Last Call immediately after Montreal), after which the HTTP model would likely only be touched again when needed.  If history is a guide, I'd guess that might not happen for 3-5 years.
>> 
>> Would a collaboration be okay?  If yes, then is there someone in particular that I (as a contributor/author) can buddy up with in HTTPBIS to get expert-level advice?
>> 
> 
> This puts us in a tough spot. The -00 draft does not do a good job of describing HTTP so I don't feel we can endorse it. The working group has an extensive set of adopted drafts right now and I don't believe it is the right priority to put this in front of them too in order to put the work in to make it appropriately expressive - it would distract from the priorities the group has decided on.
> 
> What do you think of recasting this as a model limited to restconf based applications?
> 
> -Patrick

Mahesh Jethanandani
[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Apr 2019 16:33:46 +0200 (CEST)

Hi,

It was a bit difficult to figure out what this dicussion led to, but
see one simple comment below.

Mahesh Jethanandani <[email-masked]> wrote:
> What started as a thread to figure out how to handle Kent’s I-D on
> HTTP configuration for RESTCONF, has resulted in an extensive
> discussion on the model itself. This discussion belongs to the WG
> mailing list, and as such I am adding the WG to the discussion.
> 
> See inline
> 
> > Hi Kent, I am indeed a YANG novice. I apologize if that continues to
> > add to the confusion. At least I know a thing or two about HTTP :)
> > 
> > it seems one of the high level problems we have is that restconf is
> > using HTTP as a stateful connection oriented transport

I don't think this is correct.  In what way do you think RESTCONF
tries to use HTTP as a stateful transport?

/martin

> > , when you
> > simply cannot define an http application that way. see 4.10 of
> > bcp56bis
> > https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/?include_text=1
> > .. this in turn creates your need for tcp keep alive
> > configurations.. because restconf state resides at least partially in
> > the connection rather than statelessly in the exchanges, do I have
> > that right?
> > 
> > I would strongly advise staying away from the term keep-alive. It is a
> > deprecated term of art that is not exactly what you are trying to do
> > at the HTTP level. In the past it has both been a header field as well
> > as a token on the Connection header - and it seems you are describing
> > some kind of message exchange?
> > 
> >  what is the point of max-attempts? In what scenarios does N+1 generate
> >  a reply that N does not due to connectivity timeout?
> > isn't the server dropped after max-wait * (max-attempts + 1)
> > seconds.. because you use the max-wait timeout to trigger the first
> > test
> > what is data? TCP? HTTP protocol elements like HTTP/2 SETTINGS frames?
> > HTTP headers? HTTP message bodies in all or part? HTTP
> > message bodies to a particular one of your keep-alive requests? any of
> > them? all of them?  The answers are different if you're trying to
> > test e2e.
> > 
> > I don't understand what kind of message is initiated by the HTTP
> > server, at least in a version portable fashion, to accomplish this.
> > 
> > 
> The intent has been to describe the minimum number of HTTP parameters
> for the explicit configuration of RESTCONF client/server.
> 
> But based on this thread, I am assuming that the chairs for httpbis WG
> do not regard the parameters or the approach to achieve “persistence”
> either correct or part of the HTTP protocol. While it casts doubt on
> the proposed solution, it is now a decision for the NETCONF WG to
> decide whether they want to recast the draft as a RESTCONF HTTP module
> or go back to the drawing board.
> 
> Thanks.
> 
> > 
> >>> Keepalives as well are a really tricky topic.. the mechanism you are
> >>> using is not really used on the Internet much these days and when it
> >>> is used it is used to manage persistence, not really timeouts and NAT
> >>> rebindings which I think is what you're getting at... I can think of 3
> >>> other techniques that are used to try and manage rebindings.
> >> 
> >> Actually, "managing persistence" is exactly what we're trying to
> >> achieve here.  Our show-stopping driving use-case regards RESTCONF
> >> Call Home (RFC 8071) and, in particular, point "S7" on page 8 of that
> >> document, without which a remote device may become a "brick" and
> >> require a technician to perform on-site repair.
> > 
> > please see the bcp56bis reference I made as well as the opening to
> > 7230. HTTP is a stateless protocol, applications that are using it
> > cannot be built around other assumptions about the thransport - they
> > lack version portability and don't survive integration into the
> > ecosystem of libraries, firewalls, routers, load balancers, etc that
> > are the strongest reason to base applications on http.
> >  
> >> 
> >>> I'm also a little concerned about the thinking in the other protocols
> >>> discussion - http the protocol carries a variety of schemes beyond
> >>> http:// and https:// and that probably needs to be explored.
> >> 
> >> Could you provide an example?  I'm aware that there are many other URI
> >> schemes (ldap, mailto, etc.), but they are not HTTP.  Are you saying
> >> there are some URI schemes (e.g., "myhttp:") that are like an
> >> application-layer protocol on top of HTTP?  Or do you mean that HTTP
> >> may have different transport bindings besides TCP and TLS?
> > 
> > ftp:// ws:// wss:// are the most common schemes carried on http other
> > than http:// and https://. but the protocol is can carry most of what
> > you can structure as a URI and content.
> >  
> >> 
> >>> Which brings me to my question about what HTTP implementations might
> >>> want to co-author. That wasn't meant as some kind of Not-Invented-Here
> >>> comment... rather it was trying to see if we are solving an interop
> >>> problem or engaging in hope based standardization. HTTPbis tries hard
> >>> to pursue work that enables interoperation between at least 2 parties
> >>> that wish to interoperate and that at least some part of that group of
> >>> implementations is driving the standard. I'm having trouble figuring
> >>> out who those HTTP parties are here and I'm cautious about proceeding
> >>> without that.
> >> 
> >> As mentioned before, this work began as an effort to define the
> >> configuration models for RESTCONF clients and servers.  The desire to
> >> have a *standards-based* way to do this is especially supported when
> >> thinking about deploying networks of heterogeneous devices to perform
> >> zerotouch bootstrapping (think autonomic networking).
> >> 
> > 
> >> With regards to the HTTP configuration model, it's not so much *if*
> >> there will be an HTTP model, but to what extent you (your WG) would
> >> like to or demand to be part of the effort to define it.  As the HTTP
> >> domain experts, and we being the YANG experts, the ideal scenario is
> >> for us to strike a collaboration.  In particular, given that we're
> >> trying to put an end to this nearly 5-year long effort, we politely
> >> request that you give us the blessing to proceed roughly as planned
> >> (i.e., defining a minimal skeleton with as many "feature" statements
> >> as needed).  We envision this as a very short engagement (Last Call
> >> immediately after Montreal), after which the HTTP model would likely
> >> only be touched again when needed.  If history is a guide, I'd guess
> >> that might not happen for 3-5 years.
> >> 
> >> Would a collaboration be okay?  If yes, then is there someone in
> >> particular that I (as a contributor/author) can buddy up with in
> >> HTTPBIS to get expert-level advice?
> >> 
> > 
> > This puts us in a tough spot. The -00 draft does not do a good job of
> > describing HTTP so I don't feel we can endorse it. The working group
> > has an extensive set of adopted drafts right now and I don't believe
> > it is the right priority to put this in front of them too in order to
> > put the work in to make it appropriately expressive - it would
> > distract from the priorities the group has decided on.
> >

---

From: Patrick McManus <[email-masked]>
Date: Thu, 4 Apr 2019 17:38:28 +0200

> tries to use HTTP as a stateful transport?
below

>
> > >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <[email-masked]>
>

also, in an exchange that wasn't copied to the wg,:

> To give a concrete example, there may be a device, deployed behind a NAT,
requiring a persistent management connection to its controller
application.  Because the device is behind a NAT, it MUST initiate the
connection (the controller cannot) and, thus the device MUST ensure
aliveness of the connection to the controller (the controller *needs* the
device-initiated connection to be up in order to send commands to the
device).   In case the controller disappears, perhaps due to its
data-center being hit by a meteor, the device must promptly detect to loss
and initiate reconnection to another controller.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Apr 2019 18:42:11 +0200

> > tries to use HTTP as a stateful transport?

[...]

> and initiate reconnection to another controller.

The issue here seems to be a NAT requiring state, not the RESTCONF
protocol itself requiring state.

/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, 4 Apr 2019 17:05:02 +0000

> > >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <[email-masked] <mailto:[email-masked]>>
> 
> > To give a concrete example, there may be a device, deployed behind a NAT, requiring a persistent management connection to its controller application.  Because the device is behind a NAT, it MUST initiate the connection (the controller cannot) and, thus the device MUST ensure aliveness of the connection to the controller (the controller *needs* the device-initiated connection to be up in order to send commands to the device).   In case the controller disappears, perhaps due to its data-center being hit by a meteor, the device must promptly detect to loss and initiate reconnection to another controller.

To be clear, RESTCONF is not trying to use HTTP as a stateful protocol, but it is ideal to try to keep RESTCONF Call Home connections up, as described above.   Per the "S7" reference, devices SHOULD use RFC 6520 (the TLS heartbeat extension).   This would keep the *stateful* transport (TLS) up but, unfortunately, OpenSSL doesn't want to implement it (worst, they just removed the DTLS code, https://github.com/openssl/openssl/issues/4856 <https://github.com/openssl/openssl/issues/4856>, despite Ben Kaduk and myself stating value).

The thinking behind this thread is that maybe some traffic could run on top of TLS (i.e., at the HTTP layer), to do the same and, if not, then maybe we could do it at the RESTCONF layer.  [FWIW, you might recall NETCONF/RESTCONF keepalives discusseded at the IETF 103 meeting.]

Patrick, if HTTP keepalive is not possible, then lets strike the "keepalive" parts from the ietf-http-client and ietf-http-server models, leaving it to implementations to lean more heavily on their TLS suppliers to implement RFC 6520, or fallback to unprotected TCP keepalives (which is what the BBF/Nokia said they would be doing for expediency).  Regarding the rest, let me clean the remaining bits (i.e., post a -01) and present them to you again then.

For everyone else, this email thread is from last week when Mahesh and I were trying to meet with the HTTPBIS chairs to discuss the http-client-server draft under adoption poll.  We wanted to proactively engage HTTPBIS rather than have any surprises, such as the exchange with TCPM.   Our hope is that we can come to an agreement, like the one struck with TCPM, whereby domain experts in each WG co-author a bare-minimum grouping that enables our 5-year chartered work effort to come to an end.  With regards to Last Call, we can do it joint Last Call, if desired.   For longterm maintenance of the YANG model, we're happy to turn it over to the domain-specific WG, though we don't have any need or expectation for an update, the bare-minimum is sufficient.

Kent // pick a hat

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 9 Apr 2019 19:06:43 +0000

Please see inline.

From: netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Thursday, April 4, 2019 at 7:06 PM
To: Patrick McManus <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netconf] time to meet today after 5pm

below

> >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <[email-masked]<mailto:[email-masked]>>

> To give a concrete example, there may be a device, deployed behind a NAT, requiring a persistent management connection to its controller application.  Because the device is behind a NAT, it MUST in…

To be clear, RESTCONF is not trying to use HTTP as a stateful protocol, but it is ideal to try to keep RESTCONF Call Home connections up, as described above.   Per the "S7" reference, devices SHOULD use RFC 6520 (the TLS heartbeat extension).   This would keep the *stateful* transport (TLS) up but, unfortunately, OpenSSL doesn't want to implement it (worst, they just removed the DTLS code, https://github.com/openssl/openssl/issues/4856, despite Ben Kaduk and myself stating value).

I would recommend against adding any keepalive mechanism to RESTCONF. Strongly recommending the use of HTTPS when using RESTCONF is fine, but keep in mind that RESTCONF was created, and is viewed in the industry, as a “REST-like” alternative to NETCONF. The tradeoff is functionality built into the protocol vs. complexity of writing an application that uses the protocol. It is trivial to make individual RESTCONF requests but more difficult for an application to implement network transactions using RESTCONF than if using NETCONF. An application developer is free to choose the right protocol for the job. Adding complexity to RESTCONF that make it less REST-like would be a mistake, in my opinion.

Cheers,
Charles

Kent // pick a hat

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Apr 2019 10:47:42 +1000

Charles,

> On 10 Apr 2019, at 5:06 am, Charles Eckel (eckelcu) <[email-masked]> wrote:
> 

What do you mean by "REST-like"?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 10 Apr 2019 08:29:54 +0000

On 4/10/19, 2:48 AM, "Mark Nottingham" <[email-masked]> wrote:

    Charles,

With RESTCONF, the YANG models supported by the RESTCONF server result in it exposing RESTful or REST-like APIs to the RESTCONF client. You can view the RESTCONF server as supporting a set of REST APIs with some additional conventions/requirements on the structure on the URIs, such as the root of the RESTCONF API, use of specific HTTP response codes, etc.

Cheers,
Charles
    
    Cheers,

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Apr 2019 13:50:53 +0000

> With RESTCONF, the YANG models supported by the RESTCONF server result in it exposing RESTful or REST-like APIs to the RESTCONF client. You can view the RESTCONF server as supporting a set of REST…

The root of the API is discovered via /.well-known/host-meta, per https://tools.ietf.org/html/rfc8040#section-3.1.

As for what is RESTCONF, from Sections 1.2:

   RESTCONF is not intended to replace NETCONF, but rather to provide an
   HTTP interface that follows Representational State Transfer (REST)
   principles [REST-Dissertation] and is compatible with the NETCONF
   datastore model.

And Section 1.3:

   RESTCONF combines the simplicity of HTTP with the predictability and
   automation potential of a schema-driven API.  Knowing the YANG
   modules used by the server, a client can derive all management
   resource URLs and the proper structure of all RESTCONF requests and
   responses.  This strategy obviates the need for responses provided by
   the server to contain Hypermedia as the Engine of Application State
   (HATEOAS) links, originally described in Roy Fielding's doctoral
   dissertation [REST-Dissertation], because the client can determine
   the links it needs from the YANG modules.

Kent