[Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)

Magnus Westerlund via Datatracker <noreply@ietf.org> Thu, 11 July 2019 13:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 312ED12027D; Thu, 11 Jul 2019 06:40:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com>
Date: Thu, 11 Jul 2019 06:40:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE>
Subject: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Jul 2019 13:40:44 -0000

Magnus Westerlund has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:



A. This is really a discuss discuss. With to little time to dig into the
details it appears that this protocol is making i hack of its interface towards
the its transport. It appears to attempt to use an HTTP rest interface, but
then it is also have a lot of talking about requirement for the TLS connection
underlying the HTTP. So to illustrate the issue I see here is what happens if
one like to use QUIC as the underlying transport for the rest interface rather
than TCP/TLS? So can this document achieve a clearer interface to the lower
layers so that it will be simpler to move the protocol to another underlying
version of the HTTP "transport"?

B. Section 5.6:

 The server MUST answer with a suitable 4xx
   or 5xx HTTP [RFC2616] error code when a problem occurs.

Referencing RFC 2616 that has been obsolete by RFC 7230 and companions. I do
note that there are no normative reference for that part in this document.