--On Friday, September 17, 2010 10:44 +0200 Alessandro Vesely <vesely@xxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf