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 <phill@xxxxxxxxxxxxxxx> 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 milestones1) 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 <warren@xxxxxxxxxx> wrote:--On Wed, Jul 3, 2019 at 1:10 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxxx> 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
