Subject: Re: [Tools-discuss] auth48 diffs?

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 2 Dec 2009 18:42:39 -0500

(I submitted this earlier today, but it got wedged on the way to the mailing 
list. Apologies if you've already seen it!)

Just to follow up on Jeff's note - I know that we're headed to a
conversation that needs to happen with the larger community, but since Jeff
pointed this out...

>>> For documents in AUTH48, it would be terribly convenient for the version
>>> progression to extend into the RFC-to-be, so it is easy to examine
>>> differences between the last I-D version and the RFC-Editor's proposed
>>> final document.
>>> ...
>>
>> A simple way to achieve this would be the post the proposed final
>> document as Internet Draft.
>
> That gets messy...  Posting a new I-D version requires cooperation of the 
> document author, and will likely confuse the RFC-Editor.  Also, the 
> "final" version tends to change frequently; posting each version as a new 
> I-D could significantly increase the number of I-D versions on file for a 
> document.
>
> -- Jeff

Yeah, about that.

I'm not making this up. Aaron Falk was working AT ISI when we had one of the
PILC drafts go through something like 18 AUTH48 revisions based on something
like 250 e-mails that copied the RFC Editor. The revisions happened for a
variety of reasons, some of them good. I talked about this experience in the
Working Group Leadership tutorial for several years afterwards, but I'm not
proud of it (the context in the tutorial was "learn from our mistakes").

We may have set the indoor record for AUTH48 revisions, but I know that
other people do multiple revisions in AUTH48, too. That's making me think
along two lines:

If we just dropped this change on the community, that WOULD confused people,
and not just the RFC Editor (insert the visual image of ADs going "huh???"
here, not to mention the working group, etc). So let's not do that.

But if we thought this through, we might end up with (1) some backpressure
for posting AUTH48 comments that then get modified by other authors,
resetting the AUTH48 process each time, instead of having the conversations
and THEN posting AUTH48 comments - maybe not once, but a smaller number of
times, and (2) greater visibility for the working group that post-approval
changes are happening, and people who care might want to look at diffs,
which would be easy because the changes show up as just another draft
revision. At this time, I don't believe the working group gets any
notification about these changes until the RFC is published, unless an
editor/working group chair/AD chooses to manually post a note about the
changes on the working group mailing list.

In my experience, both of these changes would be beneficial. If most
authors/editors just tell the RFC Editor "the AUTH48 version is fine", this
would be a no-op for them, of course.

Do people think we should continue this discussion on the WG chairs mailing
list, for example? Or on the IETF discussion list?

Thanks,

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Dec 2009 14:45:38 +1300

> list, for example? Or on the IETF discussion list?

And is this a new discussion? I seem to remember having it
a few times before (so I've deleted most of this thread unread).

After IESG approval, there should be *no* substantive change without
rechecking consensus with the WG. Maybe the PILC case had 18 editorial
changes that need 250 emails to get them right. I don't know. But if even
one of those changes was a real technical change, it should have gone
back to the WG.

Whether a new I-D is needed is surely a matter of common sense in
a particular case. I can't get excited about it, but it obviously
isn't needed in the majority of cases, otherwise we'd be having this
conversation every week.

    Brian