On 03/30/2017 05:26 PM, Jim Fenton wrote:
[removing saag list because this is probably at a lower level of
detail than appropriate there. But feel free to add them if I'm wrong]
My sense that there is a "BCP part" to the draft is probably more
clearly stated that there are really two different things described in
the draft, as the draft itself says in section 5 paragraph 4:
"Note that security directives are a separate mechanism from minimum
confidentiality assurance levels."
It appears to me that it's possible independently to implement/deploy
confidentiality assurance levels and security directives. So I would
split them up into separate documents.
I still see confidentiality assurance levels as more of a BCP-ish
mechanism. It defines particular security requirements for MUA-MTA
connections to meet Confidentiality Assurance Level (CAL) 1, and
different ones for CAL 0. That seems like a best current practice to me.
Disagree. Compliance with both the CAL and the security directives are
a matter of protocol interaction between client and server. The only
real difference is that in the CAL case, no new protocol features need
to be defined (we're talking about new client interactions with existing
server features); whereas for security directives there are changes to
the protocols used by the servers. But in both cases these are protocol
interactions.
A client's compliance with this protocol can be tested, and the protocol
could reasonably advance to full standard (or not) based on such testing
with multiple client implementations. So I don't understand why BCP is
more appropriate.
(But if that's what IESG wanted to do, I wouldn't fight it. Let's just
try to not let this question delay the document, ok?)
I also believe it would be more confusing to have two documents for
confidentiality assurance level and security directives, because both of
them require the client to disconnect if the requirements aren't met.
But I'll think about that some more. The current document is longer
than I'd like, and there's a tendency for readers to get overwhelmed by
long documents and miss things. But when readers have to read multiple
documents in order to implement changes, it usually makes the problem
worse.
I think we should tease these two things apart into separate
specifications so that it's clear you can have one or the other or both.
The only benefit I can see to that is that server implementors and MSPs
and server implementors wouldn't have to read the CAL document [*],
since that's all done on the user end. Offhand, I don't see why it's
beneficial for an MUA to be able to implement either CAL or security
directives or both. The two features were designed to work together.
[*] except that MSPs would still need to know about CAL for customer
support reasons
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
