Re: [art] Ben Campbell's No Objection on draft-ietf-appsawg-file-scheme-15: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Thu, 15 December 2016 23:03 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB6412994F; Thu, 15 Dec 2016 15:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 eq9c7Magc-lQ; Thu, 15 Dec 2016 15:03:35 -0800 (PST)
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 8A2441299C8; Thu, 15 Dec 2016 15:03:02 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBFN2wqV018924 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Dec 2016 17:03:00 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: Ben Campbell <ben@nostrum.com>
To: Matthew Kerwin <matthew.kerwin@qut.edu.au>
Date: Thu, 15 Dec 2016 17:02:58 -0600
Message-ID: <72030290-F923-45EA-B88F-A29E2FB59978@nostrum.com>
In-Reply-To: <MWHPR01MB2670298C94232DD1FC183BE5BE9D0@MWHPR01MB2670.prod.exchangelabs.com>
References: <148174978359.16872.6615576098350625978.idtracker@ietfa.amsl.com> <MWHPR01MB2670298C94232DD1FC183BE5BE9D0@MWHPR01MB2670.prod.exchangelabs.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5310)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/JHj4KIaRT3dyb3Xn10iajuho8sY>
Cc: "appsawg-chairs@ietf.org" <appsawg-chairs@ietf.org>, "art@ietf.org" <art@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-appsawg-file-scheme@ietf.org" <draft-ietf-appsawg-file-scheme@ietf.org>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Subject: Re: [art] Ben Campbell's No Objection on draft-ietf-appsawg-file-scheme-15: (with COMMENT)
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 23:03:36 -0000

Hi Matthew,

On 15 Dec 2016, at 0:09, Matthew Kerwin wrote:

> Hi Ben,
>
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, 15 December 2016 07:10
>>
>> - Section 5: "Implementers MUST research" and "Care MUST be taken"
>> both seem like requirements on people, not on implementations.
>> Furthermore, "research" and "taking of care" are vague in terms of
>> expected results.
>> Can these be recast into concrete expectations of implementation
>> behavior?
>
> I understand what you're asking, and why, but I don't know if it's 
> within my wordsmithing capabilities.  If I changed the RFC2119 
> normative keywords to regular English words I think that would make 
> the problem go away; would the resulting text be enough for security 
> considerations?
>
> The "MUST research" paragraph comes almost verbatim from RFC3986, 
> Section 7.5, but that says "should" instead of "MUST" -- I'd be happy 
> to move back in that direction here.

I think using normal English words (as in not 2119 keywords.) makes 
sense here. You can say important things without 2119 keywords.

An alternative would be to state it in terms of implementation behavior. 
For example: "Implementations MUST restrict the use of data obtained 
from URI components according to the reserved names and characters of 
the attached storage device"

But given that I think the point is that "implementors need to think 
about these issues and do the right thing", dropping the 2119 keywords 
is probably the best approach.

Thanks!

Ben.