Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
I agree with Sam that it might be a sensible modification of the existing process. However, it is irrelevant to the current discussion since the IESG is not at current permitted to make such a statement. The main argument against modification might well be the very fact that it would allow appeals of this type. On Thu, Mar 11, 2010 at 5:18 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I agree with Sam, for cases which would otherwise result in an endless DISCUSS - although normally I'd expect the argument to be complex enough that a separate RFC would be needed to explain the dissent. Brian On 2010-03-12 09:58, Sam Hartman wrote: Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Andrew Well, ok, and yes it probably would be a violation. But to Andrew defend the appelant, there might be a serious (though in my Andrew view totally wrong) point in the appeal. For what it's worth, I think it is entirely reasonable for the IESG to add text raising technical concerns to a consensus document. The IESG note, unlike the rest of the document reflects IESG consensus, even in cases where the document is intended to reflect IETF consensus. Here's a case where I think it would be entirely appropriate for the IESG to do so. The current process--both internal IESG procedure and RFC 2026 requires some level of agreement from the IESG to publish a document. If we had a case where it was clear that there was strong community support for something that the IESG had serious concerns about, I think it would be far bettor for the IESG to include its concerns in an IESG note than to trigger a governance problem by declining the document. Another option also open to the IESG would be to write up its concerns in an informational document published later. Without knowledge of specifics I cannot comment on which I'd favor. I have not read the current appeal and doubt that adding an IESG note is the right solution to an appeal on technical grounds about a consensus document. I simply don't want a legitimate case where adding an IESG note to come up years later and people dig through this discussion and find no objections to the claim that adding such a note would be a process violation. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
From RFC 2026 At all stages of the appeals process, the individuals or bodies responsible for making the decisions have the discretion to define the specific procedures they will follow in the process of making their decision. Suggest that before anyone suggests modifying process they consider the fact that the reason we have an appeals process is to be able to obtain insurance. There are good reasons to tie the IESG hands at certain points in the process. Endless DISCUSS is not permitted by RFC 2026: The IESG is required to deliver a timely decision. If one IESG member was using DISCUSS as a filibuster the process document makes clear that it is the IESG rules that have to bend to meet the requirements of the process document. On Thu, Mar 11, 2010 at 5:18 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I agree with Sam, for cases which would otherwise result in an endless DISCUSS - although normally I'd expect the argument to be complex enough that a separate RFC would be needed to explain the dissent. Brian On 2010-03-12 09:58, Sam Hartman wrote: Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Andrew Well, ok, and yes it probably would be a violation. But to Andrew defend the appelant, there might be a serious (though in my Andrew view totally wrong) point in the appeal. For what it's worth, I think it is entirely reasonable for the IESG to add text raising technical concerns to a consensus document. The IESG note, unlike the rest of the document reflects IESG consensus, even in cases where the document is intended to reflect IETF consensus. Here's a case where I think it would be entirely appropriate for the IESG to do so. The current process--both internal IESG procedure and RFC 2026 requires some level of agreement from the IESG to publish a document. If we had a case where it was clear that there was strong community support for something that the IESG had serious concerns about, I think it would be far bettor for the IESG to include its concerns in an IESG note than to trigger a governance problem by declining the document. Another option also open to the IESG would be to write up its concerns in an informational document published later. Without knowledge of specifics I cannot comment on which I'd favor. I have not read the current appeal and doubt that adding an IESG note is the right solution to an appeal on technical grounds about a consensus document. I simply don't want a legitimate case where adding an IESG note to come up years later and people dig through this discussion and find no objections to the claim that adding such a note would be a process violation. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
On 3/11/2010 9:16 AM, Andrew Sullivan wrote: As near as I can tell, that says that it is _not_ an appeal of the document set itself. Let us consider careful this sentence. Andrew expended substantial time an energy to read and analyze the appel. For all that, he is still left having to make guesses about the core aspects of the appeal's nature. Andrew has good command of English and is a diligent guy, so we cannot dismiss the exercise having been beyond his capabilities or as due to his having been sloppy. Again, I will contend that this is not a reasonable burden for IETF management, or the IETF community. It must be the work of an appellant to place before the IETF an appeal that is clear and concise. That's not an onerous burden. d/ ps. Based on the follow-up postings, my note here might be viewed as what sales folk call selling past the sale, but I thought that Andrew's work provided remarkable substantiation of the problem that it was worth explicitly noting it for the record. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
Andrew, Thankyou for spending time on this. On 2010-03-12 06:16, Andrew Sullivan wrote: ... It is instead an appeal that the documents were not published with disclaimers attached. Interesting. Since we're being legalistic, all IETF documents carry the standard disclaimer (by reference in recent RFCs) which says, among other things: ... DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Well, ok, and yes it probably would be a violation. But to defend the appelant, there might be a serious (though in my view totally wrong) point in the appeal. I'm extremely uncomfortable speculating about what M. Morfin really means (yes, I am entering that in the understatement of the year competition), but I think his substantive point is that the IDNA2008 use doesn't provide regular, non-technical Internet users with a complete, totally functional, rich experience that is unsurprising to them given their regular language. I think the point about disclaimers is that he thinks the publication premature, given that it can't provide that experience. So the documents should come with a warning that more work is to be done. That's more specific than the general and standard disclaimer. As I argued previously, such a view gets almost completely wrong the way the IETF standards process works. If that were the bar we had to jump, nothing would ever go out without such a warning. Soon we'd be plastering our RFCs with warnings about the hot drink inside, and so on. Maybe we'd even have to warn people about the possibility of cookies causing complaints on mailing lists. One almost anticipates the day when each addition to the RFC series is actually just new boilerplate, and nothing else. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Andrew Well, ok, and yes it probably would be a violation. But to Andrew defend the appelant, there might be a serious (though in my Andrew view totally wrong) point in the appeal. For what it's worth, I think it is entirely reasonable for the IESG to add text raising technical concerns to a consensus document. The IESG note, unlike the rest of the document reflects IESG consensus, even in cases where the document is intended to reflect IETF consensus. Here's a case where I think it would be entirely appropriate for the IESG to do so. The current process--both internal IESG procedure and RFC 2026 requires some level of agreement from the IESG to publish a document. If we had a case where it was clear that there was strong community support for something that the IESG had serious concerns about, I think it would be far bettor for the IESG to include its concerns in an IESG note than to trigger a governance problem by declining the document. Another option also open to the IESG would be to write up its concerns in an informational document published later. Without knowledge of specifics I cannot comment on which I'd favor. I have not read the current appeal and doubt that adding an IESG note is the right solution to an appeal on technical grounds about a consensus document. I simply don't want a legitimate case where adding an IESG note to come up years later and people dig through this discussion and find no objections to the claim that adding such a note would be a process violation. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
I agree with Sam, for cases which would otherwise result in an endless DISCUSS - although normally I'd expect the argument to be complex enough that a separate RFC would be needed to explain the dissent. Brian On 2010-03-12 09:58, Sam Hartman wrote: Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Andrew Well, ok, and yes it probably would be a violation. But to Andrew defend the appelant, there might be a serious (though in my Andrew view totally wrong) point in the appeal. For what it's worth, I think it is entirely reasonable for the IESG to add text raising technical concerns to a consensus document. The IESG note, unlike the rest of the document reflects IESG consensus, even in cases where the document is intended to reflect IETF consensus. Here's a case where I think it would be entirely appropriate for the IESG to do so. The current process--both internal IESG procedure and RFC 2026 requires some level of agreement from the IESG to publish a document. If we had a case where it was clear that there was strong community support for something that the IESG had serious concerns about, I think it would be far bettor for the IESG to include its concerns in an IESG note than to trigger a governance problem by declining the document. Another option also open to the IESG would be to write up its concerns in an informational document published later. Without knowledge of specifics I cannot comment on which I'd favor. I have not read the current appeal and doubt that adding an IESG note is the right solution to an appeal on technical grounds about a consensus document. I simply don't want a legitimate case where adding an IESG note to come up years later and people dig through this discussion and find no objections to the claim that adding such a note would be a process violation. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
