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

[Alex Rousskov <[e-mail]>]

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
> list with issues, proposals, possible resolutions, etc, but that's
> another story).

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.

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