Re: As Promised, an attempt at 2026bis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Thursday, 28 September, 2006 06:29 -0700 Ned Freed
<ned.freed@xxxxxxxxxxx> wrote:

>> While I agree with that, I suggest that we are in something
>> of a conundrum.  Right now, 2026 is badly out of date in a
>> number of areas.  It reflects procedures and modes that we no
>> longer follow, only a fraction of which are addressed by
>> Eliot's draft. There is general community understanding and
>> acceptance that we are operating, not by the letter of 2026,
>> but by the combination of 2026 and a certain amount of,
>> largely undocumented, oral tradition (I expect to hear from
>> the usual suspects on that assertion, but it is the way it
>> is).  To make things worse, we have some BCPs that
>> effectively amend 2026  but that are not referenced in
>> Eliot's draft -- I've pointed out some of them to him, which
>> I assume will be fixed, but may have missed others.
> 
> If that's indeed the case, the first order of business needs
> to be to document current practice. I see no chance of making
> forward progress on actual changes without first having a
> consensus as to what our current state is.
> 
> We've been in this position many times before when we've taken
> up protocol specifications that have lain fallow for some
> period of time. In several of these cases the exercise of
> getting agreement on what's actually being used uncovered
> basic disagreements about the state of play of things in the
> world that would have made forward progress very difficult. I
> think it is reasonable to believe that this is even more
> important when things shift away from the technical and
> towards the poltical.

I could not agree more.

My comments about breaking the document up so that some things
could be left unresolved were only to suggest a path forward if
Eliot was going to try to resolve and identify current practice
in some areas and not in others and others agreed that approach
was desirable.  I'm not sure that is feasible, but it might be
worth exploring if tackling all of 2026 proves infeasible.  

In either event, I concur with other comments that trying to
update 2026 to document current practice while trying to slip in
a few substantive procedural changes in opens the door to all
sorts of failure modes.

The "current practice" version of the three-step standards
process would be, IMO, to leave the three steps there (we
clearly have them and use them, even if not often) but either
remove the periodic review and timeout provisions or replace
them with some words that indicate that regular review and
advancement/demotion still reflect community desire but that, in
practice, we never do it.  Speaking personally, I could live
with either of those as a description of current status, even
though they seem contradictory, so I see some hope of getting
agreement on some very careful wording.

But a two-step process with new words and threshold conditions
isn't "current practice"; it is a new idea with all of the
difficulties in getting consensus that Keith identified and all
of the risks of inadvertent change that Sam identified.  Trying
to do that as a "current practice, except we ignore some things
that are not and slip a few new ideas in" document seems to me
to be a recipe for disaster or at least for endless wandering in
the weeds.

    john




_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]