Hi Tim,
At 10:57 10-12-2009, Polk, William T. wrote:
After reviewing IETF Last Call comments on gennai-smime-cnipa-pec, I
have decided to request IESG evaluation for publication as-is in an
Informational RFC.
The IESG sent a notice on October 13 about publication as a Proposed
Standard. Quoting Section 7.1 of RFC 2606:
"To avoid conflict between competing versions of a specification, the
Internet community will not standardize a specification that is
simply an "Internet version" of an existing external specification
unless an explicit cooperative arrangement to do so has been made."
Was an explicit cooperative arrangement made between the Italian
Government and the IETF before the Last-Call was issued?
You mentioned publication "as-is". Does this mean that any change
requested during the Last-Call will not be considered?
It is my judgement that the community does not support progression
on the standards track. Given the level of implementation and
adoption, I think it is definitely appropriate to publish an
Informational RFC documenting their experience. However, the cross
area review prompted by IETF Last Call raised some issues that had
not been identified when this document was discussed in smime.
I haven't seen any public support from the IETF community for the
publication of this document. There hasn't been much discussion on
ietf-smime about the document. I read "documenting the experience"
as also documenting the negatives to avoid repeating the mistakes.
The Gen-Art review mentioned that the draft "has significant open
issues". Quoting from the Secdir review:
"The use of mail headers, particularly from and reply-to seems
likely to require review and discussion in the e-mail community
* I'm not sure this mechanism is consistent with BCP 61 or
the Internet threat model. In particular, section 5 describes
several key threats but does not describe mandatory-to-implement
mechanisms to meet these threats. We'd never accept this from
an IETF working group outside the security area, we shouldn't
accept this from a security area document."
Here are some quotes from Italy:
"The technical details are so complex that very few people understand
them, which, by the way, is one of the reasons why PEC (whose rules
where defined by the Italian law about 5 years ago as a way to go
beyond the limits of normal e-mail services) has gone nowhere in the
market."
"Initially, the Italian government, in its wisdom, decided that everyone
in business and the public sector in Italy was legally obliged to have
a PEC certified email account. A law to this effect was introduced.
Everyone promptly complained."
"A Certified Email Provider shall be a stock corporation having a wholly
paid-up corporate capital of, at least, one million euros."
If by adoption, you are referring to the "one million professionals
have joined in" posta elettronica certificata, you can find some
information about that at
http://www.renatobrunetta.it/2009/12/02/p-a-brunetta-oltre-1-milione-di-professionisti-hanno-aderito-a-pec/
The decree of the President of Italy was published in the Official
Gazette on April 28, 2005 (
http://gazzette.comune.jesi.an.it/2005/97/2.htm ). I hope that the
authors of draft-gennai-smime-cnipa-pec have verified that the
document is in full conformance with BCP 78 and BCP 79.
Alfred mentioned that a *huge* IESG Note would perhaps be appropriate
if the document was published as Informational in the Independent
Submission Stream. I don't think that it is appropriate to have a
lower bar for the IETF Stream.
I would like to see the issues raised in IETF Last Call corrected in
a following standards track RFC, and am interested in opinions on
whether such an RFC should be pursued in the IETF, and what working
groups (if any) might be a candidate for such a project. That was
the original intent of the authors when they first brought their
draft to the smime working group. I should also note that they have
no problem giving change control to the IETF, since that was a topic
of concern during IETF Last Call..
I don't understand the request for publishing this document, then
correcting the issues raised and publishing a standards track
document. Is there an immediate and compelling reason why IETF
imprimatur is required?
If the authors are interested in pursuing the work, they could form a
new working group. Given the amount of implementations claimed,
there should be some companies interested in doing the work. They
might get other people to join as long as the implementors do not ask
for a rubber-stamp of the existing specification. There was another
proposal from the New Zealand Government for a secure mail system.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf