--On Monday, 22 September, 2008 11:40 +0200 Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> wrote: > Hi John, > > I have tried to write a statement that allows the IESG to use > common sense. However, the problem I have seen several times > when the IESG tries to use common sense in issues that comes > up regularly is that some people complains about not knowing > about this and that we can't enforce it because there are no > written rules. Magnus, Spencer's note does a fairly good job of summarizing most of my concerns. Let me address a few things that he does not, but please read his note along with this one. First of all, I see a huge difference among three categories that your note, and the draft statement, seem to roll together: (i) The class of things that the IPR WG might think of as "code", here including MIBs, configuration files, tables, and code excerpts that implementers are expected to copy, either verbatim or with simple, template-like, modifications. (ii) Test scripts and similar things, written in a form in which they will obviously be copied, perhaps modified slightly, and then executed repeatedly (with fairly high multiples of "repeatedly"). (iii) Simple, illustrative examples that, even if executed, are not likely to be executed more than once by a given implementer. One might draw the boundaries in other ways, but they are different enough that saying "the cases in the first group are harmful, therefore the cases in the third are harmful enough to require extensive rules" is just bogus. > Thus the draft statement is an attempt to > satisfy several different requirements: > > - Provide motivation why there are issues with examples > - Provide some guidance on how to handle situations which > aren't clear cut > - Be clear that this is something IESG do look at and authors > need to think about. > - Prevent complaints about late surprise and heavy hands when > we are applying what we think are common sense. One can make extensive rules or one can apply common sense. The pushback when this came up was because of a perception that common sense was _not_ being applied. This document does not somehow instantiate common sense, what it does it to transform the rigid rule that was undocumented into the rigid rule that is. And, while "undocumented" makes things much worse, the real objection is to the rigid rule, especially against the backdrop of a concern that it will take far too much time and energy to get such a rule right and that there will _still_ be exception cases. In general, any time you write a page of rules and case analysis when a sentence of guidance would do, I (and perhaps others) are going to object. Keeping things simple is of significant and substantive importance. > If you have a suggestion on how this better can be written up > I am interested. Yes. I've made that suggestion several times. It was actually in my previous note (see Pasi's comment). Don't try to delineate every case and build a rule on that basis. Just indicate that you expect safe/protected/reserved names (or codepoints or other identifiers), to be used, especially when they occur in situations in which copying and repeated execution are likely and that, if the author believes otherwise, that must be explained in a comment (in the document or wherever else you would like it) that is clear enough that the community can comment on the justification during Last Call. If you want to say something about the difference between new and revised documents, I would, based on recent experience, appreciate it, but I don't think even that is necessary. > When it comes to harm, I think we clearly have some cases > where examples can have really serious effects, configurations > being what comes to mind. When it comes to email addresses > they are primarily an annoyance, but I think any one of us > would be might irritated to learn that the suddenly started > receive spam in large quantities because someone published > their address in example in an internet draft or RFC. I think > that this is as far as this goes and something any contributor > to the IETF unfortunately have to pay for their contribution > in an open organization with open access to its documents. See Spencer's note about spam and the comment above about conflating "configurations" with "email addresses in a purely illustrative example". regards, john _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf