--On Friday, September 17, 2010 10:44 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
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...
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
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.
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
situation and the email community's conviction that the
mechanism is not satisfactory.
+1
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf