Hi Mark,
In considering my responses below, please keep in mind the following
text which is in the draft:
> In this specification we describe each of these building blocks and how
> they are intended to be used together. However, they may also be used
> separately, independent of this specification, by local deployments
> for their own purposes.
This is a relatively new concept and we are trying to walk before we
run. We should expect that the building blocks will be used in
different ways in different contexts, which in case of IoT really is
quite a movable feast.
Now please see below.
On 10/27/17 1:18 AM, Mark Nottingham wrote:
>
>> This is spelled out in Section 5. Only "https" may be used.
> My apologies, I missed that. It might be worth calling this out earlier.
Ok, what I'm proposing is the following. Feel free to suggest better.
Processing of the MUD URL
-------------------------
MUD URLs always use the HTTPS schema. MUD controllers that are able
to do so SHOULD resolve MUD-URLs, following the normal rules of
{{RFC3986}} and retrieve signature files via HTTP over TLS
{{RFC2818}},{{RFC7540}}. Requests for MUD URLs should be made with an
"Accept" header containing "application/mud+json". Normal HTTP
semantics should be observed.
If a MUD controller is not connected to the Internet, other means may
be used to import MUD files and associated signature files. So long
as the signature of the file can be validated, the file may be used.
In such environments, controllers SHOULD warn administrators when
cache-validity expiry is approaching so that they may check for new
files.
<--snip-->
> HTTP can be used offline as well. Since adding some other resolution mechanism would almost certainly require revising the specification and/or adding extensions, why not do it then?
One of the transfer mechanisms we anticipate being used is a file import
(e.g., USB stick). That wouldn't really require an additional
specification. And while other specifications may be necessary in other
contexts, they may not be here at the IETF. A perfect example: at least
one of the plethora of IoT transmission schemes requires only that a
device be preconfigured with a PSK, and that there be a backend database
of those PSKs. It's a sure bet that the MUD URL itself won't be
transmitted in that case, and it's 70/20 as to whether the URL itself or
the policy in the file is stored. In either case, for that mechanism,
the work wouldn't be performed at the IETF, although I would expect this
work to be referenced.
>
>
>>> * 3.5 systeminfo points to a URL for a human-readable description, but does not describe how it is to be localised for the administrator. E.g., should the fetch for that URL include Accept-Language? If it's HTML, how should that be presented? What versions of HTML are allowed?
>> Yes, the intent is to allow for the use of "Accept-Language". If you
>> have a recommendation about HTML versions or around language support, I
>> would be grateful. The intent is also for this not to be a large file,
>> but very few words to describe the device, possibly with a link <a> for
>> more information.
> Allowing arbitrary HTML content has a number of risks, if it's to be displayed in another context. I'd strongly recommend you specify a more constrained format.
What do you have in mind? I just ask that it be previously
standardized. If your argument is that we should stick with UTF-8 text,
perhaps that's okay as well, but the WG should get a chance to comment
on that, as it would eliminate links.
>
>
>>> * 3.6 extensions says that extensions have to be declared up-front. This is counter to common practice for most HTTP/JSON based APIs; why is it necessary?
>> This is due to an unclear statement in 3.6. The words "prior to" should
>> probably be replaced by "without". It may be an artifact of an earlier
>> version. The intent was to get rid of the ordering, precisely to avoid
>> ordering concerns.
> Right, but that doesn't impact my comment. Why do you have to declare extensions at all?
The purpose of the declaration is, like other specifications, to provide
a means to unambiguously state how an extension should be interpreted.
Also, consider this: some extensions may require parsing of other files,
rather than extending the MUD file itself. This was something the IoT
directorate review requested in particular.
>
>
>>> * 5. What does a MUD URL look like? uses a well-known URI to establish a structured name space. RFC5785 Section 1.1 explains that this is not the purpose of well-known URIs. Furthermore, it creates static structure in URLs, which is strongly discouraged by BCP190. I'm happy to work with you to help understand and meet your goals without misusing URIs.
>> The issue here ties to above. It's important to externalize the
>> versioning from the file and from the protocol. The MUD URL is a
>> convenient way to do that. We have already seen two versions of the MUD
>> file (XML and JSON). Two others have already been discussed (YAML and
>> CBOR). We've settled on JSON for now, but it's a sure bet that it will
>> change in later versions. We have HTTP as one means for resolution. I
>> expect there will be a few others, given that people have already
>> approached me about alternatives. Also, see my response directly below.
> HTTP already has well-understood mechanisms to identify formats, and they aren't in URLs; putting it there has long and widely been known to be a bad practice. Saying that you need to do so in case one day you want to support a different protocol that doesn't enable those mechanisms isn't a good reason to violate best practice for HTTP.
>
> You seem to be engaging in an attempt to layer your application semantics onto multiple application protocols with a one-size-fits-all approach. I'll point you at experiences with SOAP and WS-* to illustrate how well that goes.
We would like a self-describing file (it is, in fact, so, based on
earlier review comments), but the format is likely to change, as it has
in the past. And we need to be protocol-neutral in how that file and
its signature are processed. That leaves us limited options, which is
how we got here. We picked one means to do that. Taking into account
that history if there's something we can do better, let's make a
change. Mark, I'd be happy to take you up on your earlier offer along
those lines.
>> plus we want to make it easy for people who are really just
>> acquainting themselves with our technology to easily deploy MUD.
>> Requiring a header field would cause them to do all sorts of web
>> customization. Storing a file is already a challenge for some, not to
>> mention generating it.
> If that's your concern, we already have a wonderful specification for these technology-challenged users, the File Transfer Protocol.
The fundamental issue here is that we should take care not to wed the
MUD files themselves to one particular transfer technology. Keep in
mind the USB stick. Arguably FTP is one step above that ;-) I'm
personally open to changes with that in mind, so long as they're not
gratuitous. But there seems to be some confusion regarding the following:
> Double so since here we're literally talking about setting a MIME type -- something that people can do out of the box with a file extension on most filesystem-based HTTP servers, if they choose.
No worries about setting the mime type. We want to be conservative.
Not THAT conservative ;-)
>
>>> ## Editorial Suggestions
>>>
>>> * 1. Introduction needs some reworking; it meanders and has short, choppy sentences, and the voice seems off for a specification.
>> I'm happy to rework specific parts, if you'd like to work with me
>> offline on this.
> Great. You wouldn't happen to have this in Github somewhere, would you?
>
https://github.com/elear/mud/blob/master/drafts/draft-ietf-opsawg-mud-13.mkd
You'll see the changes we discussed in this exchange reflected in that copy.
Eliot
Attachment:
signature.asc
Description: OpenPGP digital signature