Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Warren Kumari <[e-mail]>]

On Mon, Jul 8, 2019 at 4:54 PM Keith Moore <[e-mail]> wrote:
>
> On 7/8/19 4:26 PM, john heasley wrote:
>
> > Sat, Jul 06, 2019 at 12:44:14PM -0700, Eric Rescorla:
> >> On Sat, Jul 6, 2019 at 11:55 AM Theodore Ts'o <[e-mail]> wrote:
> >>
> >>> I suspect people have been jumping off to something which is harder,
> >>> and perhaps for them, more interesting, which is signalling that a
> >>> particular I-D version is one that is worthy of being implemented, and
> >>> perhaps, deployed in a world where new implementations can be reliably
> >>> rolled out to a large percentage of the installed base in 2-3 months.
> >>> One answer is of course the experimental RFC, but the problem is that
> >>> a lot of people see RFC and immediately assume, it's a stable,
> >>> IETF-blessed standard documentation, regardless of the "Experimental"
> >>> tag on the top of every single page of said document.
> >>>
> >> An experimental RFC would not address the need I am talking about: we're
> >> spinning one of these every 1-4 months, and doing WGLC, IETF-LC, and RFC
> >> processing would cause far too much delay.
> >>
> >> -Ekr
> > exactly; neither experimental nor informational address the desire completely.
>
> So what it sounds like you need is a link to an internet-draft but
> without the version number at the end, that always points to the current
> version of that Internet-draft.

We already have that --
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/

> And IMO the link should actually point
> to active content that allows the reader to easily query the revision
> history and diffs between changes,

We already have that --
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/history/

> and recommendation status of the
> draft, instead of (merely) the plain text of the draft.

We had considered having a datatracker tag which could be attached to
a draft to do exactly this -- and decided that it would be unclear to
external people.

>  Perhaps the
> header portion of the active content should also include that link for
> easy referencing: "to obtain the current version of this internet-draft,
> visit
> https://tools.ietf.org/active-internet-drafts/draft-ietf-xxx-yyy.html".

Something like:
"The list of current Internet-
 Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress.""
?

>
> Use the normal internet-draft submission mechanism to update such documents.
>
> If we don't already have a page that does this, it doesn't seem like it
> would be terribly difficult to add.  If you really want to get fancy,
> splice the current status and links to revision history and diffs into
> the XML before rendering the XML.   But that might be overkill.
>
> Seems like it should work just fine up until at least revision -99.
>
> Of course one could always ask for more features.  But if it's worth
> doing, it seems like it's worth doing simply first.

I'm really not sure if you were subtly trying to point out that we
already have all of this and so why are we proposing anything at
all...

What we were looking for is something a *little* bit more formal than
"just an ID", and *much less formal* (and also easier to update!) than
an RFC - basically an intermediate step to signal that a version has
more agreement than just what the authors believe.
If I'm an author of a WG document (draft-ietf-foo-bar-23) I publish a
new version with whatever *I* think the WG wants - but often it's
really hard to determine what exactly that is (conversations in email
quicky run off-topic, getting the *exact* wording that makes everyone
happy is tricky, working groups are fickle and change their minds,
determining consensus is difficult, etc).
What I was trying to do is be able to signal that version A of a draft
contains what the WG has (currently!) agreed to, while version B add
what the author(s) are proposing the next version should look like;
basically reasonable analogies are that version B is the "development
branch" or something similar to a Pull Request.

I had tried making an analogy to semantic versioning, with the MAJOR
version being fixed at 0 and A being something like Version 0.5.0 and
B is Version 0.5.4. Having the major being 0 means that anything can
change at any time (https://semver.org/#spec-item-4) -- but this
analogy implies more stability than I intend.
I'd point out that WGs can already do this -- for example, the foo WG
could use draft-ietf-foo-stable-bar, and draft-ietf-foo-devel-bar, or
make it well known that draft-ietf-foo-bar will always contain the WGs
agreed to changes, and that the "development" branch is at
www.github.com/<something>/draft-ietf-foo-bar, or ...

The (proposed) stable-ietf-foo-bar proposal is / was intended to be a
clear signal that the WG doesn't think that text is sane, not that it
is carved in stone.

W


>
> Keith
>
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf