Hi John,
At 16:57 15-09-10, John C Klensin wrote:
IMO, the situation with this document illustrates that we still
don't have the disclaimer and level of consensus language that
was adjusted in RFC 5741 quite right (no surprise -- that
document was a huge and, IMO, very useful step). In this case,
there is no specific example in 5741 for "individual submission
to AD/IESG, no WG", and I can't find anything in either the
This begs the question as to what the IETF Stream is for.
announcement or the tracker that indicates that either Dave's
review, or several other comments about this mechanism from
various people with a history in email standards and/or
operations, or even the various comments in the IESG evaluation
record
(https://datatracker.ietf.org/doc/draft-gennai-smime-cnipa-pec/#ballot)
have been heeded.
I am surprised that the IESG approved the publication of this
document given the comments on the Last-Call and the Applications
Area Review which Dave wrote. Email standards have been relegated to
"traditional IETF email" from what I read in the write-up.
Quoting Section 2.2.4 of draft-gennai-smime-cnipa-pec-08:
"Each provider MUST dedicate a special storage for the deposition
of any virus-infected messages encountered. Whether the virus be
detected by the sender's access point or the receiver's incoming
point, the provider that detects it MUST store the mail message in
its own storage, and keep it for 30 months."
And there was a DISCUSS about that:
"I fail to see the usefulness of this mechanism, except perhaps for
hard disk manufacturers. There is a non-delivery message in any case.
But I understand that all this is required by Italian law..."
"you might want to think about how the operators should respond to a very
prolific virus. It is possible that you might see more virus
infected emails in
a single 30 day period than you have the resources to store. What do you do
then?"
While the S/MIME WG apparently looked at this and didn't find
problems, I think it is safe to conclude that the rough
consensus in the email is that the mechanism is really not
workable regardless of whether it can be implemented and whether
the Italian government says that it is required and works.
I would like to hear what the members of the IESG have to say about
the rough consensus on the Last-Call. If I am not mistaken, they
take into consideration the comments made by individuals during the
Last-Call and not those made by the Italian government or any other
government. As the S/MIME WG has not been closed down, maybe its
participants might wish to confirm whether they didn't find any
problems in the document.
While I agree with John Levine that publishing a description of
existing practice is in the community's interest, there is not
an obvious mechanism in RFC 5741 to express the consensus
situation and the email community's conviction that the
mechanism is not satisfactory.
I can understand publishing a description of an existing practice in
the community's interest. But the IETF Stream is not about
rubber-stamping publications from governments or any other
"standards" body. Those of you who have looked up the document
history already know that we cannot say that there is cross-area
review for a specification about email when the conviction of the
IETF email community is totally ignored.
FWIW, while I agree with the "really hackish... not intended to
be used this way" remark quoted above, I think it would be
appropriate for this document to note that the usage is
sufficiently unusual that present or future systems that attempt
to analyze messages for the likelihood of spam or other
obnoxious behavior might, upon seeing it, assign a sufficiently
poor score to prevent direct delivery. I would assume that
would not happen inside Italy if the system is required and
widely deployed, but it would be appropriate to caution others
about the risk that use of the suggested method might cause
effective non-delivery of the message.
I gather that this "hack" has been blessed by the IESG given that it
did not add its usual note when it does not like a document.
The proposed introductory text (see the bottom of
https://datatracker.ietf.org/doc/draft-gennai-smime-cnipa-pec/#writeup)
addresses some of this issue but, IMO, doesn't go nearly far
enough to make it clear that a significant number of experts
consider the mechanism defective and that it is published _only_
to inform the community about an existing practice. IMO,
publication of the document would be far more reasonable if
that were clear or if the 5741 mechanisms were used to clearly
and precisely identify the document's publication and consensus
status.
At a guess, the proposed introductory text is there so that the
DISCUSS position could be changed. I'll highlight some text:
"Since this specification describes existing deployment and implementation,
some issues identified by the community were determined to be out
of scope."
One may wonder why IETF contributions were sought when the
specification only describes existing deployment and
implementation. I gather that alignment with IETF security
terminology is out of scope too.
It is possible that is being done, but there is no evidence of
it in the announcement or in any tracker data I can find.
This document was Last called on October 13, 2009. It was approved
by the IESG in September 2010. Now, if only people did not notice,
we would not need evidence.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf