John’s description of how things looked to the working group is consistent with
my view as chair of the working group
it was a very frustrating experience
Scott
On Dec 12, 2016, at 10:47 PM, John C Klensin <john(_at_)jck(_dot_)com> wrote:
--On Tuesday, December 13, 2016 11:06 +1300 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
I think this illustrates the dictum that "there is always a
well-known solution to every human problem — neat,
plausible, and wrong." [HL Mencken, 1917]. It's not that it
wouldn't clarify the exact status of certain RFCs - but it
would hardly scratch the surface of the underlying standards
spaghetti.
IMHO, the problem tackled in
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-
04 is too complex to be fixed by simple measures.
It's also worth looking at this (out of date) example:
https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-stdpr
oc-00
Anybody up for newnewtrk?
Alternate proposal: IIR, the IESG never did a write up or
initiated a Last Call on that proposal despite a request from
the WG to do so. They simply announced that they were not
going to consider it, an action that is dubious under RFC 2026
but not prohibited. Some of us who were active in Newtrk
assumed that, if there was a Last Call and fairly clear
community consensus, the IESG would be in an intolerable
position if they decided to advance the document, but that is
just speculation.
As co-author of
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04,
I'd be happy to find time to update references and boilerplate
and reissue it if the community wants to take it up and the IESG
is willing to given it serious consideration, either on the
basis of the Newtrk recommendations or through some restarted
process.
Where I think I agree with Brian is that this is a complicated
issue and that a new rule or required paragraph will make things
even more complicated without improving things.
best,
john