IETF Logo Mail Archive

Re: [Anima] two EST question/suggestions

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 12 September 2017 23:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6562D13318A for <anima@ietfa.amsl.com>; Tue, 12 Sep 2017 16:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Z7gcFb0Jduvy for <anima@ietfa.amsl.com>; Tue, 12 Sep 2017 16:57:45 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEB71320C9 for <anima@ietf.org>; Tue, 12 Sep 2017 16:57:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7F9F02009E; Tue, 12 Sep 2017 20:01:55 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7741C806AE; Tue, 12 Sep 2017 19:57:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: anima@ietf.org
In-Reply-To: <ce8e9ee0-6695-b113-94b9-bb56142c537d@gmail.com>
References: <961.1504038708@obiwan.sandelman.ca> <BAA96F8A-C61E-4DE1-9837-7964A0E8B4A2@cisco.com> <2a1cf1e7-f668-cf76-d471-78585d7ad7ba@cisco.com> <8b165f89-3be1-c814-5a88-bf62f708972f@gmail.com> <27231.1505249495@obiwan.sandelman.ca> <ce8e9ee0-6695-b113-94b9-bb56142c537d@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 12 Sep 2017 19:57:43 -0400
Message-ID: <6079.1505260663@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/4Re6bD7Yq0NJYGoCHBVe2vmIyX0>
Subject: Re: [Anima] two EST question/suggestions
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 23:57:47 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> We are running over HTTP 1.1, we have to assume that.
    >> The issue is that both client and server libraries will grow HTTP 2, and we
    >> need to know if this is a problem.
    >>
    >> > It seems to me that we want to minimise the requirements for low end pledge
    >> > devices, and every item that we make mandatory works against that.
    >>
    >> BRSKI does not target constrained devices;  in the future having only an HTTP
    >> 2 library (because the application is using that) might be simplest.  Is it
    >> going to work okay?

    > I don't see why not. But isn't there potentially a class of devices that
    > while not being 'constrained' in the formal sense, nevertheless needs to
    > minimise its software footprint? So the implementer will want to choose
    > the solution with the smallest footprint, rather than whatever MTI we
    > happen to define in 2017.

Yes, I agree with you.

That's why I would like us to permit pledges to support a single client HTTP
library.  They will use whatever HTTP client library that they need for their
primary application... so if it's a webrtc nanny camera, then it might well
be HTTP2 + QUIC.

The problem with HTTP2 is that it permits requests and responses to be
interleaved and not-sequential in the TCP sense.  This potentially has a poor
interaction with the BRSKI state machine.  We ought to say something about
this *today*.

    > Of course we can always change the MTI later, but if we say right now that
    > the MTI only applies to the server side, adding new solutions for future
    > types of pledge becomes more straightforward. As far as I can see, this
    > would have zero impact on first-generation implementations; initially
    > both servers and clients will support the MTI anyway.

My take is that the server has to support every single MTI that we have every
supported.  That's okay.  But, HTTP 1.1 with persistent connections is the
minimum (not the maximum).



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email