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

Adam Roach <adam@nostrum.com> Thu, 11 July 2019 22:52 UTC

Return-Path: <adam@nostrum.com>
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 531AA12016B; Thu, 11 Jul 2019 15:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 8rvaUYuvKPTV; Thu, 11 Jul 2019 15:52:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E08E8120041; Thu, 11 Jul 2019 15:52:24 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6BMqHip044115 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Jul 2019 17:52:19 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562885540; bh=yo306wkegEZV1ntlmYuG5EErP8dmNdZAJ/zt5dmqh4Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Vo7HTHq5HUY8HMRJMwfq3mzxEdqnvykwc4kVeEddBrtim9UbgU5eM7KqIMZ2cl7/v GskWF59J8pslA+uLMWG8h1kRnFQ7tewTAcCTEl2cSjWLFs6uZn5kFKsqKxNPfCTATc p/00rfoUbCRNHuU3rQFgYpHanBCd9enDGMjJgzaQ=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Michael Richardson <mcr+ietf@sandelman.ca>
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
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <20219.1562875510@localhost>
From: Adam Roach <adam@nostrum.com>
Message-ID: <d25962d9-22ae-e6c3-f0d3-6eaf2ad36ec1@nostrum.com>
Date: Thu, 11 Jul 2019 17:52:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <20219.1562875510@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/7JfpuHkUM306K5vlEoEkpIbMMrk>
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 22:52:27 -0000

On 7/11/19 3:05 PM, Michael Richardson wrote:
> <#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?


"HTTP", but even that may be unnecessary in this case.

REST means... something. Exactly what depends on who you ask. In 
practice, the least controversial thing to do is avoid the term; and, if 
you're trying to describe a specific quality (e.g., idempotence), say so 
explicitly.

For this document, I don't think you really care much the purported 
properties of REST -- by any definition -- and I suspect you don't 
conform to them, for at least some number of mutually incompatible and 
religiously-held definitions of that term.

In any case, I don't think the reference adds anything to the text, 
regardless of whether it points to 7.1.2 or to 6.3.2. So I would propose 
something along the lines of:

    Rather than returning the audit log as a response to the POST (with 
a 200
    (OK) response code), the MASA MAY instead return a 201 (Created) 
response
    containing a "Location" header field that indicates the location of the
    prepared audit response. This allows the audit response to appear at a
    location that enables caching.


If that says something other than what you meant, let me know, and I'll 
try to fix it.

/a