Subject: Re: [newtrk] Re: IESG comments on draft-ietf-newtrk-decruft-experiment-02.txt

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jan 2006 09:35:34 +0100

Brian, Harald, all,

I've just submitted -03 of this draft which combines the title and
abstract changes with the removal of the additional 2 rfcs Alex
requested, as I heard no objections.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jan 2006 11:04:05 +0100

Let's hope this finishes it.

48 documents to Historic, out of 119 candidates. Most decisions totally 
non-controversial.

March 2004 to January 2006. Two years, a couple of hundred messages. Not 
too many hours of work, I think.

Worth it?

.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jan 2006 12:22:31 +0100

Harald Tveit Alvestrand wrote:
> 48 documents to Historic, out of 119 candidates. Most decisions
> totally non-controversial.
>
> March 2004 to January 2006. Two years, a couple of hundred messages.
> Not too many hours of work, I think.
>
> Worth it?

I would find it more worth it if we can develop a process out of the
experiment.  That should be our next work item.

Eliot
.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Jan 2006 13:48:18 +0200 (EET)

> experiment.  That should be our next work item.

It's hard to estimate the work Eliot did in trying to contact various 
(dead or alive) WGs, RFC authors, etc. -- or did he (I recall hearing 
something about that)?

Regardless, I think creating an (experimental) process would be a good 
next step.  IMHO, also decrufting non-std strack docs should be on the 
table but lower priority.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jan 2006 12:54:52 +0100

> (dead or alive) WGs, RFC authors, etc. -- or did he (I recall hearing

I did some.  The big issue is that many email addresses have changed,
and many working groups have gone poof.  I don't think the process was
onerous.  I also did some nudging to get some updates out there (like
CIDR).  One thing I would suggest is that the IESG look at the remaining
documents and consider getting them promoted (somehow).  I put off that
discussion because I figured this group would have related output.

Eliot
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 Jan 2006 17:46:19 -0600

> discussion because I figured this group would have related output.

Eliot, I would like to see "promoted (somehow)" happen, and maybe happen in 
a way that looks like the way decruft happened (I mean "as a mass movement", 
not "over a period of years").

As best I can tell, the plan behind the three-level standards track was "up 
or out" - either a specification advances or it goes away, with the default 
being "goes away". The current suspended-animation of proposed standards was 
never the plan.

Now that we have conclusively proved that a only relatively small number of 
proposed standards will ever "go away" in my lifetime, is it worth 
re-thinking the default, at least in some cases?

I mean, it's just BARELY possible that advancing RFC 2581 isn't going to 
take out the Internet, since every TCP on earth implements slow start, 
congestion avoidance, fast retransmit, and fast recovery, and maybe this one 
RFC could advance to draft standard even if no one writes up 
interoperability reports?

Perhaps there are others, that we could be equally daring about :-)

Spencer 

.

---

From: David Kessens <[email-masked]>
Date: Wed, 11 Jan 2006 17:06:57 -0800

Eliot,

> discussion because I figured this group would have related output.

While I appreciate your tireless efforts, I would like to make it very
clear that you are here asking the IESG to take on more work then it
currently does.

As most ADs already have more work to act on than time available, this
will mean that you are de-facto requesting us to drop other work. I
believe that it is extremely important that this working group
considers this very carefully and gives the IESG instructions on what
other work should get a lower priority.

As far as my personal opinion, and please forgive me my bluntness, I
believe that this whole effort to reclassify IETF documents, while
well intentioned, equates to paperpushing. Basically, and this stems
from my operational background, my question is whether this
reclassification effort is making any difference in the day to day
operations of the Internet. 

The IETF's mission is, to quote from rfc 3935, to make the 'Internet
work better'. Loading more work on overloaded ADs or more process on
hardworking IETF participants is not going to help to accomplish this
mission. I believe that our best chances for *successful* process
reform are in a review of our processes and to first look for cutting
features in our process that are not in use or that don't pass the
'does this make any difference in the real Internet?' test.

David Kessens
---
.

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Jan 2006 17:15:15 -0800

> 'does this make any difference in the real Internet?' test.

I disagree; IMO, the work this represents helps move the chaff out of
the way so that the wheat - old wheat and new wheat - is easier to find.
Organizing the wheat so it's useful is just as productive - sometimes
moreso - as generating new wheat.

Joe
.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 11 Jan 2006 18:08:21 -0800

Perhaps some work we could take on, that might not be so onorous, would
be to keep track of the email addresses of working groups and technology
experts, even after the working groups are closed.  This could be a
voluntary
process which wouldn't involve the ADs at all. I know the tools group is
currently discussing requirements for better tools to track email addresses
and participants in _current_ working groups, maybe the same information
could be kept for closed ones?

This would also help "make the Internet work better", since often
people have questions or issues that arise well after the WG is closed,
and having contact information maintained would be useful.

Larry
-- 
http://larry.masinter.net

.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Jan 2006 18:18:14 -0800

> operations of the Internet. 

Exactly correct. And nicely said.

The problem with arguments in favor of this work is the tendency to ignore that:

    a) we have never seen a compelling demonstration that the chaff is causing 
Internet indigestion, or

    b) pursuit of this work detracts from other work, as you noted.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: David Kessens <[email-masked]>
Date: Wed, 11 Jan 2006 23:24:07 -0800

Joe,

> moreso - as generating new wheat.

The free market (and open source community as well) is way quicker and
more efficient in determining whether something is historic/obsolete
than the IETF. People vote with their pocket book and simply abandon
the protocol when it no longer makes sense. I see very little value
for us to spend a large amount of time to make a standard officially
historic years *after* it is already widespread knowledge that a
(proposed) standard is indeed historic/obsolete.

David Kessens
---
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Jan 2006 10:11:03 +0100

> (proposed) standard is indeed historic/obsolete.

1) It's not a large amount of time (IMHO). Most important result of the 
experiment.

2) "Widespread" knowledge is not the same as "findable" knowledge.

I've said it before and I'll say it again: Either do this work (and now we 
know what size work it is) or abandon the idea that standards-track status 
will ever be made to conform to reality.

WRT workload on the IESG: I think that for this particular document, the 
IESG has spent more energy (by a relatively large factor) on worrying about 
how much this willl cause extra work for the IESG than it has on actually 
processing the document.

I agree with David that asking the IESG to take on more work (to push the 
remaining docs up the track) is a non-starter. The IESG's job in this 
context is (I think) to make it possible for other people to do the job.

                     Harald

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Jan 2006 11:59:46 +0200 (EET)

On Thu, 12 Jan 2006, Harald Tveit Alvestrand wrote:
> remaining docs up the track) is a non-starter. The IESG's job in this context 
> is (I think) to make it possible for other people to do the job.

I agree with this view.  The more work that we can find non-IESG 
people to do, the better :). If the IESG processes hundreds of 
documents per year, I fail to see how processing one (on decrufting) 
per year (or thereabouts) would be a problem.

On the other hand, in the past people HAVE written "Request to move 
XXX to historic" - documents.  I'd expect that this process could be 
used instead for many of those, so the total number of documents to 
process could be even lower.  Also, each WG might not need to spend 
time arguing whether it's worth the effort to move docs to historic by 
"request to move" RFCs, and could possibly use this process instead.

What could, on the other hand, imply more work for the IESG is pushing 
documents up in the standards track -- but this experiment hasn't 
really been about that (IMHO). (The more work would be caused by 
additional IETF last calls, judging the consensus, evaluating the 
implementation reports, having to read standards track revisions more 
carefully, etc.)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Jan 2006 11:40:23 +0100

> implementation reports, having to read standards track revisions more
And I view this as part of the charter of the IESG, and this is also why
a timeline was established in RFC 2026.  Again, if you want to rewrite
2026 go ahead, but stop ignoring it.

Eliot
.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Jan 2006 09:02:25 -0500

Actually, there are multiple ways in which getting things properly marked 
historic is helpful.

The simplest case is when I have to explain to Marketing / Product 
Management which features we need.  Sure, they look at the boxes out 
there.  They then try to look at all the vaguely relevant RFCs, and often 
ask for almost everything.  Getting the really obsolete ones marked as 
historic will help me explain to them why those are not needed.

A related case is when I try to understand a new and complex aspect.  I can 
usually use the obsoletes / updates information to help figure out what I 
need to read.  But getting some of the clutter marked as historic will 
definitely help.  (And we do presume that our documents are actually for 
folks who are not active in this community.)

In fact, arguing that the "free market" will make this decision means that 
there is actually a barrier to entry for new players in that they have to 
figure out what the "free market" as "decided".  I don't actually think 
that is good for the internet as a whole.

Yours,
Joel M. Halpern

.

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jan 2006 07:52:39 -0800

David Kessens wrote:
> than the IETF. 

As would a free market be quicker/more efficient at deciding what to
standardize. I'd be glad to relieve the IESG of that job too. But as
Eliot pointed out later, both establishing and deprecating standards
seem part of the same job.

Joe

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 12 Jan 2006 10:33:05 -0600

Harald,

> will ever be made to conform to reality.

I would be good either way. If the IETF develops standards, we should take 
the standards process seriously. If the IETF develops specifications, and 
drops its standards track, we wouldn't need to think about standards-track 
status at all.

I am less comfortable with being stuck in the middle ("oh, my gosh. You read 
RFC 2026 and thought that implementing 'standard TCP' was a BETTER idea than 
coding proposed-standard slow start and congestion avoidance?")...

Yes, I do know about TCPM, and that's kind of the point. TCPM happened after 
a discussion on the end-to-end list where we decided that NOBODY knew what 
"TCP" was. If Internet Standard-level documents suggest an answer that is 
actually worse than "we don't know", this is not a good thing.

> context is (I think) to make it possible for other people to do the job.

I agree with Harald agreeing with David (and appreciate David sending his 
note to the list and precipitating the discussion).

Thanks,

Spencer 

.