----- Original Message -----
From: "Brian E Carpenter" <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
To: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Cc: <ietf(_at_)ietf(_dot_)org>
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(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk 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