Robert Sayre wrote:
Also from the draft:
"At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
security mechanism to guarantee universal interoperability."
I do not think this is a factual statement, at least when it comes to
HTTP, which is where my interest lies. [...]
On the other hand, I've seen with SIP where forcing the working
group to do this has been extremely counter productive. The reason
is that since it was backend loaded, ramming in S/MIME and TLS
was rife with mistakes and in the case of S/MIME was a solution in
search of a problem. Since we're talking about how things actually
turn out from process, it would be good to acknowledge that the
process in this particular case was ultimately counter productive:
instead of taking the time to get security right, we institutionalized
incorrect/non-interoperable behavior.
I seriously doubt that SIP is the only offender here as general clue
as to how to do this right is still arguably lacking, and it most
certainly doesn't get done in a fevered month before last call. IMO,
the process needs to take into account the reality of when we are
trying to graft security protocols onto implemented/deployed
protocols like SIP, SMTP... It's an effort unto itself and needs
to be carefully considered, and hopefully by a group of people
whose goal is to make something that's _useful_ and _interoperable_
rather than just squeaking through the IESG mandated process.
Mike
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf