This looks really good, Eliot. Thanks for being so responsive and positive to my peculiar brand of paranoia and pedantry. Just a few bits of discussion remain... >> I know I ranted about privacy before and the authors took some text I wrote >> as the basis of the privacy considerations, but I'm still worried that the default >> will be that devices are MUD-enabled (good) and that users will not be >> protected. It would be sad if the user's only option is to reject MUD devices >> (especially as they might not even know that the devices are MUD-enabled). >> More burble below, but it seems to me that we should make privacy-supporting >> modes of operation at least the default, but possibly the only approach. >> >> Section 15 has... >> >> The release of a MUD URL by a Thing reveals what the Thing is, and >> provides an attacker with guidance on what vulnerabilities may be >> present. >> >> Pleased to see this text: it was a security concern I had. Good to have >> it flagged. However, the mitigation suggested 2 paragraphs later is a >> bit thin and sounds rather optional. I see how an implementer might >> take action, but what can a user do to protect their device? [...] > > While this may not be a *perfect* solve for all of your concerns, I hope > you will find the proposal below Good Enough. Keep in mind that we > are attempting to address a very broad set of devices with a large variety > of capabilities, from energy-harvesting devices that may never encrypt > (think a wall switch) to devices that have heaps of power and memory > (think robots). Many of the devices have very limited privacy concerns, > while others will have quite a few. In addition, whatever capabilities the > device has must intersect the capabilities found in deployments. > > With all that in mind, what I propose is the following: > • Add text that RECOMMENDs that devices make use of TEAP when there > may be privacy concerns and when it is available; and > • In other cases where privacy may be a concern, we should RECOMMEND > that a configuration option be provided, particularly when devices are > designed to be mobile, which is where I think most of your concerns > stem from. This is getting gooder. Thanks. Even when the MUD controller is on the premises (the not mobile case), it contacts an offsite file server, and that act is visible. Suppose my Hi-Fi uses MUD - now you know that my house is worth robbing. Suppose my intruder alarm uses MUD - now you know what security system I have. Of course, when the MUD controller is remote (the mobile case), it's all even more worrying. I know you are trying to trade between perfect and getting something that will be implemented and so make the world a somewhat better place. But just recall that someone implemented those devices that "leak like sieves" and those folk are unlikely to see a Recommendation as anything like a strong hint. Well, I'm not in a position to block the whole effort, and I'm not enough of an expert to suggest a solution to my concern that works for all types of device. >> There seems to be some overlap of terms and definitions in 1.5 and 1.6. > > Can you be more specific? 1.5 and 1.6 both have "manufacturer". 1.5 has "controller" and 1.6 has "MUD controller". The definitions don't match. >> 3.5 has me confused. Looks like a fine idea, but how does it work? A >> Thing reports the MUD URL, and the file that is pulled contains the >> systeminfo URL, and the info that is pulled contains the localised info. >> Have I got that right? > Yes. > >> That means that the MUD URL has to include the correct systeminfo for >> the locality. Presumably we're interested in the locality of the MUD >> controller. > > The intent here is basically to allow for language tags to do their thing > through one level of indirection. That doesn't require any specific change > to the URL itself. I've included some text in response to Mark, but that > text may further shift based on other suggestions Mark may have. I'm missing something, but that's OK, I don't have to understand something for it to be right :-) So long as it is possible for the MUD Controller to be in one locale and the MUD Server in another and all the bits to work right, I'm happy. >> Introduction >> >> Please do NOT use random uppercase words in your text. There's NO >> need: the readers are no more stupid than the average reader of an >> RFC. >> >> Ditto 3.4, 3.6 > > Sorry- I didn't parse this. Sorry I'm being sassy. I mean, please don't capitalise for emphasis. Just limit yourself to 2119 capitalisation. >> Introduction >> >> The key points are that the device itself is expected >> to serve a limited purpose, >> >> I think you mean s/expected/intended/ > > How about "assumed"? We're both being overly passive. Who has the expectation/intention/assumption? By "intended" I meant "intended by the manufacturer". So, actually, any one of the three words is fine, if you can attribute the verb to someone. >> Introduction >> >> o A classifier that a device emits that can be used to locate a >> description; >> >> Classifier or classification? > > Classifier. Oh. A "classifier" is a person or thing that classifies. I don't think the device emits a thing or a person :-) I think it emits a piece of information that allows the device to be classified. Cheers, Adrian