Subject: [newtrk] BOUNCE [email-masked]: Non-member submission from [The Grouch <[email-masked]>] (fwd)

From: "Lucy E. Lynch" <[email-masked]>
Date: Tue, 29 Jun 2004 09:16:24 -0700 (PDT)

sorry - lost in the spam filters!

Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
llynch  @darkwing.uoregon.edu		(541) 346-1774/Cell: 912-7998

---------- Forwarded message ----------
Date: Sun, 13 Jun 2004 19:09:21 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from
    [The Grouch <[email-masked]>]

Date: Sun, 13 Jun 2004 16:17:33 -0700
From: The Grouch <[email-masked]>
To: New Track <[email-masked]>
Subject: Review - draft-black-newtrk-proposals-00
Message-ID: <FB8E0265E5A7AC98F08BF8A9@CF10DEC7E73AECE68A7FF96E>

((Note - this message is sent from someone who's trying to act in the role
of a WG participant. Name at bottom of message.... From: address set to
emphasize the hats I'm not wearing....))

This is a metacommentary, since draft-black-newtrk-proposals is itself
intended to be commentary on the proposals..... so a lot of the comments
are about things I'd like to see in such a commentary....

- why the name? why not draft-newtrk-proposals?

- as is usual in these discussions, I challenge the objectivity and
testability in the sentence "Objectively, over time, the IESG has raised
the bar for the publication of Proposed Standard documents". It is
impossible to even discuss this without giving a more precise definition to
"over time", and I believe that over the last 2 years (the longest period
where I trust my memory), the level has been reasonably constant.
If "Objectively, over time" is replaced with "A number of people have
observed that over the last 10 years", I won't challenge that.

But that's me being backward-looking. It doesn't change the perceptions of
what we can do in the future.

- irritation on format: I wish Appendix 2 had been spun off as a separate
document, and that the lengthy quote from RFC 2026 had been left in 2026.
That would have the effect of focusing the document on its current real
content: section 2.

- missing goals/metrics section: I find no placeholder in the document that
is to be filled out with metrics against which one can measure the success
of the standards track. Such a section would logically belong between
sections 1 and 2, and would contain things like:

  * Increase the interoperability of implementations of new
    protocols on the Internet (how to measure?)
  * Shorten the time from "adopted idea" to "stable spec" for
    protocols from 2 years to 1 year (?)
  * Reduce the number of man-hours required to document
    interoperability and formally acknowledge that it exists
    (no idea of what to put in the "from" and "to" fields....)

I don't think that we have consensus on the metrics yet, but it seems like
a good idea to have that at some point....

- missing discussion of motivation: I don't think we understand that much
of what motivates people to work on IETF protocols. But the question of
whether we can get people to do the work of "pushing things up the track"
or "revision in light of experience" is critical to whether they will
succeed or not. So some text (or a placeholder saying "I wish we had some
text about this) would be a welcome addition to the document.

That's for the general document. Now to the proposals
-----------------------------------------------------

2.1 Make the current system work

I think this should have references to draft-alvestrand-newtrk-historical,
since it can be seen as trying exactly this. They also point out some of
the costs that follow from trying to do so, which I think is valuable for
the discussion. I believe the cost for pushing things up the track is even
higher than the cost of kicking them off it.

2.2 Prune

The section should mention the issue of "documents stuck in Proposed" for
one reason or another. Apart from that, it's a simple overview.

2.3 Slash and burn

draft-loughney-what-standards and draft-klensin-newtrk-antiques could be
mentioned here as specifying something resembling such a registry. However,
I believe that the idea of a registry is at least as separable as the
snapshot idea - it could be used as a supplement to an one-level, two-level
or three-level process.

2.5 Snapshot

As for the registry, this is an idea that can go together with multiple
other ideas. Perhaps we should group registry and snapshot into a separate
section called "new instruments", and use the current section 2 for only
"complete" solutions?

The description seems thorough.

It's hard to disagree with section 3, but section 4 may note that security
requirements currently seem to be the source of the most conflicts over
whether a specification is "good enough", so we must expect that a change
in requirements criteria *will* have a security impact on the Internet.

I'll leave the review of appendix 2 for another time.....

                     Harald Alvestrand

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