Subject: draft-gennai-smime-cnipa-pec-08

From: SM <[email-masked]>
Date: Wed, 15 Sep 2010 13:59:38 -0700

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.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01709.html

---

From: John Levine <[email-masked]>
Date: 15 Sep 2010 21:31:16 -0000

>  "This is really hackish. Display names are not intended to be used 

Given that it's Informational, not standards track, and it appears to
do an OK job of describing the existing Italian setup for certifed
e-mail, it seems to me that it's appropriate to publish it to document
existing practice, even if none of us seem to think that it's very
good existing practice.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Sep 2010 19:57:03 -0400

--On Wednesday, September 15, 2010 13:59 -0700 SM
<[email-masked]> wrote:

>> 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.
> 
> Last-Call, the IESG has approved publication.  Quoting some
> comments made recently by an Area Director:
> 
>   "This is really hackish. Display names are not intended to
> be used like this."
> 

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
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.

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.

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.

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.

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.

regards,
   john

---

From: SM <[email-masked]>
Date: Wed, 15 Sep 2010 21:16:35 -0700

Hi John,
>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.

>(https://datatracker.ietf.org/doc/draft-gennai-smime-cnipa-pec/#ballot)

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?"

>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.

>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.

>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.

>and precisely identify the document's publication and consensus

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 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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 17 Sep 2010 10:44:55 +0200

On 16/Sep/10 01:57, John C Klensin wrote:
> [...] 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.

Well, it is required by law, so one may say it works...  However, the 
I-D only mentions a part of the system, and it says right at the top that

   This document represents the English version of the Italian
   specfications, (http://www.cnipa.gov.it/site/_files/Pec-def.pdf)
   which will be the ultimate PEC reference.

(That "which" seemingly refers to "the Italian specifications" rather 
than "the English version", even if the comma and parentheses that 
precede it might be misleading.)  Some passages differ slightly from 
the Italian version.  For example, there is a section, 8.5 in Italian, 
that briefly describes the content of the "PEC providers directory". 
In the English version, section 4.5, as a note to the scheme, mentions 
that "[t]he data of all PEC providers is encompassed in a [LDIF] 
file".  But how does one become a PEC provider?  I, for one, am not 
entitled to.  In practice, the mechanism describes a private walled 
garden.  Being governmental may make it public, in some sense, but not 
open.

> mechanism is not satisfactory.

+1

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Sep 2010 11:32:11 +0100

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:

>document was a huge and, IMO, very useful step).
>
Right.

>In this case,
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.)

>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.

>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
>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
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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Sep 2010 11:39:57 +0100

Hi SM,

SM wrote:
 [...]

>  "This is really hackish. Display names are not intended to be used 

Well, yes. But my personal bar for publishing an Informational document 
on something which is already deployed, is much lower.

Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Sep 2010 11:03:27 -0400

--On Friday, September 17, 2010 10:44 +0200 Alessandro Vesely
<[email-masked]> wrote:

>> [...] 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.
> 
> Well, it is required by law, so one may say it works...

Yes.  I should have clarified "workable" with some language
about global applicability.  If nothing else, the fact that the
mechanism depends on government-authorized certificate providers
puts us into a space we have visited many times before: getting
such providers recognized across national boundaries requires
treaties or other cross-border arrangements that have repeatedly
failed to come together in a satisfactory way.

> However, the I-D only mentions a part of the system, and it
> says right at the top that
> 
>    specfications,
> (http://www.cnipa.gov.it/site/_files/Pec-def.pdf)
> (That "which" seemingly refers to "the Italian specifications"
> rather than "the English version", even if the comma and
> parentheses that precede it might be misleading.)  Some
> passages differ slightly from the Italian version.

And a document like this is much more satisfactory if it
represents an accurate and exact translation even if the
official version remains the one in the original language.
I'm, of course, not in a position to know whether the
translation is accurate or not, but I believe that more effort
and review was invested in the translation accuracy and
completeness question , e.g., RFC 5830-5832 than in this
document.   In any event, the process followed for 5830-5832
clearly does not require any IETF community consensus at all.
The only thing that is required is an accurate statement about
what the documents are and consensus within the Independent
Submission Stream process that the information they provide is
potentially useful for the community.

Part of the difference is historical and should, IMO, cause us
to ask questions that really have little to do with this
document: What became 5830-5832 were submitted to the
Independent Stream for publication and submitted exactly as a
translation of some relevant GOST standards for the information
of the portion of the community who might find those standards
less accessible in their original, Russian, forms.  This
document, as I understand it, was submitted to an IETF WG with
the intention of developing an IETF standard with it as a base
(note that involves handing over of change control and that some
changes from the Italian original were to be expected).  The WG
didn't want to put it on the Standards Track, so it ended up in
an in-between state as a document that doesn't have IETF
consensus that it should be Recommended for others to implement
but that, assuming your analysis is correct, has departed
someone from the original specification (by omission if not by
actual differences) and hence does not completely represent that
existing practice.

Possible fine-tuning of the text aside, I see far more problems
in the way we decide how documents like this should be published
than I do in the document or its publication.  I continue to
believe that publishing it (and ones like it) is appropriate.

>  For
> example, there is a section, 8.5 in Italian, that briefly
> describes the content of the "PEC providers directory". In the
> English version, section 4.5, as a note to the scheme,
> mentions that "[t]he data of all PEC providers is encompassed
> in a [LDIF] file".  But how does one become a PEC provider?
> I, for one, am not entitled to.  In practice, the mechanism
> describes a private walled garden.  Being governmental may
> make it public, in some sense, but not open.
> 
>> 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

Again addressing that broader question, it seems to me that
situations of this type are going to arise as long as we permit
protocol specifications to be published in the IETF Stream (and
without WG endorsement as part of that WG's program of work)
purely because they represent existing practice or other
standards. We have mechanisms for handling such documents via
the Independent Stream, at arms-length from IETF processes,
streams, and endorsement.  I believe those ISE-based mechanisms
are satisfactory and have been demonstrated to work well but, if
there are problems I don't know about, we should look at them
and fix them, not use an alternate mechanism that is, IMO, less
well-suited to the situation.  I would think that, in general,
the IESG should favor such a split in responsibilities and
publication streams because it would reduce both their workload
and the need to invent separate review processes and then get
into the middle of this sort of debate.  But there may well be
other considerations that I'm not seeing clearly.

    john

---

From: SM <[email-masked]>
Date: Fri, 17 Sep 2010 11:10:04 -0700

Hi Alexey,
At 03:32 17-09-10, Alexey Melnikov wrote:
>There might be some mis-communication on this and lack of anything 
>in the datatracker, but feedback was heard by the IESG.

According to the write-up, the issued identified by the community 
were determined to be out of scope.

>Firstly, based on IETF LC feedback the document status got 
>downgraded from Proposed Standard to Informational.

The question of whether the IETF Last Call was appropriate has not 
been answered.

>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.

I don't have any problem with the level of review which you did.  You 
probably did more work than what would be expected on an IESG evaluation.

According to the write-up, the draft was reviewed and discussed on a 
WG mailing list.  You mentioned asking the others to fixup obvious 
email related problems after the WG discussion.  If there were still 
obvious email related problems, I conclude that the level of review 
performed on the WG mailing list was inappropriate.

>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.

Noted. :-)

>discouraging RFC Editor note in the document was based on Dave's 
>review. (We can argue separately if the note is strong enough.)

Ok.

>Independent Submission, IESG would have had very little power (or 
>even no power) to say anything about what is wrong with the proposed 

If this document was submitted as an Independent Submission, it would 
not be in the IETF Stream and it would not be the IESG's problem to 
solve.  John Klensin already mentioned RFC 5830-5832.  If I recall 
correctly, that was done because of a "RFC Required" code-point assignment.

>I would be very happy to discuss how the discouraging RFC Editor 
>note could be improved

Do we have to discuss about why we should not fall for the "rough 
consensus and running code" sound bite? :-)

At 03:39 17-09-10, Alexey Melnikov wrote:
>Well, yes. But my personal bar for publishing an Informational 
>document on something which is already deployed, is much lower.

At a higher level, I agree with you.

Regards,
-sm