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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 04 April 2019 14:12 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4811206B4; Thu, 4 Apr 2019 07:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wYZxJexmlb0; Thu, 4 Apr 2019 07:12:39 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6901200EC; Thu, 4 Apr 2019 07:12:39 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id j26so1317942pgl.5; Thu, 04 Apr 2019 07:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2uH+X1agomnppXaPLr4DgNZ0y28hLFvwp8I324wvwaA=; b=tN1qBwSUE77omoJkUYPkXLjpHvO7IeqKtDbNx4axMHodggDXJ4iIWJY/zGMw0E7Y3I HV+SzIXcnGOzJZkXe7OpRIL3uERDierpeu0JlVhkUY5dSK5GHA1t0878hHpsvJQ6EbB5 JWRWTN7qBIqcN7CMKdPHqSxdedDmpwJpWngNdAk32A1YFkVEg0SOWvco3Fxs+ih2yihk J3jHZV8UtiAxrrC/von3HLMj4rRYop8VATU9xm14lF0xRZF3rZnGOqxqEwRbHu7h8gEC Dd8Z5ul6y3H8NZwDrRlfMgGLy++c2fmFvYmVJIVKJh4TRavHaonA35p7k5JYttrBS5me 3ulg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2uH+X1agomnppXaPLr4DgNZ0y28hLFvwp8I324wvwaA=; b=fFdMIYvyTNh/8gdP2fv6bihHD/cX3AX/sYC2bMU1QR0hlU6zNmaR4LZKPLJI4V9XNf Mcg/qNVgyLVDqbssxHwE4rkzmpkxnjNEhH3GG8SzMR5PAadbNyDvzivuxiLjCE8+dZ04 MAdrQ7QYu0XsZT4sQRryrPhIKlM6BShlPs67qVu6FknFcsBNekkOEzWhbl9djKE14m7D 8qEzDu2rldgwY/hKgU02HYYIsRTXXK3QSzt9ZOAgTtzb5OwLGMQS3AnE4r4GOW1NNQt5 6T+rhNe4vPWGnM70VEQ64O2x18njImvxSiXhD7EzrkqqLf/2QFz8Tt/r8opc0/sm3TyB H+vQ==
X-Gm-Message-State: APjAAAUg+YUUVqBdP8yQAH7ZevLqNDYex5QQc9i1Vli9kSthomZi95ud TYXb85zt8iFHGWntHHbbBoI=
X-Google-Smtp-Source: APXvYqyNBjQIrbU5fRmljw7dYqHDxePfne4mA3GVkjnVOLpgQL/3WX/QQ5MyWLp2LYxtlJl9afDZaA==
X-Received: by 2002:a63:ff18:: with SMTP id k24mr6023022pgi.140.1554387158299; Thu, 04 Apr 2019 07:12:38 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:78c9:4ec8:b2c9:94e4? ([2601:647:5600:5020:78c9:4ec8:b2c9:94e4]) by smtp.gmail.com with ESMTPSA id i1sm42820985pgc.63.2019.04.04.07.12.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 07:12:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-52B2AC0F-F923-49C1-B3B8-711B82CDDA81
Mime-Version: 1.0 (1.0)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Mailer: iPad Mail (16A404)
In-Reply-To: <CAOdDvNoDFoa30tJ8XDz482_38rw8+ajwW4+dSx7s_psoFY7ukQ@mail.gmail.com>
Date: Thu, 4 Apr 2019 07:12:36 -0700
Cc: Kent Watsen <kent+ietf@watsen.net>, httpbis-chairs@ietf.org, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, netconf@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com>
References: <01000169bf4bb1d5-f6fc0ffc-70e0-439d-9b96-59540b334d0f-000000@email.amazonses.com> <CAOdDvNrgFgjp6uvUPS1EDzS_ZUBwsr06dvWY7gH+fmSabkpa-Q@mail.gmail.com> <01000169cb48a8fe-2012b30c-b858-4b9f-aeea-7c22802b96d9-000000@email.amazonses.com> <CAOdDvNrE4QKfC+-XsaTS_tg8vGbMZqF=iFBn1iKJMW5UvumqjQ@mail.gmail.com> <01000169cc22f874-10931e3c-eedd-41f9-a0e6-ff051c7d2002-000000@email.amazonses.com> <CAOdDvNrQvUUUbwfF0XtC0R_7EfF9k02S1ZYHJy-c12enBBOeTQ@mail.gmail.com> <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <CAOdDvNoDFoa30tJ8XDz482_38rw8+ajwW4+dSx7s_psoFY7ukQ@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/D6XyKmMPAGyfzhBSskx_I24PVWs>
Subject: Re: [netconf] time to meet today after 5pm
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 14:12:43 -0000

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 <mcmanus@ducksong.com>; 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 <kent+ietf@watsen.net>; 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
mjethanandani@gmail.com

>