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

[Spencer Dawkins at IETF <[e-mail]>]

Top posting ...

It seemed to me that we spilled a large number of words in NewTrk trying to
describe when working groups could declare a Stable Snap Shot (SSS), or in
a parallel proposal, a Working Group Snapshot (WGS), and who would need to
approve that (choices included the IESG, ADs, and WG chairs), and after
tripping over a number of corner cases, what seemed appropriate to me was
to let working group chairs declare that a draft was stable for a specific
purpose - as we do now with QUIC implementation drafts, the chairs say "at
the next interim, we'll be testing -22, whether there are later revisions
or not", and see what happens after that.

Writing process BCPs that work for all IETF working groups is hard, and
trying to nail down every detail and anticipate every possible problem with
every possible usage makes it harder.

But it seems important to realize that we're not talking about something
the IETF isn't doing now - we're talking about how obvious what the IETF is
doing now will be to people who aren't at the epicenter of specific work.

Best wishes, of course.

Spencer

On Thu, Jul 11, 2019 at 9:56 AM Phillip Hallam-Baker <[e-mail]>
wrote:

> Thinking through comments made by John Klensin on the other thread, I came
> to a similar conclusion. Warren may not have the right mechanism but I
> think that it is in principle right that a Working Group should decide the
> degree of stability of their spec as they work.
>
> There is precedent for this, if you look at the QUIC group they are doing
> effectively that. It is always good to work from actual practice.
>
> When writing a spec, there are two separate sets of milestones
>
> 1) Is the technology fixed?
> 2) Is the description of the technology fixed?
>
> The first has to precede the second of course. And there are degrees of
> done-ness. But in most cases there are clear waterfalls that the WG goes
> over where it is understood that a decision has been taken and won't be
> un-made unless there is a really really good reason.
>
> Sometimes those decisions are made before a spec gets to IETF. If there
> are 10,000 users of a spec and it is using XML, it is going to be a slog
> persuading people to switch to JSON because it is the flavor of the month.
> If there are a million legacy users, the change probably ain't going to
> happen.
>
> Questions of this type should (and often are) negotiated during WG
> formation.
>
> If the spec has more than a certain complexity, there is usually a point
> where the WG decides that the functionality and technology are essentially
> decided and from this point on the work will be basically word smithing.
> There can be a lot of that left to do of course. But the point is that
> there is usually a decision that from that point on, the WG is not going to
> make any breaking changes without considering the interim deployments.
>
> Again, these are shades of gray, not bright lines.
>
> It might well be the case that we could use some more formal notice of
> when these points are crossed. It probably isn't a good idea to make this
> require IESG action but it might be something that is recognized as a
> milestone.
>
>
> There are exceptions where this doesn't work of course but those are
> usually when you are faced with trying to extend a legacy platform that
> isn't designed to extend in the way you want and so there are inevitable
> conflicts in the spec. CAA presented a choice between two different
> approaches to handling CNAME records that met different sets of use cases
> and you have to choose one or the other.
>
>
> On Wed, Jul 3, 2019 at 4:26 PM Warren Kumari <[e-mail]> wrote:
>
>>
>>
>> On Wed, Jul 3, 2019 at 1:10 PM Keith Moore <moore@network-heretics..com
>> <[e-mail]>> wrote:
>>
>>> On 7/3/19 4:04 PM, Warren Kumari wrote:
>>>
>>> > Hi there all,
>>> >
>>> > TL;DR: Being able to mark a specific version of an *Internet Draft* as
>>> > “stable” would often be useful. By encoding information in the name
>>> > (stable-foo-bar-00) we can do this.
>>> >
>>> > Heather and I will be holding a side meeting at IETF 105 to discuss
>>> > the idea and get feedback.
>>> > When: Tue, July 23, 3:00pm – 4:30pm
>>> > Where: C2 (21st Floor)
>>>
>>> It seems to me that this would defeat the entire purpose of
>>> Internet-Drafts and serve to circumvent the IETF process.    There
>>> should be no expectation of stability until a document has reached
>>> IETF-wide consensus.
>>>
>>
>>
>> Great, please come to the side meeting and we can try better explain the
>> use case. I thought I’d better described the use case further down in the
>> mail, but it seems I may have failed...  This specifically allows the WG to
>> point at a version of a document that external type people can implement
>> against **while** still allowing the working group to make changes, etc. If
>> anything this allows the WG to make more changes because it (hopefully)
>> removes some of the “we cannot change this bit because someone may have
>> implemented against it” concern.
>>
>> But, it’s entirely possible that this is just a bad idea, please come to
>> the side meeting...
>>
>> W
>>
>>>
>>>
>>> --
>> 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
>>
>