This is an exciting concept, and the draft overall is approachable. I have identified a few areas I think need more detail, and have a longish list of nits (please don't take that to be negative). ==Issues== I find the structure of the introduction unclear. Please consider reworking it. I would suggest even more succinctly listing goals and constraints, and then intended applicability (these things are in the current text, but I think you can render them much more efficiently). In particular, the argument that implementers of things are incented only to provide the minimal amount of behavior to get their thingyness could be more strongly highlighted. The document proposes "reputation services". It needs more words about whether those exist, and what scopes the architecture imagines (an enterprise might have a different idea of a reputation service than a residence). There is a notion of "decent web reputations" in the security considerations section. Who determines that? The security considerations section should talk about attacks against the reputation services. In the first paragraph of Section 2, it's not clear if you are trying to restrict the models to only those in the two documents in the list following the paragraph. I am not a YANG doctor, so this may be in the weeds, but it feels like there's a discrepancy between the diagram at the end of section 2 and the element definitions in section 3. In particular 3.7 doesn't seem to align with what the diagram or the example in Appendix B uses. Should you be defining "from-device-policy" and "to-device-policy" instead of "packet-direction"? (I'm wondering if 3.7 reflects an older design?) At section 3.13, the description of my-controller is not quite right. This bit signals to the mud controller to use a mapping that it knows about or creates. Something else established that class (and maybe gave it a name). I talked about this with Eliot and he has a better description to use. It's not clear to me that this is a good use of .well-known. I suggest getting an expert review on the proposed usage. (I had a quick conversation with Mark Nottingham and got some initial feedback that I'm passing along here. I'm sure there's more that an in-depth review would identify.) Why wouldn't a URI template (RFC6570) do the job? Rather than use RFC3986's query, consider pointing to HTML5 (which would bring the more familiar key=value format). The document needs to say more about how HTTP is used. I assume you only intend to use GET, and that you expect redirects to be followed, and that nothing special needs to be considered with caching? The document needs to be explicit about it. Take a look at . (There's been some conversation about it on the art list, so Eliot, at least, is already aware of it - see ) I think there needs to be more discussion of the PKI used for signing MUD files. Consider discussing whether the stacks used by typical things will let them add DHCP options (or include bits in the other protocols being enabled). If it's well known (I can't say) that these stacks typically _won't_ provide that functionality, then you should punch up the discussion of the controllers mapping other identifiers to MUD URLs on behalf of the thing. You suggest the DHCP Client (which is a thing) SHOULD log or report improper acknowledgments from servers. That's asking a bit much from a thing. I suspect the requirement is unrealistic and should be removed or rewritten to acknowledge that things typically won't do that. The security and deployment considerations sections talk about what the need for coordination if control over the domain name used in the URL changes. It should talk more about what happens if the new administration of the domain is not interested in facilitating a transition (consider the case of a young company with a few thousand start-up-ish things out there that loses a suit over its name). Please discuss whether or not suddenly losing the MUD assisted network configuration is expected to leave the devices effectively cut-off. Right now, you leave the DHCP server (when it's used) responsible for clearing state in the MUD controller. Please discuss what happens when those are distinct elements (as you have in the end of section 9.2) and the DHCP server reboots. Perhaps it would make sense for the DHCP server to hand the length of the lease it has granted to the MUD controller and let the MUD controller clean up on its own? The document currently suggests that a piece of software inspect the WHOIS database to see if registration ownership of a domain has changed. Do you really mean software, or should this be advice to the administrator of the controller instead? ==Nits== I recommend an editorial pass focusing on simplifying sentences. Look particularly where the word "therefore" is used and consider restructuring the surrounds. (It is used non-sequitur in a couple of places). Be careful to call out actors explicitly (I note the places that particularly caught my eye below). Some specific nits: The abstract speaks only about properties of MUD but does not describe what MUD _is_, or is good for. A few more words here would help. Next to last paragraph of section 1 (before 1.1): A means for _who_ to retrieve the description? (Consider rendering the three list elements on their own lines.) The last sentence of section 1 treats "enterprise networks" more specially than it intends, I think. Why couldn't _any_ network do this? Could the sentence be reworded to make it clear that enterprise networks are an example? First sentence of 1.1: Perhaps you mean "general purpose computing devices" instead of "general computing"? "their" has an unclear antecedent. Last paragraph of 1.3: It's unclear what "such an approach" is intended to point to. Would "a general solution that required capabilities their particular device would not use" make more sense? First paragraph of 1.5: "might to allow" is probably meant to be "might be to allow". What does it mean for a controller to "need to speak COAP". Do you mean "controllers capable of speaking COAP"? Fourth paragraph of 1.5 at the discussion of time and effort: Consider rephrasing this to focus on the result of the time and effort (high quality) rather than the time and effort itself. In the list of abstractions at the end of 1.5, you have three things you describe as devices and one thing you describe as a class. You later talk about the abstractions you've described as devices as classes. At this point in the document what you mean by "class" has not been made as explicit as it could be. Section 1.8, item 3: the MUD file doesn't have hosts in it (it has identifiers of some kind). Consider being more explicit about what you mean by testing that against a reputation service. Section 3.1: You say "Which turn was taken". I think you meant "Which, in turn, was taken". Consider deleting "for those keeping score". Section 3.3 is missing a word at "the location any MASA service"? I found the prose in the descriptions of the "manufacturer" and "same-manufacturer" elements (3.8 and 3.9) very confusing. I think additional prose introducing the concepts and maybe some examples would be very useful. What do you mean by "matches" at 3.10. Do you mean "is"? The caution in the 2nd paragraph of 3.12 is not clear. At section 4, consider pointing out that you are not allowing DHCP by default, and that devices that are expected to use DHCP need to have an explicit allow in their MUD file. The description of the manufacturer leaf in the MUD YANG model could be made more useful. Provide a reference for "giaddr" when you use it in section 9.2. Section 14, 2nd paragraph: additional segmentation of what? Second paragraph of Section 15 - it would help to be more precise with agency. _Who_ should review the class? In the security considerations section, when you get to the "if for some reason it is not possible to determine whether ownership has changed", _who_ are you suggesting conduct further review? ==Micro-nits== 1,$s/enorcement/enforcement/g s/autjors/authors/