----- Original Message ----- From: "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx> To: "Stephen Farrell" <stephen.farrell@xxxxxxxxx> Cc: <ietf@xxxxxxxx> Sent: Sunday, December 08, 2013 9:26 PM > On 09/12/2013 09:34, Stephen Farrell wrote: > > > > On 12/08/2013 05:56 AM, l.wood@xxxxxxxxxxxx wrote: > >> Stephen, > >> > >> I've no idea what you think you mean when you say 'moving beyond > >> mandatory to implement'. My take is that encryption should never be > >> mandatory to implement. > > > > MTI security is what's called for by BCP 61. Sometimes the MTI > > security for a protocol will involve confidentiality, other > > times (e.g. routing protocols) it has tended not to. So your > > "take" is at odds with long standing IETF BCPs. > > And just to repeat an earlier discussion: > > MTI != MTIMC != MTEBD != MTD > > Mandatory to Implement > Mandatory to Implement and Make Configurable > Mandatory to Enable by Default. > Mandatory to Deploy > > These distinctions matter. The first three are requirements on > coders and vendors, that we can include in IETF standards. > The last one is a requirement on operators, who will do what > they think best or what local laws force them to do. Absolutely; and this is something that the I-D under discussion seems to ignore. Also, quite often our RFC specify that a particular feature should be controllable, that there should be a 'button' to allow it to be disabled or enabled, which I think again needs promoting. (If I had the option to turn off encryption when submitting this e-mail to my MX, I would do it most of the time - it is nothing but hassle and, of course, it is 'end to almost-nowhere' and so seems to me to add nothing by way of privacy). Tom Petch > > Brian >