Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..

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

 




--On Tuesday, 22 January, 2008 12:03 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:

> On 2008-01-22 11:24, Eric Rescorla wrote:
>> As a procedural matter, I agree with Scott and John. This
>> document should not be considered for advancement at this
>> time nor until such time as there is real evidence of
>> widespread consensus.
> 
> Actually, I agree too, but I also agree with Russ that the
> discussion needed something noticeable to trigger it.

Brian,

I feel so strongly that it is inappropriate to try to use a Last
Call as a means to stimulate community discussion and interest
on this document that it is hard for me to comment
substantively.  I have even found myself speculating on whether
an appeal is in order (because a Last Call is an IESG action,
such an appeal is clearly possible procedurally).

However, one general observation...

>> As a substantive issue, renaming PS and DS to Preliminary
>> and Deplyable strikes me as a terrible idea. Whatever the
>> merits of the current names, they are the ones we have and
>> changing them now will only create confusion. Deployable
>> is a particularly bad choice since PSs are regularly
>> deployed.
> 
> I will listen to the consensus view on this, of course.
> I think we have to recognize that the original roles
> intended for PS and DS have been changed in practice,
> and that may be hard for newcomers to appreciate.

I think we all recognize that.   But subtle changes in
terminology will tend to confuse everyone rather than help.
Many newcomers and many of those who have been involved for a
longer period will  encounter both sets of terminology and will
wonder if something has actually changed or if we are just
playing with words.  Others will encounter only one and make
whatever assumptions they make.

In retrospect, I think we made a serious mistake when we started
using "standard" and "proposed" as part of the same phrase.  As
Scott pointed out, it is a little late to try to change that
now.  In an odd way, it has worked to our advantage: we don't
hear "you shouldn't use that because it isn't a Standard" nearly
as often as we might had we chosen terms for PS that don't
involve the term "standard" at all.

I certainly agree that 2026 needs significant work.  I agree
with the comments of several others that we need to revise it
and, probably, divide it into pieces in the process rather than
working on a patch document.   But therein lies the main problem
I see with your draft: it tries to patch and push little changes
through instead of addressing issues head-on.    

This terminology change is a good example.  While we may differ
on whether it needs to be fixed (and when) and what the fix
should be, I believe there are very few people in the community
who believe that the maturity levels in 2026 reflect both
current reality and what, given current reality, we would like
the levels to be and represent.  While consensus probably
extends that far, recent years have seen a large number of
attempts to actually change things.  We've had proposals for one
step and for two, proposals to change the way we think about
things by bundling the documents and associating the concept of
"standard" with the bundles rather than individual maturity
levels, at least one proposal to change how we number and when,
and so on.  While the reasons differ, the thing that all of
those proposals have in common is that they didn't go anywhere.
It seems to me that trying to bypass whatever perceived problems
stimulated those proposals by tweaking terminology is a waste of
energy at best.

    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]