--On Wednesday, August 12, 2015 13:27 +0100 Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > To clarify: I don't think RFC20 is a precedent for saying > yes to this status change and the above wasn't intended to > imply that. The only precedent I think we get from RFC20 is > that the argument "that text is old" is not *by itself* > reason enough to say no to the status change. That is fair. I read it as saying something more like "RFC 20 sets the precedent for moving almost anything, of any status, onto the standards track (or BCP), with only a Last Call and note in the tracker". As you have gathered, I interpret the RFC 20 experience much more narrowly and, in particular, see "move things from one category to another" as potentially different from "assign a category to something previously listed as 'unknown'". From my point of view, one way to avoid removing that paragraph would be to clarify what you think the precedent is and the above is fine. On the other hand, given that the IESG, with sufficient community consensus, can change or make exceptions to almost anything, I'm not sure your claiming precedents is really helpful. On the other hand, if you want to cite something, Section 2.2 of RFC 6410 makes it quite clear that reclassification of a document, at least from Proposed Standard to Internet Standard, is permitted without a new RFC being required. I think extrapolating from that to BCP is at least as reasonable as extrapolating from the somewhat special case of a previously "unknown" status spec like RFC 20. Neither is really a precedent for a change from Informational to anything else or from something else to BCP. > As far as I know there aren't any other status changes that > provide us with useful precedent here, but I could be wrong > on that. See earlier notes. Several moves to Historic and, I think, at least one exercise of the Proposed-> Internet Standard transition without issuance of new RFCs. > So we could modify or remove that paragraph fairly easily > I think. (Mind you I'm also not getting why that is an > important change to make.) See above. My concern is about claiming a precedent that could be too broadly interpreted and that would then get us in trouble later. Personally, I'd be happy if you said "this is an unusual action, but circumstances seem to justify it and it is generally consistent with things we do by exception as long as community consensus is present". If you need precedent or authorization for that, Section 9 of RFC 2026 seems quite clear to me. > If nobody suggests an alternative, or to keep it, I can > remove it. (Might be better done in a week or so, around the > middle of the LC in case there are other accumulated changes.) Ack. best, john