Re: Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]