Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 11 July 2019 20:05 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 8B7E3120121; Thu, 11 Jul 2019 13:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Dn_bSwdrnJEs; Thu, 11 Jul 2019 13:05:14 -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 DD63A1201DC; Thu, 11 Jul 2019 13:05:11 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CCE23818F; Thu, 11 Jul 2019 16:03:05 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C332E4E9; Thu, 11 Jul 2019 16:05:10 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Adam Roach <adam@nostrum.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, anima@ietf.org
In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com>
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+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: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Jul 2019 16:05:10 -0400
Message-ID: <20219.1562875510@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Mah7eYt7rC8nviJVkqHCXOv2EoM>
Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Jul 2019 20:05:17 -0000

<#secure method=pgpmime mode=sign>

Adam Roach via Datatracker <noreply@ietf.org> wrote:
    > §5.8:

    >> Rather than returning the audit log as a response to the POST (with a
    >> return code 200), the MASA MAY instead return a 201 ("Created")
    >> RESTful response ([RFC7231] section 7.1) containing a URL to the
    >> prepared (and easily cachable) audit response.

    > The DISCUSS portion of my comment on this text is that it is unclear about how
    > the URL is to be returned. It can just as easily be interpreted as returning
    > it in a "Location" header field as it could as returning it in the response
    > body -- or maybe somewhere else entirely (e.g., a link relation).  This
    > ambiguity will cause an interop issue. Please be explicit about precisely how
    > the value is conveyed.

I see how this could be confusing.

    > While not part of the DISCUSS, I also have a fairly serious comment on the
    > phrasing and citation of  "return a 201 ("Created") RESTful response
    > ([RFC7231] section 7.1)". Section 7.1 points to the top-level discussion of
    > Control Data header fields, rather than any general discussion of RESTful
    > responses.  It's worth noting that the term "RESTful" never appears in RFC
    > 7231, so it's really unclear what section this was attempting to target.
    > Perhaps 6.3.2?

Yes, that's what we are trying to target.
I guess we also latched onto section 7.1.2 ("Location")

Can you point me to another document that tries to specify the same thing.
If we shouldn't say we are trying to be RESTful, what should we say?


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