[Anima] two EST question/suggestions

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 29 August 2017 20:31 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AA8D8132D95 for <anima@ietfa.amsl.com>; Tue, 29 Aug 2017 13:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EGtIDIv-OGYc for <anima@ietfa.amsl.com>; Tue, 29 Aug 2017 13:31:49 -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 78602132D91 for <anima@ietf.org>; Tue, 29 Aug 2017 13:31:49 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C2852E1AB for <anima@ietf.org>; Tue, 29 Aug 2017 16:35:11 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 209AD8430C for <anima@ietf.org>; Tue, 29 Aug 2017 16:31:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima <anima@ietf.org>
X-Attribution: mcr
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, 29 Aug 2017 16:31:48 -0400
Message-ID: <961.1504038708@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4>
Subject: [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, 29 Aug 2017 20:31:51 -0000

Max, I suggest that we add some text to section 2 to indicate that BRSKI EST
connections SHOULD be HTTP 1.1 persistent connections.
I wrote:
        <t>Establishment of the TLS connection for bootstrapping is as
           specified in EST <xref target="RFC7030"/> section 4.1.1 "Bootstrap
           Distribution of CA Certificates" <xref target="RFC7030"/>.
           While EST section 3.2 does not insist
           upon use of HTTP 1.1 persistent
           connections, BRSKI connections SHOULD use
           persistent connections.  This is due to the provisional state
           that occurs in the TLS connection.
           The following extensions are added for automation:

We may also want to say something about HTTP 2.0's multiplexed
request/responses (I think we don't want them).  I'm not sure exactly what
the list of things we don't want yet, or how to express this.
I am sure that we don't want QUIC (or SPDY) or other stuff like that!

I don't know if the binary-ness of HTTP2 matters to use at all in the end,
and we should just let that upgrade path simply proceeed.

The other question is about the use of 102 Processing codes, and 201 Created
codes.  I think that we discussed making /requestvoucher more RESTful by
returning a 201 Created, along with a Location: header, and decided against
it.  I think that I'm partly re-opening this question. (Shall I make it a ticket)

The reason for my question is about Registrar->MASA interactions that need to
occur, and timeouts that might occur.  Returning a 201 Created pointing to a
URL that could be used to retrieve the resulting voucher would provide a nice
way to do things. If upon the pledge issuing the GET, the voucher still isn't
ready, a 102 Processing code could be returned.

I'm particularly concerned that the pledge not set too-short timeouts here,
as the only recourse it would have is to close the connection.

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