For what it's worth, http://www.rfc-editor.org/info/rfc5078 (the first
revision to RFC 3777) was Informational, just tuning the non-normative
timeline to name stuff that hadn't been accommodated, such as
o A few common practices are not accounted for in the Appendix B
timeline [RFC3777]. For example, it is common to allow a week for
notifying unsuccessful nominees before the formal announcement is
made. This is not included in the timeline.
I believe I'm quoting Russ Housley, Gen AD at the time, correctly as saying
"if we can't agree on that one, we can't agree on anything".
After that was approved, we made more significant, but still incremental,
updates to normative text.
So, perhaps draft-kucherawy-rfc3777bis-01 is the bait we stake out this
time, to see what happens to the least controversial proposal possible?
("stuff we've already agreed to, once")
Spencer
On Tue, Sep 16, 2014 at 6:13 PM, Brian E Carpenter <
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 17/09/2014 09:46, Dave Crocker wrote:
On 9/16/2014 2:31 PM, Joel M. Halpern wrote:
And from experiences we all have been through, I would stronglye xpect
even more complex and difficult discussions if we open the document up
to substantive changes.
Taken on its face, this appears to be an argument for never making any
changes to any aspect of IETF infrastructure.
Which I'm pretty sure is not what Joel meant.
I'd rather see a rapid IETF Last Call on draft-kucherawy-rfc3777bis-01,
which is intentionally a no-op in terms of process changes. It could
easily be expedited as an RFC before the next IETF, if anybody cares
that much. Then we can have a managed discussion of the issues and
proposals that Mike has raised, which deserve debate.
Brian