substantive review: I think that Brian has pointed out a number of areas where, if we were to produce a revised 2026, work needs to be done and I think that some number (but by no means all) of his suggestions are good, but 1/ I think a delta of this complexity makes the result unreadable - a new version of 2026 would make far more sense 2/ I do not think we are remotely ready to produce a revised 2026 (no matter how much I would like to) process- and discussion-wise that said, some notes as if this might move forward I'm not sure that tweaking STD is enough of a problem to fix - STDs are mostly ignored and thus do not get in the way re expired IDs: see, for example http://tools.ietf.org/id/draft-bradner-pbk-frame-00.txt i.e, "expired" IDs are available through tools.ietf.org (a good thing in my mind) but confuses the suggested text changes TS vs AS - it would be good to say that a TS can include an AS - but I'm not sure one needs to do much more than that I'm not sure much needs to be done in a delta document about requirement levels other than mention RFC 4897 renaming the standards levels a bit of history the first place I found that lists the standards levels is RFC 1083 (Dec 1988) - that lists "Proposed Protocol", "Draft Standard Protocol" and "Standard Protocol" "Proposed Protocol" switched to "Proposed Standard Protocol" in RFC 1140 (May 1990) The current usage (dropping "protocol") was established by the time that RFC 1310 was published (March 1992) so we have been using basically the same names since 1990 - I'd want to see a very good reason to change names with that amount of history behind them - and I do not see it here - I do think that we have issues with the 3-level process but tweaking the names in this way would: 1/ confuse 2/ not prevent deployment at the first IESG-approved stage (since we often get deployment at the Internet Draft stage) re: interoperability requirements - Brian details some real issues here and having a quick punt to the IESG to say what it mans may not be a bad idea but this is something that may deserve a separate document because the details of interpretation will change from time to time - and its easier to update a stand alone doc re: informational RFCs - proposed addition makes sense re - non WG. sponsored info & exp RFCs - I do not like this process anyway when it is uses as a way around getting a nasty (in some people's minds) IESG note on their RFC (which can happen if it goes through the RFC Editor) - I'd rather this escape route were closed and the IESG note made more factual and less something that an author would want to avoid - if the path involves real IESG review then it would be good to note that in the RFC (and note the same in wg info & exp RFCs) re: stale proposed & draft standards - something like what Brian proposes makes sense re: appeals kickoff - if it applies to "any decision whatever" then how about document editor decisions? (document editors are not appointed by the IESG) or decisions by the IETF Trust or IAD (also not appointed by the IESG) _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf