Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.

[Ted Lemon <mellon@xxxxxxxxx>]

Perhaps it would be effective to mark documents not stable and not label stable documents.  IOW, encourage wgs to explicitly say “for the love of Mike, don’t ship this.”

Sent from my iPhone

On Jul 3, 2019, at 7:54 PM, john heasley <heas@xxxxxxxxxxxxx> wrote:

Wed, Jul 03, 2019 at 01:04:56PM -0700, Warren Kumari:

“Evolving” documents (there were originally called “Living documents”,

but that name is already in use in the web community, and so we chose

another name to make it less confusing).

“State of Play” documents.

I wish that you would not create new terminology if it is the same idea.
It decreases accessibility, IMO.  Instead label it with IETF; "IETF
Evergreen Document", which seemed the most common term for this when I
looked a few weeks ago, or "IETF Evolving Document".  I do not understand
why it is relevant or how some other group's use of it creates baggage
for IETF.  Seems wholly a NiH problem.  Decide for yourself what the
most common term is and use that.

BTW, I read a page that seemed to suggest that the Canadian Gov't uses
all three terms.

There are a number of topics / drafts where the best current practice

changes over time - a simple example of this is something like routing

security, and so I’ll use it as an example (also, the concept was

first presented in GROW!), but the concept is applicable to all sorts

of cases.

The best practices for routing security (what / how to filter,

route-leak prevention, etc) change over time and it is not really

feasible to document how to e.g build route filters and then release

-bis documents quickly enough to keep up with how the operational

advice changes; this means that much of this sort of information

doesn’t get documented in the IETF, and instead is scattered around in

institutional knowledge, personal blogs, IRC channels, etc.

This I'd like to see - a stable document name (URL) that documents an
ever evolving technology.  For example, RFC 7525 (TLS Recommendations)
attempts to document TLS standads; protocol revisions, cipher suites,
etc.  Tremendously useful RFC for developers and users, that seems already
out of date and probably was shortly after publication.

It would be useful to have a document like RFC7525 that could evolve
with TLS, but more nimbly than an RFC.  One that an RFC of another
discipline could reference, and follow the evolution without itself
needing updating.  The evolution needs to be captured in a public SCM,
so that previous versions can be retrieved.

I do not think that I've addressed any of your points, but this is
perhaps another use case.

https://www.w3.org/wiki/Evergreen_Standards

9: This ain’t new, $person proposed something similar at $meeting_or_list….

Indeed. As an example, Phillip Hallam-Baker mentioned a desire for

something similar at the IETF102 plenary; I think that this

1992: https://datatracker.ietf.org/wg/livdoc/about/