Subject: [newtrk] draft-rousskov-newtrk-id-state-00

From: Alex Rousskov <[email-masked]>
Date: Mon, 5 Apr 2004 22:05:15 -0600 (MDT)

Folks,

	The following draft outlines a "Draft State Declaration"
mechanism that was mentioned in a couple of NEWTRK threads recently. I
hope this mechanism can be polished to become useful for WGS or as a
stand-alone tool.

http://www.ietf.org/internet-drafts/draft-rousskov-newtrk-id-state-00.txt

Abstract

   This memo describes a mechanism to relay the state(s) of an Internet
   Draft to the reader. This mechanism may be used, in part, to
   encourage or discourage review submission, test suite creation, and
   prototype implementation of the entire draft or its portions. The
   state of the draft is declared using a human-friendly notation
   suitable for automated extraction of standard states.

Please review/comment.

Thanks,

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

---

From: Larry Masinter <[email-masked]>
Date: Mon, 05 Apr 2004 22:02:39 -0700

> http://www.ietf.org/internet-drafts/draft-rousskov-newtrk-id-state-00.txt

There are a couple of problems with the mechanism. The state of
a draft, the state of consensus on a draft, changes more rapidly
than the draft itself. So putting the state of the draft inside
the draft leads to a problem -- you submit a draft, then poll the
working group for consensus, then, after the working group has
discussed the draft, the state changes.

Since the status of drafts and working group progress changes frequently
and, unlike drafts, doesn't need to be stable, my suggestion is to
leave the internet drafts alone, and focus on the working group
web page.

Secondly, it's unlikely that the status will fit into a limited number
of neat categories. While it would be nice if you could just
assign a token out of a simple enumeration, but often the status
is much more complex.

My suggestion is this:

Every working group has a web page, but the chairs and draft authors
don't have much input into it.

http://www.ietf.org/html.charters/newtrk-charter.html

says "No Current Internet-Drafts", for example. What if each
working group had, on its web page, for each internet draft,
a "status" field which a working group chair could change?

In fact, what if each Internet Draft had a web page which listed,
at a minimum, its status, but also might contain open issues,
proposed resolutions, pointers to discussions in the mail archives,
etc.? 

This would give you more transparency, it would allow for
better updates, and would give participants better information.
We used issue-list tables in many working groups, and they've
been quite useful. Why don't we make them more generally available?

In the simplest case, the draft-status page could be auto-generated,
with a simple administrative form for updating the status among the
enumerated set, but we could make it possible for people to make
more extensive updates.

It might be convenient if each Internet Draft contained the URL
of the web page that described its status. (And, even better, an issue
list with issues, proposals, possible resolutions, etc, but that's
another story).

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

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 6 Apr 2004 07:16:06 -0500

Thanks, Alex, for submitting a draft. We're working on our next rev of
WGS(A), and you're helping me focus on some things I hadn't thought
about (sufficiently).

I'm responding to the draft and to Larry's note in one e-mail (so
there are comments below reflecting my thoughts about Larry's thoughts
about your thoughts). My comments are pretty high-level (this is not a
SIR CARDing, by any means).

- I happen to also be typing on a proposal to stick stuff IN a draft,
as opposed to sticking stuff ABOUT a draft on a web page. I hear what
Larry is saying about how often the state might change, and it is
irritating to put out two versions of the draft, one for the consensus
call and one to include the result of the consensus call. The problems
I have with "putting it on the web page" are (1) IETF-hosted web pages
are program-generated, so we need custom software development for the
secretariat to make this happen, and (2) lots of groups are using
"additional web pages" now to include material that's not carried on
the WG home page, but there's no consistency for these pages. At the
very least, the draft would need to contain a pointer to a web page,
or casual readers won't see them. As Harald says, draft version
numbers are cheap, so maybe issuing more draft versions is the best we
can do.

- I agree with Larry about having an enumerated set of states - maybe
we could figure this set out, but I don't think we know them now (at a
consensus level). It was too easy for me to think of new reasons for
WGS in Seoul for me to think I've exhausted the list of reasons, and
I'm not a very imaginative guy - a lot of reasons for WGS could map
onto specific states in this draft. This makes me even more cautious
about the web page approach, if we need custom software development
every time we tune our list of enumerated states. WGs have been using
"additional web pages" for a while, because WG chairs have more
control over the contents than they have over the IETF-hosted web
pages.

- I like the idea of making it easy for automated tools to find this
information.

- I like the idea of including dates like "next revision scheduled
for", or "reviews solicited by", if people will use them.

- WGS will require responsive WG chairs (in order to have any effect),
and this draft seems to require them to be even more responsive (in
order to have any effect), because the necessary sampling rate of
state changes is probably higher.

One meta-comment - Alex's proposal would make the world a lot better
place for people who aren't up-to-their-armpits in a working group
trying to figure out what's going on, and Larry's suggested additions
to a working group web page would also. I don't know if we're
chartered to think about this or not (Scott?), but I hope somebody
is... the level of obscurity for our work, for people who don't
subscribe to a working group's mailing list, is pretty high.

Spencer

From: "Larry Masinter" <[email-masked]>

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

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 05 Apr 2004 23:05:08 -0700

1) note: there is room on the charter for a pointer to an "additional 
information" page for the WG. I encourage all WGs to have such a page. 
Unfortunately, for the time being, there is no centralized facility to 
offer WG chairs as a hosting site.

2) what Alex is proposing would be the editor's best attempt at reflecting 
the status of the WG at the moment the draft is published. I don't see how 
it could represent anything else.

.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 6 Apr 2004 09:57:06 -0600 (MDT)

At the end, there is an attempt to summarize our [dis]agreements.

On Mon, 5 Apr 2004, Larry Masinter wrote:

> The state of a draft, the state of consensus on a draft, changes
> more rapidly than the draft itself.

IMO, the correct assumption would be "WG consensus may change more
rapidly than WG publishes the draft". That is, what you are describing
does happen, but does not happen all the time. That is an important
caveat to keep in mind.  The State Declaration mechanism has profiles
for both stable and unstable drafts; a WG does not have to publish
draft state if it changes too often to be published using todays
publication mechanisms.

> So putting the state of the draft inside the draft leads to a
> problem -- you submit a draft, then poll the working group for
> consensus, then, after the working group has discussed the draft,
> the state changes.

I have several orthogonal answers to that:

    1. IETF draft publication system is broken/obsolete. When/if
       it is fixed, it should not take more than a minute to
       publish a revision of a draft. Fixing draft publication
       system is beyond the scope of the State Declaration
       draft and probably beyond the scope of any IETF WG
       (unfortunately). The state declaration mechanism will benefit
       from such a fix, but does not require a fix to be useful.

    2. The WGs should not use the "known state" declaration
       profile if they expect the state to change sooner than
       the next version of the draft is published. The mechanism
       allows the WG to tell the world that the draft is not
       stable, which is much better than to tell the world nothing!

    3. In many cases, a WG does not have to publish a new
       version of a draft to make a consensus call for a specific
       portion of a draft. Discussing that portion on a mailing
       list is often sufficient (depending on the feature and
       on specifics of the consensus call). For example, it
       is often possible to reach "the next version of the draft,
       with issues A and B fixed as discussed, should have the
       Review bit set" consensus.

> Since the status of drafts and working group progress changes
> frequently and, unlike drafts, doesn't need to be stable, my
> suggestion is to leave the internet drafts alone, and focus on the
> working group web page.

The state declaration mechanism can be applied virtually "as is" to
the WG web page. Since WG web pages do not have revision history, the
revision number should be removed from the draft-name component of the
formal-record. I cannot think of any other serious changes.

> Secondly, it's unlikely that the status will fit into a limited
> number of neat categories.

The number of categories is not limited. There is a limited number of
standardized categories, but WGs can add their own state and part
values at will.

> What if each working group had, on its web page, for each internet
> draft, a "status" field which a working group chair could change?

It cannot be a "field", I think. It has to be an "section" or "page"
since draft state may be more complex than can be described in a
field.

> We used issue-list tables in many working groups, and they've been
> quite useful. Why don't we make them more generally available?

I agree that giving WGs write access to IETF-hosted or IETF-linked web
pages is the right thing to do, but I think that does not affect the
Draft State Declaration draft much. In other words, you should
consider writing a different proposal that outlines how WG web space
should be managed.

> It might be convenient if each Internet Draft contained the URL of
> the web page that described its status. (And, even better, an issue

I think that from information management point of view, separating a
draft from its state is a Bad Idea. It seems like you are trying to
patch a side-effect of a broken publication system instead of fixing
the core problem. If drafts can be auto-published, there will be no
out-of-sync problem we can solve (i.e., fresh information will be
available if and when the WG wants it to be available, even if the
information changes hourly). Again, these kind of changes seem to be
out of the State Declaration scope.

Summary: It seems to me that you are not against the idea per se, but
would like state declarations to be published on the web. I think that
would be great (and the draft mentions that possibility)! Our only
disagreement seems to be in whether declarations should exist
separately from the drafts or extracted from them, which is an issue
that does not affect the proposed declaration mechanism much.

Do you agree with this summary? Do you think it would make sense to
polish the draft to make the declaration mechanism more location- and
publication-mechanism-neutral?

Thank you,

Alex.

.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 6 Apr 2004 10:30:10 -0600 (MDT)

On Tue, 6 Apr 2004, Spencer Dawkins wrote:

> We're working on our next rev of WGS(A), and you're helping me focus
> on some things I hadn't thought about (sufficiently).

I hoped for kind of the opposite effect, actually :-). I hope WGS(A)
can simply point to or, at least, reuse large portions of the proposed
declaration mechanism instead of "thinking" about these matters.

> The problems I have with "putting it on the web page" are (1)
> IETF-hosted web pages are program-generated, so we need custom
> software development for the secretariat to make this happen, and
> (2) lots of groups are using "additional web pages" now to include
> material that's not carried on the WG home page, but there's no
> consistency for these pages.

These are two side-effects of the same problem, IMO. Official WG web
space should be managed by the WG, not secretariat. I suspect there is
existing low-maintenance software that can be used to make this happen
without increasing secretariat burden. In fact, I believe that if this
is done right, the secretariate long-term burden will be much less
(and the WG burden will be higher).

This seems to be unrelated to the state declaration itself. It only
relates to the authoritative location for the declaration (draft
versus page).

> As Harald says, draft version numbers are cheap, so maybe issuing
> more draft versions is the best we can do.

Indeed, draft revision numbers cost nothing. It is the publication
delay that costs a lot. It is like communicating via snail mail: it
"works", but precludes some very useful kinds of information exchange.

> consensus level).

There is no enumerated set of states. There is only an enumerated set
of standard states. WGs can add their own states, not necessarily
enumerate-able.

I will try to polish the draft to make the above assertion clear. It
looks like it is a common misconception about the mechanism!

> for", or "reviews solicited by", if people will use them.

Do you think this should be formalized for automated extraction as
well? Currently, you can include such dates in states or comments, but
no software will be able to understand them without AI.

Can we address 90% of related needs if we introduce one formal
mechanism: the state expiration date? That is, every state will have
an optional expiration date after which the WG expects the state to be
different. Should the expiration date apply to each state (for
flexibility) or to the entire declaration (for simplicity)?

On the other hand, this sounds like patching a side-effect of the
current draft expiration mechanism (which is too rigid to make
practical sense). So again, this could be out of scope, and a
different draft would be needed to solve the problem by changing
expiration semantics and allowing WGs to set meaningful draft
expiration times.

> - WGS will require responsive WG chairs (in order to have any
> effect), and this draft seems to require them to be even more
> responsive (in order to have any effect), because the necessary
> sampling rate of state changes is probably higher.

I would state it differently. Both drafts increase WG load if the WG
wants to benefit from them and do not increase WG load otherwise. The
Chair involvement is necessary at some stages, but most of the work in
determining state lies within the WG itself, as usual.

> trying to figure out what's going on, and Larry's suggested
> additions to a working group web page would also. I don't know if
> we're chartered to think about this or not (Scott?), but I hope
> somebody is... the level of obscurity for our work, for people who
> don't subscribe to a working group's mailing list, is pretty high.

Yes, the state declaration draft was intended primarily for folks not
intimately familiar with the draft (inside or outside the WG). It
makes little sense to declare the state of the draft to those who
already know what the state is :-). Said that, I hope the mechanism
will have a positive _stimulating_ effect on authors or draft "teams"
as well.

Thank you,

Alex.
.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 06 Apr 2004 10:03:44 -0700

I don't think you have summarized my position; I think that
formalizing and encouraging the declaration of the state
of a draft in the draft itself (rather than a pointer
to where this could be found) is a bad idea. 

If it were the case that the state of the draft was
always known at time of publication of the draft, it
would be different.

Consider 'writers' and 'readers', in two cases:

1. In cases where the state of the draft changes after the draft
comes out, putting the state in the draft itself is counter-productive;
it was unnecessary work for writers and is potentially
confusing to readers. This is especially troubling when
disagreement appears after it seemed as if there was consensus.

2. In cases where the state is known before the draft is published,
it still adds work for writers and has marginal utility for
readers, since the readers still have to go to some
web page to see whether the state has changed since the draft
was published.

Futher, consider how adding this section will change people's
behavior:

I think it would encourage people to delay publishing drafts
until the state is 'known'. But the best way to decide
on the state is to publish the draft and ask people
to review the actual document, instead of talking about
abstract points that don't actually appear in the document.

It's been my experience that convergence on status only
comes after there is an actual draft that contains the
text that you think there was agreement on a particular
point, and people are able to read the text in context.

So I think it's counter-productive to encourage people to
put the status in the drafts.

Larry

.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 6 Apr 2004 12:06:19 -0600 (MDT)

On Tue, 6 Apr 2004, Larry Masinter wrote:

> formalizing and encouraging the declaration of the state of a draft
> in the draft itself (rather than a pointer to where this could be
> found) is a bad idea.

Noted. It is an important difference I did not realize.

Said that, please note that the proposed declaration can be used
outside of a draft with virtually no changes to the mechanism itself.
Depending on others feedback, it may be a good idea to adjust the
draft so that it does not imply a specific publication channel/medium.

Depending on the state of draft publication/dissemination mechanism,
publishing draft state on a web page may indeed be better than (or no
different from) embedding it in a draft. For example, it is easy to
imagine a system where the draft snapshot is assembled from the draft
text and state declaration on-the-fly, when the reader requests "the
most recent revision of the Foo draft". Will IETF be able to do that
in the foreseeable future? Where is the right forum to discuss this?

The remaining responses below is an attempt to clarify some
misconceptions that, IMO, are _unrelated_ to the declaration
placement.

> If it were the case that the state of the draft was always known at
> time of publication of the draft, it would be different.

The proposed mechanism has a profile to state that the state is not
known at the time of the declaration publication. If we use a web page
as a medium, this mechanism is still very useful and can be used
virtually as-is.

Also, please note that the state may be applied to a _portion_ of the
draft. It is often the case that the WG has consensus about certain
portions of the draft, but not the entire draft. Similarly, a WG may
have consensus about appropriateness of certain actions (e.g., review)
but not others (e.g., implementation).

> comes out, putting the state in the draft itself is
> counter-productive; it was unnecessary work for writers and is
> potentially confusing to readers. This is especially troubling when

Yes, consensus may change at any time, especially if the WG allows it
to change at any time. Any declaration medium other than WG mailing
list will be out-of-date sometimes.

However, often the WG acts to protect itself from extra/repeated work
in certain areas. A WG may say "we are not going to willingly come
back to the syntax debate; the protocol syntax is frozen as of now,
and we expect no changes until IESG review". Or "we are not going to
publish the next version of the draft until 2004/05/01, and we expect
all reviews submitted by 2004/04/15 to be reflected in the next
version of the draft". Such long-lived statements can and should be
declared (somewhere).

Similarly, absence of consensus should be declared as well (to avoid
the false impression that the WG draft represents WG consensus).

Finally, note that the web page becomes out of date just like a draft.
If draft publication (i.e., update) takes about the same time as web
page update, then there is no difference between the two approaches as
far as freshness of information is concerned. Since you are,
essentially, suggesting a change to the way WG web pages are made, we
should compare the overheads of supporting your change with the
overheads of supporting draft-embedded declarations (among other
things).

> it still adds work for writers and has marginal utility for readers,
> since the readers still have to go to some web page to see whether
> the state has changed since the draft was published.

Having authoritative states in two places makes no sense indeed (and I
do not think anybody suggested that)! Either we should include the
state in the draft (and replicate it on the web page) or we should
publish it on the web page (and link to it from the draft). Both
approaches have pros and cons, as usual. None creates the problem you
describe in #2 above.

> I think it would encourage people to delay publishing drafts until
> the state is 'known'. But the best way to decide on the state is to
> publish the draft and ask people to review the actual document,
> instead of talking about abstract points that don't actually appear
> in the document.

What you describe above is already explicitly supported by the proposed
mechanism! When there is WG consensus that the draft is ready for a
review, the WG uses a standard

	Draft :- Review

declaration. No self-imposed delay in publication (in any medium) is
needed!

Moreover, the presence of the above state (in any medium) will allow
people who are interested in the draft to review it when the WG wants
it to be reviewed. IETF will be able to offer meaningful
"watch/monitor this draft" tools for external readers.

> It's been my experience that convergence on status only comes after
> there is an actual draft that contains the text that you think there
> was agreement on a particular point, and people are able to read the
> text in context.
>
> So I think it's counter-productive to encourage people to put the
> status in the drafts.

I agree that it may be counter productive in some situations, for the
reasons you imply above, but only if updating a draft requires a
significant effort. If updating a draft with a new state declaration
is as "expensive" as updating a web page, then keeping the state
declaration in the draft is no worse than maintaining it on a separate
page, right?

If so, we need to compare the effort/benefits to let WGs manage state
declarations on their IETF web pages with the effort/benefits to let
WGs manage draft publications on their IETF web pages.

Thanks,

Alex.
.