Hi John, I understand your points and somehow agree on some of them. I can try to establish a prioritization if that can help, and certainly I will be happy to keep updating the document if at the end the decision is to keep it in a web page, or just as a live I-D, or whatever else. Regards, Jordi > De: John C Klensin <john-ietf@xxxxxxx> > Responder a: <ietf-bounces@xxxxxxxx> > Fecha: Thu, 19 Jan 2006 22:00:10 -0500 > Para: <jordi.palet@xxxxxxxxxxxxxx> > CC: "ietf@xxxxxxxx" <ietf@xxxxxxxx> > Asunto: Re: I-D > ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt > > Jordi, > > Unlike several others and their comments, there are significant > parts of this I find useful, at least in terms of identifying > issues that should be examined. There are several other parts > of it with which I disagree. And, ultimately, the presentation > of a list of suggestions without prioritization lowers its > utility considerably. On the other hand, I doubt that consensus > even on the list of suggested principles is possible. Consensus > about how they should be prioritized would be more difficult > yet, and consensus among those with significant experience > planning and running IETF meetings would certainly be no less > difficult. > > The difficulty, it seems to me, is the combination between that > problem with claiming consensus and what can and should be done > with the document operationally. It is just my opinion, but I > consider anything whose purpose is to tell the IAD, IAOC, or > IESG (or the IETF or IASA more generally) how to behave > procedurally or decide on things to be completely inappropriate > for publication as an independent submission RFC. If others > agree, then the only way to get this published as an RFC is via > the IESG and some IETF consensus process. > > One possibility is to just leave it as an I-D, updating it > periodically as needed, but keeping it out there as a > perspective that the IAD might consider. That has certainly > been done with some IETF and meeting operational documents in > the past. Another would be to pass it to the IAOC (see note > below) along with a suggestion that they establish a set of > periodically-updated IETF operating procedure notes and put this > (or a modified version of it) into that series. Otherwise... > well, I just don't know, even independent of the aspects of it > with which I disagree. > > I will try to find time to send you a list of particular topic > areas about which we appear to disagree, but I don't consider a > discussion of those specific topics to be appropriate or useful > on the IETF list unless the IESG decides that this document > should be an IETF topic (e.g., via a Last Call for BCP). > > john > > (note: in both the document and some of your comments in the > last 24 hours, I think you've gotten the IAOC (the oversight > committee/ IASA decision body) and IASA (the whole > administrative operation in principle, but, in practice, just > the conceptual realization of the IAOC, the IAD (whom they > supervise), and the set of tasks and those who carry them out > that are supervised by the IAD and/or IAOC directly).) > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf