Overall, I like this specification, and am very interested to see how it is received by the market. That said, I found some significant issues that I believe need to be addressed before publication. ## Design Issues/Questions * 1.8 Order of Operations talks about retrieving the MUD URL, but doesn't give any detail about how clients should do so. What URL schemes are acceptable? If HTTP(S) is, what headers should be sent in the GET request? Should redirects be followed? Should unsuccessful (e.g., 4xx, 5xx) responses be ignored, or trigger some other state? What level of certificate checking is required for HTTPS? Etc. It could be that your intent is "everything that the Web platform does", but that should be said explicitly. * 3.2 and 3.3 duplicate the functionality of HTTP Last-Modified and Cache-Control. What is the benefit of doing so? Realistically, do you expect manufacturers to use protocols other than HTTPS to host MUD files? * 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? * 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? * 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. * 12 Creating and Processing of Signed MUD files uses a separate file (at a fixed location) to host a signature. Why not just require use of HTTPS, leveraging WebPKI? Or, if there's a good reason not to do that, why not carry the signature in a response header field? ## Editorial Suggestions * 1. Introduction needs some reworking; it meanders and has short, choppy sentences, and the voice seems off for a specification. * 1. Introduction uses "buy"; suggest "own", as some limited-capability devices can be made, not bought. * 1. Introduction uses the extremely generic "object" to describe the target hosts for this specification, then switches to "Thing" with no explanation in 1.3. * 1. Introduction waves its hands about possible quality-of-service uses of MUD. I think it'd be best to avoid making claims for features that aren't yet supported. * 1.6 Terminology defines "Thing" as "the device emitting a MUD URL." This is going to be confusing, because the common use of the term is much broader. Suggest "MUD Thing." * 1.7 s/retrieve MUD files/fetch the MUD URLs in order to retrieve MUD files/ * 1.7 s/retrieves the MUD file/fetch the MUD file/ -- Mark Nottingham https://www.mnot.net/