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

[Alex Rousskov <[e-mail]>]

On Tue, 6 Apr 2004, Larry Masinter wrote:

> 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.

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).

> 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.

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).

> 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.

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.

> 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.

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.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html