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

[Martin Bjorklund <[e-mail]>]

Hi,

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


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

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