--On Thursday, September 03, 2009 11:55 +0300 Jari Arkko <jari.ar...@piuha.net> wrote:
>... > In particular, when I have been an AD it has always been a > pleasure to work with the RFC Editor, and they have always > made exactly the right decisions. In my honest opinion of > course. And I'd rather count on that and think about ways to deal with any patterns of deviation if they should occur than start devising ways for one stream to tell another one what it must do. > But I did want to bring up a couple of other angles. First of > all, all the streams get their share of garbage. And sometimes > the right decision is to publish the document despite it > having some faults, or at least differences of opinion to > established IETF practice. However, in such cases the notes > that we are talking about really can be necessary (e.g., when > a document redefines RADIUS Access-Reject as Access-Accept, to > cite one real example from a few years back). And that is perhaps exactly an example for the other side. First, it is at the very margin between the "procedural review for conflicts with ongoing IETF work" that both 3932 and 4846 call for and the "technical review" that both documents more or less indicate should be handled on an individual review basis. I suggest that it is not so much a conflict with the ongoing work of an IETF WG, but a flat technical error. The right solution for such errors is to fix them, or at least ask the authors to include a detailed discussion of why the terminology needs to be different, not a "note"... especially, IMO, one that, per the current interpretations of the current RFC 3932, is closer to "nah, nah, we don't like this" than a useful explanation that identifies the specific problem. I believe that, if an ISE were to ignore reviews/input on a subject like that, or fail to push the authors very hard after getting it, we would have a very serious problem on our hands... whether that review came from the IESG, from a single AD, from within some relevant WG, or from a moderately random IETF participant or onlooker. So I don't see that "notes" are the right solution to that problem. At worst, they become a crutch that reduces the ISE's belief that it is the responsibility of the authors and the RFC Editor function to actually get these documents right. > The second point was that in general, human organizations are > prone to occasional failures. I at least prefer designs that > are inherently capable of dealing with such failures (e.g., > appeals path, way to fix a bad decision). We agree about that, which is one of the reasons why institutionalizing the current practice of telling the IESG why comments are being rejected (if that happens) strikes me as a good idea. But, to paraphrase (I think) Joel, I'll prefer to see things work in a way that gets documents improved rather than ones that drop cross-stream notes into them (mandatory or not). And that is especially so after many decades of experience in watching people's eyes glaze over as they notice what appears to be boilerplate and skip it... getting the text right, or getting it to clearly note that there are dissenting views and why, is just a much better way to get the point across than note-inserting. > However, I still > want to see the RFC Editor as a simple journal-like function; > please don't take my comment as an indication that board > members should be selected by Nomcom, publication decisions > should have public last calls or anything like that. We > already have the IETF which runs in a community driven manner. Good. And thanks. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf