Subject: RE: [newtrk] Re: updated draft on cruft / draft-alvestrand-newtrk-cruft-00.txt

From: <[email-masked]>
Date: Thu, 2 Sep 2004 08:37:57 +0300

Hi all,

> I'll just repeat what I've said before.... if we don't (somehow) move stuff 
> to Historic when it's not being used at all, we should abandon all pretense 
> that we do so.

I agree completely with Harald.  Truth in advertising is important, and we
don't follow our own standards process, I think that there is a credibility
gap.

John

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 2 Sep 2004 02:43:50 -0400

>don't follow our own standards process, I think that there is a credibility

There are many ways in which we do not follow up on our own rules or 
processes, and I think that we should prioritize which ones we fix 
and how we fix them.

There was initially a proposal that the IESG (well, really Harald) 
would form a review team to review the status of every document that 
has been stalled on the standards track for more then 24 months and 
make a quick determination of whether the document was still active 
(in any way) or should be moved to Historic status.

While I didn't see any great value to this task, Harald seemed to 
think it would have some benefits.  He also proved that he could find 
people to volunteer for this task.  While I might have been able to 
think of something more valuable for those people to do with that 
amount of time, the potential negative impact on the standards 
process seemed negligible.  I was slightly concerned that the IESG 
would spend time on this issue (both approving the 'cruft' document 
and approving the proposed actions of the 'cruft' committee) that 
could be spent on something else, but it didn't seem like this would 
use very much IESG time.  So, after convincing myself that the 
original 'cruft' proposal was a mostly harmless effort, I chose to 
ignore it.

I suppose that I should hold all of our efforts to a higher bar and 
ask questions like:  How would this effort help the IETF to produce 
higher quality, more relevant or more timely standards for the 
Internet?  Or at a higher level, how would this benefit the IETF or 
the Internet?  But, I am mostly a live-and-let-live sort, so if 
people feel strongly that some work should be done, I am inclined to 
let them do it unless I know of some reason why it would reduce the 
quality, relevance or timeliness of our standards and/or damage the 
IETF or the Internet. Fighting someone else's idea takes time, so I 
reserve that effort for ideas that I think may have significant costs 
or cause real damage.

The newer proposal is, IMO, much more questionable.  It doesn't only 
suggest living up to the letter of the law by reviewing all documents 
that have been stalled on the standards track for 48 months, it 
proposes that the 'cruft' committee will make a determination 
regarding the suitability of work that is still active (implemented, 
used, etc.), and decide whether or not this work should remain on the 
standards track based on current standardization criteria (such as 
security criteria, etc.).

This type of effort would require a more senior and carefully-chosen 
review committee (not just willing people with adequate care and 
judgement, but people with strong-enough cross-area review skills to 
make such a determination).  In my opinion, such a committee would 
need to be selected through a community-driven process, not just by 
Harald picking some folks with IESG advice and consent.  This effort 
would also consume _far_ more time (for the committee, the IESG and 
_many_ others) than the previous version, because the level of 
decisions that would need to be made by the committe and 
reviewed/approved by the IESG would be much higher, and we are all 
likely to end-up dealing with a great deal of feedback from the 
community regarding whatever choices are made.  Ultimately, this 
might involve IAB team in cleaning up the resulting appeals.  It also 
creates new document classes that would need to be document 
elsewhere, explained to IETF newcomers, etc. creating work for the 
RFC Editor, the IETF EDU Team and others. Also, the potential for 
doing harm to the IETF's reputation and/or the perceived stability of 
deployed technology in the Internet is much higher.

I still see no way that this effort would increase the quality, 
relevance or timeliness of our Internet standards, and I do see some 
ways that this effort could reduce the timeliness of other IETF work 
and/or harm the IETF or the Internet.  Since I see this new proposal 
as quite costly and potentially damaging, I'd like to see some 
correspondingly strong benefit that the IETF is expected to gain from 
following this process.  And, I have said, I don't see that benefit. 
So, it is my personal opinion that we should not proceed with the 
process described in the current 'cruft' document.

What benefits do you see from following this procedure?  If your only 
reason for pursuing this effort is your stated belief that we should 
follow our own rules, why not just change the rules instead?  It 
would take much less time and effort for all concerned to write a 
quick update to RFC 2026 that states that the review of standards 
track documents described in the last paragraph of section 6.2 was 
not found to be useful and is no longer performed.  While I see 
little value to writing such an update, the costs and potential for 
harm are very low, so I would not object to it if someone else wrote 
it.

Margaret

.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Sep 2004 10:35:44 +0200

> I suppose that I should hold all of our efforts to a higher bar and ask 
> questions like:  How would this effort help the IETF to produce higher 
> quality, more relevant or more timely standards for the Internet?  

Higher quality is NOT a goal, IMHO.  More relevant and timely standards is.

> Or at 
> a higher level, how would this benefit the IETF or the Internet?

Right question.  This aids the IESG in allowing things through that 
perhaps are a little iffy in terms of usefulness, without feeling the 
need to have to nitpick to death proposals.  This has happened.

> But, I 
> am mostly a live-and-let-live sort, so if people feel strongly that some 
> work should be done, I am inclined to let them do it unless I know of 
> some reason why it would reduce the quality, relevance or timeliness of 
> our standards and/or damage the IETF or the Internet. Fighting someone 
> else's idea takes time, so I reserve that effort for ideas that I think 
> may have significant costs or cause real damage.

Your view above conflicts with IESG's record and comments from some of 
your peers.  Whether you see it or not, the pressure for perfection is 
there.  This to me is a necessary (but by itself not sufficient) step to 
ease that pressure.

> that have been stalled on the standards track for 48 months

It says no such thing, by the way.  It says that any standard that is 
languishing should get a review, but it doesn't state a time frame. 
Even if a standard goes beyond 48 months it doesn't guarantee or 
necessarily even suggest that the cruft committee review it.

>, it proposes 
> that the 'cruft' committee will make a determination regarding the 
> suitability of work that is still active (implemented, used, etc.), and 
> decide whether or not this work should remain on the standards track 
> based on current standardization criteria (such as security criteria, 
> etc.).

> make such a determination).  In my opinion, such a committee would need 
> to be selected through a community-driven process, not just by Harald 
> picking some folks with IESG advice and consent.

Today an *INDIVIDUAL* can submit a request to have a Standard moved to 
Historic, and the entire IESG would have to review it WITHOUT ANY 
PREPARED ASSISTANCE.  One could inundate you TODAY with those requests 
without any process change and that would bog down the IESG for weeks, 
if not months.  And so we can't clean out the cruft today.

What this proposal buys you is this: reduced overhead of getting rid of 
old stuff through the following

  - an organized review at three levels
     - WG/committee
     - Community (last call)
     - IESG, who can consider summaries of the work as well as whatever
       other outside sources they'd like.

  - no RFC editor action for those standards that are themselves not
    dangerous.

  - A document that indicates dangers a protocol poses when it is in
    fact dangerous.  This does NOT in fact represent a change from
    RFC 2026 process.

And so...

>  This effort would also 
> consume _far_ more time (for the committee, the IESG and _many_ others) 
> than the previous version, because the level of decisions that would 
> need to be made by the committe and reviewed/approved by the IESG would 
> be much higher, and we are all likely to end-up dealing with a great 
> deal of feedback from the community regarding whatever choices are 
> made.

... you've misread the proposal or we've not made intent clear.  There 
is no reason to believe that the IESG needs to spend more time on this 
effort than a ("oh yeah, SLIP is dead. Long live SLIP").  Again, please 
see the presentation I gave at NEWTRK.

>  Ultimately, this might involve IAB team in cleaning up the 
> resulting appeals.  It also creates new document classes that would need 
> to be document elsewhere, explained to IETF newcomers, etc. creating 
> work for the RFC Editor, the IETF EDU Team and others. 

As both Harald and I (repeatedly) wrote on this list, we added the 
additional category based on a request to separate dangerous from simply 
old and crufty.  Neither he nor I are wedded to the idea, and have said 
we would be fine with pulling the new category.

Just to nail this one, I'll submit a new draft in a few days that 
removes this text.

> Also, the 
> potential for doing harm to the IETF's reputation and/or the perceived 
> stability of deployed technology in the Internet is much higher.

The IETF's current reputation within my company (Cisco) is that it's 
quite difficult to get a standard through, that REAL customers have no 
voice within the community, and that we've ossified beyond the point of 
another organization upon which we used to heap scorn.  This was even 
pointed out in a presentation in the last plenary, so it's not just my 
company that has this view.

Eliot

.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Sep 2004 11:53:20 +0200

One last comment:

 > and we are all likely to end-up dealing with a great
> made.  Ultimately, this might involve IAB team in cleaning up the 
> resulting appeals.

The one thing I've learned from lawyers is that the fastest way to be 
sued is to not follow your own documented procedures in a systemic way. 
  One thing I've learned about lawyers is that they have imagination 
when it comes to applying the above.

Eliot
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 2 Sep 2004 07:25:40 -0500

> What benefits do you see from following this procedure?  If your 
> only reason for pursuing this effort is your stated belief that we 
> should follow our own rules, why not just change the rules instead? 
> It would take much less time and effort for all concerned to write a 

I'm sympathetic to almost everything Margaret wrote, but I'm really 
intrigued by the use of the words "quick update" and "RFC 2026" in the 
same sentence.

I can be confused on this - I have been confused on other things - but

o I've heard people say our process RFCs should be like the US 
constitution - changed very infrequently, and

o I'd like to see running code for "quick changes" to "RFC 2026", and 
I'm thinking that RFC 3667/3668 does not qualify for "quick".

I don't care whether we do what we say we do, or change what we say we 
do to match what we do. If I understood JohnL, he was saying that 
these two things should match, not which one should move when they 
don't. I agree that they should match.

Spencer 

.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 02 Sep 2004 10:21:27 -0400

FWIW  (probably not  much in  this crowd)  I think  Margaret has  it exactly
right.  I don't think anyone has given any real grounds for disagreeing with
her.

I'd take it a step further though. 

Any attempt to declare things  "dangerous" would just be a political process
in which members of the committee could reopen any issue where they disagree
with the WG consensus. 

I don't even trust people to  say that something is not used anymore, except
in the  case where that  is completely uncontroversial.  There've  just been
too many cases in which prominent  IESG members have pronounced things to be
"dangerous" and  "undeployable" in spite of  considerable empirical evidence
to the contrary.

One thing  that is clear  from all these  discussions about IETF  process is
that "rough consensus and working code"  is not a good way to make decisions
about IETF process, as (a) there is no way to produce "working code" in that
context, and (b) the IETF contains  few if any subject matter experts in the
area  of  "how  to run  an  organization"  or  "how an  organization  should
communicate clearly to the outside". 

.