[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [newtrk] IETF Process discussions - next steps
Eliot,
I specifically do not believe there were any signs of newtrk reaching
a consensus on the first two points you mention and I specifically
do not believe that there is enough interest in the community to
justify a clarification update of 2026.
I wish it were otherwise. I have personally (co)authored several drafts
in this area over the last several years, namely
draft-ietf-newtrk-proposals
draft-carpenter-newtrk-twostep
draft-carpenter-ietf-disputes
draft-carpenter-rfc2026-critique
but without an emerging consensus for specific change we are at the end of
the road.
BTW I have just submitted an update of draft-carpenter-rfc2026-critique
which is somewhat reoriented:
This document discusses how RFC 2026, the current description of the
IETF standards process, operates in practice. Its main purpose is to
document, for information only, how actual practice interprets the
formal rules.
There's a preview at
http://www.geocities.com/be1carpenter/draft-carpenter-rfc2026-critique-02.html
Comments welcome.
Brian
Eliot Lear wrote:
Brian,
Your logic omits two substantial problems that NEWTRK was chartered to
address:
* We are not practicing what we preach. The IESG continues to
ignore and violate Section 6.2 of RFC 2026 by not reviewing the
state of PS and DS standards.
* We again do not practice what we preach when we say that there are
three tracks. Running code largely indicates one.
Hence we need an update to indicate what it is we do practice.
Otherwise, particularly for the first item, people can and should
legitimately ask what *other* requirements the IESG finds inconvenient.
Furthermore, it leaves us open to people coming in and saying, "You
don't follow your own process, so please don't hide behind it when you
take an action I don't like." The IESG must correct this issue.
In the process of doing so, we should recognize that the three step
process is obsolete. Anyone who disgrees with that statement is
ignoring the evidence. Our tradition as an organization is to attempt
to rectify our specifications based on running code. Let us please do
so in this instance.
Finally, you have repeatedly failed to heed my recommendation of letting
Scott simply propose an update to the specification. We as an
organization have trusted him and his words for a long time. We are now
in a debacle because the IESG can't seem trust either this working group
or him. And now we are going around endlessly through process hoops.
To say I am utterly disappointed at where we are would be an understatement.
Eliot
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html