Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 May 2014 12:38:40 +1000

Hi David,

Thanks. Responses below.

On 5 May 2014, at 1:16 pm, Black, David <[email-masked]> wrote:

> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These comments 
> were written primarily for the benefit of the operational area directors.  
> Document editors and WG chairs should treat these comments just like any other 
> last call comments.
> 
> Document: draft-ietf-appsawg-uri-get-off-my-lawn-04
> Reviewer: David L. Black
> Review Date: May 4, 2014
> IETF LC End Date: May 7, 2014
> IESG Telechat Date: May 15, 2014
> 
> Summary: Ready with nits
> 
> This draft provides Best Current Practices for specifying (well, mostly not
> specifying) substructure in URIs.  As the author of a URI scheme spec,
> RFC 4088 for SNMP URIs, I can definitely envision some of the problems
> that this draft's recommendations seek to avoid.  Overall, this is a clear
> and well-written draft 

Thank you.

> The author did include operational Difficulty as a rationale for the
> recommendations, thank you.

Glad to oblige :)

> OTOH, the questions in Appendix A of RFC 5706
> are generally inapplicable to this draft, although I do have a couple of
> minor editorial comments:
> 
> [1] The Operational Difficulty paragraph in Section 1 implies that all URIs
> can be represented in filesystems:
> 
>   o  Operational Difficulty - Supporting some URI conventions can be
>      difficult in some implementations.  For example, specifying that a
>      particular query parameter be used precludes the use of Web
>      servers that serve the response from a filesystem.
> 
> I might add the text "if the URI scheme is otherwise appropriate for
> serving of stored responses from a filesystem.”

How about making the example more specific:

“””
For example, specifying that a particular query parameter be used with "HTTP"
  URIs precludes the use of Web servers that serve the response from a filesystem.
“”"

?

> [2] Section 2.1 seems somewhat cavalier in suggesting modifications
> to RFC 4935:
> 
>   A specification that defines substructure within a URI scheme MUST do
>   so in the defining document for that URI scheme, or by modifying
>   [RFC4395].
> 
> I might add "Note that modification of [RFC4935] is NOT RECOMMENDED." and
> add "NOT RECOMMENDED" to the list of RFC 2119 terms used in Section 1.2.

If someone wants to modify that spec (we’re going to reference BCP115, not RFC4395, BTW), they’ll need to go through the appropriate process; if they’re being unwise about it, hopefully we’ll catch that…

Cheers and thanks again,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Black, David" <[email-masked]>
Date: Tue, 6 May 2014 22:30:24 -0400

Hi Mark,

Thanks for the quick response.

For [1], your proposed text is fine and better than what I suggested.

For [2], while I'm sure that you're correct that any unwise attempt to modify that BCP/RFC would be caught, IMHO, it would be helpful to add some text to warn the unwise earlier, before they invest any significant time/effort in pursuing that sort of modification.  I don't particularly care whether an RFC 2119 keyword is used, but I would like to see some sort of clue offered ;-).

Thanks, --David +++Sent from Blackberry

----- Original Message -----
From: Mark Nottingham [mailto:[email-masked]]
Sent: Monday, May 05, 2014 10:38 PM
To: Black, David
Cc: Apps Discuss <[email-masked]>
Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04

Hi David,

Thanks. Responses below.

Thank you.

Glad to oblige :)

“””

?

Cheers and thanks again,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 May 2014 11:58:15 +1000

> For [2], while I'm sure that you're correct that any unwise attempt to modify that BCP/RFC would be caught, IMHO, it would be helpful to add some text to warn the unwise earlier, before they invest…

I’m struggling to come up with appropriate text here. Do we really need to caution people that the process needs to be followed, and that might be difficult if you want to do something controversial? 

E.g. we could say that modifying BCP115 is “unusual” — but considering that there’s a modification of it underway right now, for the second time in eight years, that’s not strictly true.

What target audience are you thinking of? Anyone who has a passing familiarity with the IETF must realise that modifying a Best Current Practice isn’t something you can do unilaterally?

Cheers,

---

From: "Black, David" <[email-masked]>
Date: Wed, 7 May 2014 23:55:30 -0400

> What target audience are you thinking of? Anyone who has a passing familiarity
> with the IETF must realise that modifying a Best Current Practice isn't
> something you can do unilaterally?

I'm thinking about people who aren't active in the IETF, and in particular
don't pay a lot of attention to our processes (heck, it was years after I
started coming to IETF meetings that I finally understood what a BCP is),
but do look at our documents to figure out what to do before getting around
to bringing their "clever" new ideas to us rather later than we might like
to have initially seen them in a perfect world.

> I'm struggling to come up with appropriate text here. Do we really need to
> caution people that the process needs to be followed, and that might be
> difficult if you want to do something controversial?
> 
> E.g. we could say that modifying BCP115 is "unusual" - but considering that
> there's a modification of it underway right now, for the second time in eight
> years, that's not strictly true.

Ok ... here's an suggestion that doesn't use a 2119 keyword:

OLD
   A specification that defines substructure within a URI scheme MUST do
   so in the defining document for that URI scheme, or by modifying
   [RFC4395].
NEW
   A specification that defines substructure within a URI scheme MUST do
   so in the defining document for that URI scheme, or by modifying
   [RFC4395].  The latter approach is not preferred and should only be
   used in exceptional circumstances.

IMHO, twice in eight years is consistent with "exceptional circumstances."

Thanks,
--David

> -----Original Message-----
> Sent: Wednesday, May 07, 2014 9:58 PM
> To: Black, David
> Cc: [email-masked]
> > For [2], while I'm sure that you're correct that any unwise attempt to
> modify that BCP/RFC would be caught, IMHO, it would be helpful to add some
> text to warn the unwise earlier, before they invest any significant
> time/effort in pursuing that sort of modification.  I don't particularly care
> whether an RFC 2119 keyword is used, but I would like to see some sort of clue
> offered ;-).
> 
> I'm struggling to come up with appropriate text here. Do we really need to
> caution people that the process needs to be followed, and that might be
> difficult if you want to do something controversial?
> 
> E.g. we could say that modifying BCP115 is "unusual" - but considering that
> there's a modification of it underway right now, for the second time in eight
> years, that's not strictly true.
> 
> What target audience are you thinking of? Anyone who has a passing familiarity
> with the IETF must realise that modifying a Best Current Practice isn't
> something you can do unilaterally?
> 
> Cheers,
> 
> --

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 May 2014 12:09:21 +1000

>   used in exceptional circumstances.

I’m not against this. What do other people think?

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 May 2014 11:53:24 +1000

I got private feedback from others that they were OK with this too, so I’ve added:

“””
The latter approach is not preferred and ought only be used in exceptional circumstances.
“””

(“ought” instead of “should” to avoid confusion over 2119 terms).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 May 2014 11:11:18 +1000

Hi David,

Discussing this with the IESG, I’ve currently revised this to:

“””
A specification that defines substructure within a specific URI scheme MUST do so in the defining document for that URI scheme. A specification that defines substructure for URI schemes overall MUST do so by modifying {{BCP115}}.
“””

Do you think a note about the inadvisability of doing a BCP115 modification is still necessary, or does the separation here help?

Thanks,

On 14 May 2014, at 10:49 pm, Black, David <[email-masked]> wrote:

> Mark,
> 
> That works for me; thank you for following through on this.
> 
> Thanks,
> --David
> 
>> Sent: Tuesday, May 13, 2014 9:53 PM
>> To: Black, David
>> I got private feedback from others that they were OK with this too, so I've
>> added:
>> 
>> """
>> """
>> ("ought" instead of "should" to avoid confusion over 2119 terms).
>> 
>> Cheers,
>> 
>> 
>>

---

From: "Black, David" <[email-masked]>
Date: Wed, 14 May 2014 08:49:27 -0400

Mark,

Thanks,
--David

---

From: "Black, David" <[email-masked]>
Date: Thu, 15 May 2014 23:55:57 -0400

Hi Mark,

The separation into two sentences is an improvement.  IMHO, an additional
note about inadvisability of modifying BCP115 is still helpful.  OTOH, I'll
defer on whether it's necessary to the ADs involved in approving the draft,
as I had originally flagged this as a minor editorial item and think the
draft is ok with or without the additional note.

Thanks,
--David

> Sent: Thursday, May 15, 2014 9:11 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Discussing this with the IESG, I've currently revised this to:
> 
> """
> A specification that defines substructure within a specific URI scheme MUST do
> so in the defining document for that URI scheme. A specification that defines
> substructure for URI schemes overall MUST do so by modifying {{BCP115}}.
> """
> 
> Do you think a note about the inadvisability of doing a BCP115 modification is
> still necessary, or does the separation here help?
> 
> Thanks,
> 
>