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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 14 Dec 2016 13:09:43 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-appsawg-file-scheme-15: No Objection

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:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I support Stephen's DISCUSS

- 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?

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 Dec 2016 06:09:57 +0000

Hi Ben,

From: Ben Campbell [mailto:[email-masked]] 
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.

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.

Cheers
-- 
Matthew Kerwin
Senior Web Developer, Queensland University of Technology
Enterprise Information Services (EIS) – Application Services, Library Services
Level 2, KG-SYN | GPO Box 2434 | Brisbane, Qld Australia 4001
CRICOS No 00213J

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 Dec 2016 06:15:57 +0000

> 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.

Sorry, Section 7.3.

-- 
Matthew Kerwin | QUT

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 15 Dec 2016 17:02:58 -0600

Hi Matthew,

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

> 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?
>
> 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.

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 Dec 2016 23:27:05 +0000

From: Ben Campbell [mailto:[email-masked]] 
Sent: Friday, 16 December 2016 09:03
> Hi Matthew,
[snip]
> about these issues and do the right thing", dropping the 2119
> keywords is probably the best approach.
>
> Thanks!
>
> Ben.

Excellent, I've made those changes in my copy, and they'll be included in
-16.

Cheers, and thanks
-- 
Matthew Kerwin | QUT