Subject: [newtrk] A few things I would like in a WGS

From: "Christian Huitema" <[email-masked]>
Date: Tue, 10 Feb 2004 09:29:47 -0800

In order for a WGS snapshot to make sense, I believe that there are a
few key points that are required:

1) The elevation of status from draft to WGS should occur strictly
within the WG. 

2) The WGS shall be "more durable" than a simple draft.

3) The document name shall clearly indicate a different status than
"just another draft".

We have debated many times whether the "consensus call" for a WGS should
include just the WG or more than the WG. Keith put up a strong argument
for peer review prior to publication, and I believe nobody disagrees
with the need for some amount of peer review. However, it is entirely
possible to perform a reasonable amount of peer review inside a WG. IETF
working groups are open, so anyone who really cares can in fact
participate to the review. Besides, we already have a process that
guarantees IETF-wide peer-review: this is what we get when we progress a
document to PS. If we want something lighter weight than PS, and I
believe we do, then the review process should be contained within the
WG.

Another aspect of the debate is whether the WGS shall be an archival
document or just another draft. On one extreme, some would want the WGS
to be pretty similar to an experimental RFC; but then, why bother? We
already have a way to publish experimental RFC and later publish a
revision as PS. On another extreme, some would want it to be just
another draft, with a nice commentary on the WG page. But doing that
does not meet the snapshot requirement, because drafts can be superseded
by other drafts at any time. Today, once draft-12 is published, draft-11
ceases to be officially available. The solution is probably to guarantee
that a snapshot will remain available at least until another snapshot is
adopted, or the specification is published as an RFC, or the working
group is disbanded. The snapshot should not disappear automatically
after 6 months, and it also should not disappear automatically after the
publication of another draft.

If we want to have a different expiration rule than ordinary drafts, we
probably need a different naming convention, if only to facilitate the
work of the secretariat. A naming convention also has the benefit of
being outwardly visible, so third parties can immediately differentiate
between a random draft and a document that has at least some consensus.
In practice, that could be as simple as a different draft suffix. After
consensus, a WG chair would ask to re-publish a draft with a new suffix,
e.g., the chair of the "wurtzel" WG would ask to re-publish
"draft-ietf-wurzel-rabbit-03" as "draft-ietf-wurzel-rabbit-wgs01.txt".
Indeed, the details of such systems should have to be worked out by the
secretariat.

-- Christian Huitema

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

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 10 Feb 2004 10:44:17 -0700 (MST)

On Tue, 10 Feb 2004, Christian Huitema wrote:

> ...
> The solution is probably to guarantee that a snapshot will remain
> available at least until another snapshot is adopted, or the
> specification is published as an RFC, or the working group is
> disbanded. The snapshot should not disappear automatically after 6
> months, and it also should not disappear automatically after the
> If we want to have a different expiration rule than ordinary drafts,
> we probably need a different naming convention, if only to
> facilitate the work of the secretariat.

How about making _all_ drafts permanent? Disk space is cheap.
Historical record may be priceless. Many expired drafts are already
permanent due to archives outside of IETF control.

I suspect this have been discussed before, but I quick check did not
reveil anything useful; please point me to a good authoritative answer
if one is already available.

Alex.

P.S. WGS tag/state should be automatically extractable/detectable, of
     course, but changing the naming scheme for such a tag seems to be
     not worth the trouble of breaking existing software like xml2rfc.
     IETF web pages can index or even render WGSs differently.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Feb 2004 12:58:54 -0500

> possible to perform a reasonable amount of peer review inside a WG. 

In theory yes.  In practice there have been numerous counterexamples that 
illustrate that it is highly improbable that a WG will do a good job of
accepting input from those viewed as "outsiders" if that input would cause
the WG to have to make significant changes.

> IETF working groups are open, so anyone who really cares can in fact
> participate to the review.

...and be disregarded by the WG.  I've seen it happen far too many times.
This is the rule rather than the exception.

This "openness" is somewhat of a myth.  In practice, WGs are "open" only
to those who have the time and energy and funding to participate actively 
in the group's conversations (including all face to face meetings) from
start to finish.  This makes WGs reasonably accessible to those in the
directly affected industry, and somewhat accessible to interested parties 
who have a substantial direct interest in the technology being worked on
by the group.  But it makes WGs inaccessible to those who are affected
by the group's output but who don't have the time/energy/funding to keep
actively participating in the group because their interests are peripheral
to the core interests of the group.

> Besides, we already have a process that

I think you have that exactly backwards.  The goal isn't to have a lighter 
weight way of getting endorsement for a document and therefore making PS 
less relevant.  The goal is to make it possible to get to PS more quickly.
Actually the goal is to make it possible to get to DS more quickly (meaning
that there has been interoperability testing) without the document 
languishing at PS.  

Keith
.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Feb 2004 08:42:15 -0800

Christian,

CH>  The snapshot should not disappear automatically
CH> after 6 months, and it also should not disappear automatically after the
CH> publication of another draft.

good point.

CH> "draft-ietf-wurzel-rabbit-03" as "draft-ietf-wurzel-rabbit-wgs01.txt".

that's be pretty reasonable, although I'd suggest -01wgs, so that the
sorting order does not get disrupted.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

.