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

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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/
>