Hi John/SM,
As I am partially responsible for the final RFC Editor note that was
inserted before the document got approved, I feel obligated to comment
on this.
John C Klensin wrote:
--On Wednesday, September 15, 2010 13:59 -0700 SM
<s...@resistor.net> wrote:
Hello,
At 09:37 08-08-10, Dave CROCKER wrote:
This is a summary review, with a focus on design goals and
systems-level issues.
Based on my reading of the specification, much more in-depth
reviews of this specification are appropriate and required,
to consider the fine-grained details
which could be problematic. However, this deeper review
should wait for resolution of the more basic problems with
the design and specification.
draft-gennai-smime-cnipa-pec-08 was reviewed by Dave Crocker
on August 8, 2010 [1]. I haven't seen any response to the
review.
Although there was strong concerns about this draft during the
Last-Call, the IESG has approved publication. Quoting some
comments made recently by an Area Director:
"I don't think that it specifies well requirements it is
trying to
fulfil and it doesn't use email infrastructure well while
doing that."
And a previous comment:
"This is really hackish. Display names are not intended to
be used like this."
I'll read Section 6.5.2 of BCP 9.
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).
Right.
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
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.
There might be some mis-communication on this and lack of anything in
the datatracker, but feedback was heard by the IESG.
Firstly, based on IETF LC feedback the document status got downgraded
from Proposed Standard to Informational.
Secondly, based on IETF LC I entered a DISCUSS on the document. I did
much deeper AD review that I would have done otherwise. I forced authors
to fixup obvious email related problems (but of course I didn't catch
all of them). And I delayed document publication until a discouraging
RFC Editor note was added.
However I didn't feel that preventing publication of the document was
the right thing to do. I've moved my position on the document to
Abstain, which is just about as strong of a statement on the document as
I think should be done.
Thirdly, Dave's review comments were taken into consideration. The
discouraging RFC Editor note in the document was based on Dave's review.
(We can argue separately if the note is strong enough.)
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.
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.
Indeed.
I would also like to add that if this document were submitted as an
Independent Submission, IESG would have had very little power (or even
no power) to say anything about what is wrong with the proposed
approach. So people should be very careful about what they are wishing for.
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.
Fair enough. I think the most constructive thing to do is to concentrate
on how the discouraging RFC Editor note can be improved/made stronger.
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.
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.
I would be very happy to discuss how the discouraging RFC Editor note
could be improved
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.
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.
Best Regards,
Alexey
---
Internet Messaging Team Lead, IETF Application Area Director,
<http://www.ietf.org/iesg/members.html><http://www.isode.com>
JID: same as my email address
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
