On 7/8/19 5:52 PM, Warren Kumari wrote:
On Mon, Jul 8, 2019 at 4:54 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> 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 <tytso@xxxxxxx> 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
