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

[Mahesh Jethanandani <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
[e-mail]

>