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

[Keith Moore <[e-mail]>]

On 7/8/19 5:52 PM, Warren Kumari wrote:

> 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/
why, yes.
>> 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/

Yes, though the "history" link could be made explicit on the former page.

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

To some degree that might depend on how the status is presented.

>>   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.""
> ?
Well, not quite.   I'm thinking if you have a living document that 
sometimes also gets printed out, it would be useful for that document to 
make obvious where to go to find the latest version _of that 
document_.   You could certainly get there via the list of 
internet-drafts, but it's a long list and it's not hard to provide 
something better.
>> 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...

More like, if we can describe what is wanted in terms of simple deltas 
to what we have already, it would be easier for us to understand what 
various people want.  That and if desirable, we could probably implement 
those deltas on an experimental basis fairly easily.

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

I think I've seen at least three different things that people are 
looking for.   I think my concerns in most cases pretty much boil down 
to making sure that in each case appropriate process is followed and 
documented and transparent to readers, and that document versions aren't 
misleadingly labeled.   And if we're talking about changing existing 
processes, that those changes be appropriately reviewed and meet IETF 
Consensus.

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

I think that's true for every version of an I-D.  It's what I think the 
WG wants or hope the WG will accept.   If the WG accepts it, it goes to 
IESG; if not, I iterate again.

If WGs want to say "we approve this document but we don't want to send 
it to IESG just yet" (or maybe not ever?), I think that's a process that 
doesn't exist yet, and perhaps should not exist. The danger is that WG 
approval will be taken as "good enough" without broader community 
review.   There are probably corner cases in which this would be ok, 
though - for which IESG could allow specific WGs to do this for specific 
documents that meet pre-established criteria.

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

I agree this could be done now for WGs using git* to maintain documents, 
as long as a WG doesn't claim that the master branch of the document has 
somehow been approved.   But it's a slippery slope for a WG to label a 
document as having been approved, since that would look like new process 
and bypassing wider review.

Anyway, it may be that what you want is more a matter of 
defining/approving process changes than developing new tools.

Keith