Getting close. > >> 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. > > Here, I think you have some cause for hope, because on the whole, in the > home, wireless encryption is generally used. It's not perfect but would > address the point you make above. Yes. This addresses communications between device and router, and between router and MUD controller. Of course, there are some issues with the use of wireless encryption in the home (like security concerns) added to the fact that far fewer people use wireless security than you might think given that you hang out with technology-aware folk. But that's OK because (nominally) we have a protection mechanism. But when the home-based MUD controller uses a URL to access a MUD server, isn't that pretty visible and associated with the home (via the IP address)? > > Of course, when the MUD controller is remote (the mobile case), it's all even > > more worrying. > > Yes, and to that end I propose to highlight a particular warning for > open networks (this would be one amongst many that developers should > heed with regard to open networks). OK. That works. > > 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. > > My hope is that this problem will abate over time, but I really cannot > say. My guess is that the same who are unlikely to heed such a > recommendation are also highly unlikely to implement MUD in the first place. Yeah, you're right. I assume you have already written the paper titled "As Clear As MUD". > >>> 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. > > Ah- that is because they are being used in different contexts. One is > intended as a YANG node and the other really means those people who > build the thing. Yeah, got that. But isn't the YANG node supposed to encode the information about the real things? Well, if everyone else thinks this is clear. > >>> 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. > > Ok, I think we might have to disagree. The use of passive in this case > is appropriate because the assumption is general and not attached to a > single party. Also, the following phrase – and the rest of the document > – make clear who is doing what. Sigh. You'll not convince me that passive voice is ever a good thing in a spec. A general assumption is pretty risky. It's a second order assumption: you're assuming that I assume. I'm reminded that the US has actually written laws about "intended use" because those assumptions were not necessarily shared. Maybe it's just writing style. Thanks, Adrian