Subject: [art] Fwd: Second LC on draft-ietf-opsawg-mud

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Mar 2018 13:20:19 +1100

Hi ART@,

I spent a fair amount of time walking Eliot through BCP190's implications upon MUD's design.

In the end, we came to a position where MUD reserves the query string on MUD URLs for future use (they want to be able to insert data from the MUD controller to the MUD server there, even though the MUD URL isn't under control of the controller).

My suggested alternative for that sort of case was using a HTTP request header, but there was some concern that some implementers might find this difficult.

While in Web architecture an application would ideally use some sort of runtime form language to describe the query arguments, it's also pretty common for the resource itself to define what query arguments are acceptable, their syntax, etc. Furthermore, while not standard behaviour, it's become extremely common for implementations to treat query strings as using the application/x-www-form-encoded format, and to ignore query strings they don't understand.

So this requirement:

~~~
Applications MUST NOT directly specify the syntax of queries, as this can cause operational difficulties for deployments that do not support a particular form of a query.
~~~
 -- https://tools.ietf.org/html/rfc7320#section-2.4

is perhaps too strong.

Two questions:

1) Does anyone have any heartburn with allowing MUD to specify URL query strings for its resources in this fashion? Note that MUD does not currently specify any syntax/structure for query strings (although it might one day), it just forbids their use in MUD URLs.

2) What do people think about relaxing the requirement there in a future revision of BCP190? E.g., to a SHOULD NOT, and/or with some further contextualisation?

Cheers,

> Begin forwarded message:
> 
> From: Warren Kumari <[email-masked]>
> Subject: Second LC on draft-ietf-opsawg-mud
> Date: 3 March 2018 at 5:15:08 am AEDT
> To: IETF Discuss <[email-masked]>, [email-masked]
> Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fliAyszfHNAkBGQGz-bxhEprwJo>
> 
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
> 
> This document had a (successful) IETF LC on 2017-10-24. The authors
> had asked me to hold it after the LC completed as it has a dependency
> on parts of draft-ietf-netmod-acl-model.
> 
> It is now stable, but there have been sufficient changes since the
> original LC (https://www.ietf.org/rfcdiff?url1=draft-ietf-opsawg-mud-13&url2=draft-ietf-opsawg-mud-18
> ) that I wanted the community to have a chance to comment on the
> changes.
> 
> So, please let me know by March 9th (1 week) if any of the changes in
> the new version cause you significant heartburn. Note that this is not
> a repeat IETF LC, but rather a chance to object to the specific
> changes.
> 
> Thank you,
>    W
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 5 Mar 2018 21:33:48 -0600

> 1) Does anyone have any heartburn with allowing MUD to specify URL query strings for its resources in this fashion? Note that MUD does not currently specify any syntax/structure for query strings (…

On their face, the rationale of "it's more complex to implement" and 
"APIs are already doing this" aren't terribly compelling, so perhaps a 
bit of expounding especially on the first one might be helpful.

To be clear, for the "new header" hypothetical approach, are we really 
just talking about having to call "setRequestHeader()" on an XHR object 
(or the equivalent for whatever client library is in use)? If so, I'm 
not sure how much weight the "implementation complexity" argument bears: 
this is a trifling amount of additional work.

> 2) What do people think about relaxing the requirement there in a future revision of BCP190? E.g., to a SHOULD NOT, and/or with some further contextualisation?

I think there's probably room for some "MUST NOT... except..." language 
in here. I'm not familiar with MUD's situation, but if it raises Really 
Good Reasons that having protocols define fixed formats for query 
strings, paired with an explanation about why the harm to general URL 
principles aren't as bad as for other cases, then perhaps they can form 
a basis for reasonable exceptions.

/a

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Mar 2018 08:19:34 +0100

Hi Adam,

On 06.03.18 04:33, Adam Roach wrote:
>> 1) Does anyone have any heartburn with allowing MUD to specify URL
>> query strings for its resources in this fashion? Note that MUD does
>> not currently specify any syntax/structure for query strings
>> (although it might one day), it just forbids their use in MUD URLs.
>

The key issue is that we have (at least) three parties in this system,
and that the MUD-URL itself is meant to be held fixed, as far as the
Thing (end device) is concerned.  We envision that the most a device
might claim in a query would be a major change to the MUD file
specification (like, for instance, a move away from YANG/JSON or how
resolution is supposed to work).  In addition, we want to leave some
room for the controller passing additional information back to the
manufacturer, such as a posture assessment.  In considering how that
happens, the manufacturer will not control the query itself- that would
be a standards action, assuming we go down this route.  The point is to
not create clashes while we have a more relaxed conversation about it,
rather than try to foreclose options at this point.  Also, the text
requires no browser code changes, and server implementations should
already defend against queries they do not understand.

> just talking about having to call "setRequestHeader()" on an XHR
> object (or the equivalent for whatever client library is in use)? If
> so, I'm not sure how much weight the "implementation complexity"
> argument bears: this is a trifling amount of additional work.

It's not a simple matter of implementation complexity but whether
architecturally we want to have the information in one place (e.g., a
URL) rather than having to stitch a URL and a header together to deliver
what amounts to a query.  And again, this is the conversation we don't
really want to try to shove through last call, but consider after some
operational experience.

>
>> 2) What do people think about relaxing the requirement there in a
>> future revision of BCP190? E.g., to a SHOULD NOT, and/or with some
>> further contextualisation?
>
>
> I think there's probably room for some "MUST NOT... except..."
> language in here. I'm not familiar with MUD's situation, but if it
> raises Really Good Reasons that having protocols define fixed formats
> for query strings, paired with an explanation about why the harm to
> general URL principles aren't as bad as for other cases, then perhaps
> they can form a basis for reasonable exceptions.

Fair enough.  Again, the conversation in front of us.

Eliot

---

From: Adam Roach <[email-masked]>
Date: Tue, 6 Mar 2018 22:42:21 -0600

> really want to try to shove through last call, but consider after some

I still haven't had time to look over the document, but I think you'd be 
safe with a statement along the lines of: (a) this document does not 
define query parameters for the URLs, and (b) MUD server operators would 
be well advised to avoid the use of query parameters on MUD URLs, as it 
is possible that future specifications may define specific query 
parameter handling. That should be enough to put a pin in the topic 
until we have the operational experience (and various conversations) to 
make a more informed decision about how to proceed.

/a

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Mar 2018 08:27:05 +0100

Hi Adam,

On 07.03.18 05:42, Adam Roach wrote:
>
> I still haven't had time to look over the document, but I think you'd
> be safe with a statement along the lines of: (a) this document does
> not define query parameters for the URLs, and (b) MUD server operators
> would be well advised to avoid the use of query parameters on MUD
> URLs, as it is possible that future specifications may define specific
> query parameter handling. That should be enough to put a pin in the
> topic until we have the operational experience (and various
> conversations) to make a more informed decision about how to proceed.

I think we're within epsilon on wording.  I think you've brought out
that it's probably a good idea to outline a bit more why the text is
there, which is that there is a potential future interoperability
problem.  And so my understanding is that the shorthand for that is
usually "MUST" or "MUST NOT".  But I can live with "use a query at your
own peril" or words to that effect.  It seems to me to amount to the
same thing.

Eliot

---

From: Adam Roach <[email-masked]>
Date: Wed, 7 Mar 2018 03:25:11 -0600

> own peril" or words to that effect.  It seems to me to amount to the

This is a pretty important difference. We're talking about operational 
guidance here, not protocol behavior. When it comes to operational 
guidance about how URLs are assigned, normative imposition of structure 
(even forced omission of specific URL components) is an outright 
violation of BCP 190, which puts you well into DISCUSS territory when 
the document hits the IESG.

Non-normative operational advice doesn't quite have the same problem, 
although I admit it's skating really close to the line. The only reason 
I'm not balking at the concept is that Mark implied the potential to 
discuss a BCP 190 update that loosens this restriction under certain 
circumstances, and -- if such is the case -- giving operators fair 
warning of such a possibility seems warranted. As I implied before, 
while it's not obvious to me now that such a relaxation of BCP 190 is 
okay, I'm not foreclosing on the possibility of some compelling 
rationale coming along.

/a

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Mar 2018 11:26:18 +0100

Ok, copying Warren for guidance.  Please see below.

>>> conversations) to make a more informed decision about how to proceed.

I'm happy to make the guidance non-normative, so long as the operational
warning is clear.  I understand that we have an ordering problem here,
and that BCP 190 is indeed in play, even though I don't think it
envisioned this use case.

My proposed change, then, is as follows:

OLD:

Any "https://" URL without a query component can be a MUD URL. For example:

NEW:
Any "https://" URL.  However, see below about query components.  For example

OLD:

The query string of the MUD URL is reserved for potential future use;
MUD URLs
MUST NOT contain queries when sent to the controller. MUD file servers MUST
ignore query parameters that they do not understand.

NEW:

The query string may be useful in the future to convey additional
information that may
need to be standardized.  This is the subject of future work.  As such,
device and MUD
controller developers are advised to avoid its use or otherwise further
document its use
in follow-on work, so as to avoid future potential name clashes.

Adam, is that sufficient?  If so, Warren, should I publish this change? 
This is the only textual issue that came up in your 1wk L/C.

Eliot

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Mar 2018 08:29:45 -0500

> Adam, is that sufficient?  If so, Warren, should I publish this change?

Whatever you'd prefer - I'm one of the "post early, post often" types
- we have a diff tool, so people can see what's changed, and
improvements make it easier for future reviewers... but other
(crazy![0]) people have other ideas, so do whichever you'd prefer.

... but, we are still in the draft cut-off phase, so if you do decide
to post a new version, please wait till the meeting starts.

W

[0]: Yes, this is the hill I've decided to die on - it's pretty and
has heather... :-P

---

From: Adam Roach <[email-masked]>
Date: Wed, 7 Mar 2018 10:41:46 -0600

> This is the only textual issue that came up in your 1wk L/C.

With the caveat that I haven't read the document yet for full context 
[1], this seems good.

/a

____
[1] e.g., it's not obvious why devices *and* controllers need to heed 
this advice: it really only needs to be whichever acts as an HTTP 
server. The advice really only need apply to whichever one allocates URLs.