Subject: Re: [rfc-i] Time to say "NO!!" to AUTH4200 (Re: AUTH48 checking the different formats (Re: Public archival of AUTH48 communications))

From: David Noveck <[email-masked]>
Date: Mon, 28 Feb 2022 04:55:19 -0500

While I am in favor of greater transparency in this area and I feel that
the discussion has been helpful, I think the fundamental issue is that the
AUTH48 process has gotten out of control, which it clearly has, given that
there are documents that have languished in this state for over 25 weeks
rather than 48 *hours*, which was the original intention.   I can see no
justification for this expansion to 25 x 7 x 24 =  4200.

Perhaps with the formatting issues that now exist there is a need to be
more realistic and move to AUTH168 or even AUTH192 but a line clearly has
to be drawn and AUTH4200 is on the wrong side of it.

It gives time for issues on which consensus has been declared to be
relitigated, perhaps endlessly, and that is clearly bad.  Another source is
ADs showing an inappropriate degree of tolerance for lazy authors and that
has to stop somehow.9oj

The IESG has tried to address this issue in a statement on 1/5/2006 but,
here we are 16 years later and the problem still exists.

I'd like to ask all ADs with documents beyond the AUTH1000 point to
investigate and suggest ways to address the issue for real.

On Mon, Feb 28, 2022, 3:37 AM Carsten Bormann <[email-masked]> wrote:

> >> With the move to XML and renderings of a new RFC in different
> >> formats, who is responsible for reviewing the different
> >> renderings for unintended changes in meaning? If it's the
> >> authors, I'd hope that a change in AUTH48 might offer some way
> >> to spread the burden.
> >>
> >> FWIW
> >
> > Larry, based on the last document with which I went through
> > AUTH48 (in the first half of 2020), it wasn't clear who, if
> > anyone, was responsible for checking the different formats and
> > renderings.
>
> “Responsible”: The authors of course (in theory).
>
> > Of course, the theory is that, if the XML is
> > correct, everything else should take care of itself.
>
> Well, that isn’t even a theory.
> Xml2rfc has its mysterious ways.
>
> More importantly, implementers will look at a rendering (TXT, HTML/PDF).
> If that is confusing, you will have interoperability problems (or low
> take-up).
> So authors will typically check one of the renderings in some detail.
> (Only with a lot of luck, they will seriously both TXT and HTML or PDF,
> which unfortunately is really needed in particular since 3.10.0.)
>
> Where aspects of the XML are not visible in the renderings, the RPC has
> started to ask specific questions.
> E.g., for the type= attributes of <sourcecode elements.
> I’m not sure there is a checklist of invisible aspects.
> It would help to have an debug-the-XML rendering where all these invisible
> aspects become visible.
>
> In summary, I think that a theory where authors are responsible for the
> XML will stay fiction.
> The RPC is much better off doing this, being used to operate in that noisy
> environment, and (I hope) more aware what went wrong in previous RFCs.
>
> Grüße, Carsten
>
>
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Feb 2022 10:45:16 -0500

Perhaps the story of AUTH4200 could be more clearly communicated so that we
can understand if it's an anomaly.

My experience, for instance, with RFC8415 was that AUTH48 stretched into 2-3 months, because
the length of the document meant that a few authors just couldn't find the
time to do the full review required.  A significant issue was that it had
spent a long time in the Q, and authors had swapped too much context out.

Basically, the best way to make it all work faster would be to just do it
faster  :-)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 28 Feb 2022 15:50:35 -0000

Y'all might find Christian's work in RFC 8963 useful in this regard.
Although only a small and random sample of RFCs, it does show some of the variation in Auth48 and the (possibly anecdotal) causes thereof.
Adrian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Feb 2022 18:18:08 +0100

Am 28.02.2022 um 10:55 schrieb David Noveck:
> the discussion has been helpful, I think the fundamental issue is that
> the AUTH48 process has gotten out of control, which it clearly has,
> given that there are documents that have languished in this state for
> over 25 weeks rather than 48 /hours/, which was the original intention.
>   I can see no justification for this expansion to 25 x 7 x 24 =  4200.
> ...

I'm currently on a set of docs where we've been in AUTH48 for almost 2
months.

IMHO, this is because the RPC work style mixes lots of unrelated changes
into one monolithic process, and the authors can either just assume
everything is ok, or take their time to evaluate every change. That
takes time.

It would be much easier if the RPC just created pull requests for what
are essential language/grammar/style fixes and left everything else alone.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 18:31:35 +0100

> are essential language/grammar/style fixes and left everything else alone.

… and the authors are working in their authoring format and essentially have to retro-convert the RPC changes back into that format so they can continue to run the automation.  While this is strictly necessary only for a few very complex documents (like the set of documents Julian is talking about (*)), automation is likely to become more important for more drafts over time, and it is just the way we software people do things.

Text is code…

I think we can discuss how tenable it is for the RPC to make edits in org-mode, mmark, Julian’s special XML vocabulary, kramdown-rfc, nroff :-)
I don’t think the answer to that is as obvious as it might have been.

Also, we authors have different ways to run the source revision control; fortunately, there is a lot more convergence in that (i.e., git, mostly with github) than in the authoring formats.  (There may be details in the workflows that I don’t fully grasp yet, but the equivalent of a PR should always work.)

Grüße, Carsten

(*) one of which my AUTH48-DONE RFC is waiting for :-)

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Feb 2022 18:42:41 +0100

> … and the authors are working in their authoring format and essentially have to retro-convert the RPC changes back into that format so they can continue to run the automation.  While this is strict…

...and it's a shame to stop treating it that way in the last publication
step.

FWIW, although I would prefer proper diffs against *our* sources, it
would already be helpful if the RPC created diffs against the plain text
output in sensible work units, such as "this fixes your typos", "this
makes hyphenation consistent" and so on.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 18:48:50 +0100

On 2022-02-28, at 10:55, David Noveck <[email-masked]> wrote:
> 
> I'd like to ask all ADs with documents beyond the AUTH1000 point to investigate and suggest ways to address the issue for real.  

Apart from the technical mismatches I just brought up, there also is a scheduling problem.  Doing AUTH48 even for a medium-sized document such as RFC-to-be 9176 (60 PDF pages; 74 in TXT form) requires setting aside some time.  Today, the RPC is essentially a black box that suddenly spews a significant work order at you.  Not totally surprising (one can look at the queue, look at average sojourn times, and make guesses), but not plannable either.

So in this case I decided to leave all the early AUTH48 work with the main author/editor, and I will only come in when the document is nearly stable, which has given me some time to weave this work into the scheduling.  But there just is no way to do this in less than 4 weeks (which is still AUTH672, phew).

If we plan to move towards a more author-friendly form of document production, some interaction about scheduling the author work will need to be added.
And yes, “kein Plan überlebt den ersten Feindkontakt”… (*).

Grüße, Carsten

(*): Actually, Moltke said “Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus”.  Apparently, he didn’t have an RPC helping him :-)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Feb 2022 11:04:22 -0700

No hats.

On 2/28/22 10:42 AM, Julian Reschke wrote:
>> … and the authors are working in their authoring format and 
>> essentially have to retro-convert the RPC changes back into that 
>> format so they can continue to run the automation.  While this is 
>> strictly necessary only for a few very complex documents (like the set 
>> of documents Julian is talking about (*)), automation is likely to 
>> become more important for more drafts over time, and it is just the 
>> way we software people do things.
>>
>> Text is code…
>> ...
> 

Folks, I'm sure realize that you are asking for a major revamp of the 
RPC's work processes to align with the work processes that some authors 
follow.

I say "some" because not all authors treat text as code, work in a 
source code management system like Git, author in markdown, feel the 
need to keep their repository up to date with changes made by the RPC, etc.

Is it up to the RPC to modify its work processes depending on the work 
processes of the authors for a given document? What are the implications 
for tooling and for training of editorial staff?

And so on.

This is a business process re-engineering initiative with unclear scope, 
but I'd guess that the scope won't be small.

Therefore, while it might be productive to get this topic out in the 
open now, IMHO it should be discussed in the RSWG with significant input 
from the RPC and the IETF LLC, who will need to fund the relevant work 
(which might include tooling, training, and whatever all else).

In the meantime, someone might want to author an Internet-Draft.

Just my two cents.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Feb 2022 13:08:36 -0500

I would actually go further.

It seems to me it is untenable to expect the RPC to work with the soruce 
form of all the authors.
And the community has nothing resembling agreement on what the source 
form should be.

So please, let's not go there

Yours,
Joel

On 2/28/2022 1:04 PM, Peter Saint-Andre wrote:
>>> strictly necessary only for a few very complex documents (like the 
>>> set of documents Julian is talking about (*)), automation is likely 
>>> to become more important for more drafts over time, and it is just 
>>> the way we software people do things.
>>>
>>> Text is code…
>>> ...
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 28 Feb 2022 13:55:19 -0500

Peter and Joel,

All that said, Carsten had an excellent point when he said "Apart from the
technical mismatches I just brought up, there also is a scheduling
problem.  Doing AUTH48 even for a medium-sized document such as RFC-to-be
9176 (60 PDF pages; 74 in TXT form) requires setting aside some time.
Today, the RPC is essentially a black box that suddenly spews a significant
work order at you.  Not totally surprising (one can look at the queue, look
at average sojourn times, and make guesses), but not plannable either."

Having been there, I agree that it can be a good amount of unplanned work
when a document pops up into AUTH48. Perhaps at the very least, once the
new RFC structure is in place we can ask the RPC to give us a heads-up, say
a week in advance, to expect a chunk of work to arrive.

Cheers,
Andy

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Feb 2022 11:59:28 -0700

tl;dr - It's important to communicate and set expectations. I couldn't 
agree more. Let's capture that in the forthcoming I-D that I'm sure 
someone is already writing. ;-)

On 2/28/22 11:55 AM, Andrew G. Malis wrote:
> Peter and Joel,
> 
> All that said, Carsten had an excellent point when he said "Apart from 
> the technical mismatches I just brought up, there also is a scheduling 
> problem.  Doing AUTH48 even for a medium-sized document such as 
> RFC-to-be 9176 (60 PDF pages; 74 in TXT form) requires setting aside 
> some time.  Today, the RPC is essentially a black box that suddenly 
> spews a significant work order at you.  Not totally surprising (one can 
> look at the queue, look at average sojourn times, and make guesses), but 
> not plannable either."
> 
> Having been there, I agree that it can be a good amount of unplanned 
> work when a document pops up into AUTH48. Perhaps at the very least, 
> once the new RFC structure is in place we can ask the RPC to give us a 
> heads-up, say a week in advance, to expect a chunk of work to arrive.
> 
> Cheers,
> Andy
> 
> On Mon, Feb 28, 2022 at 1:08 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >>> On 2022-02-28, at 18:18, Julian Reschke <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>>>
>      >>>> are essential language/grammar/style fixes and left everything
>     else
>      >>>> alone.
>      >>>>
>      >>>
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Feb 2022 12:18:49 -0800

Peter,

I agree with you that this is a topic for RSWG.

With that said, I do think there is something useful to do here that
doesn't require the
RPC to work in everyone's preferred source tooling (although of course I
wish they
would), namely:

1. Splitting out the various phases of work to distinguish between, for
instance,
   (1) conversion to pre-RFC form (2) copy edit (3) author AUTH48 changes
   (4) final page layup, etc. Right now one has to deal with all of these
at once,
   whichis challenging.

2. A more modern toolchain for tracking changes at each stage rather than
    exchanging emails with OLD/NEW and links to stuff on a web site.

As I said, I think this would also require the RSWG, but I wanted to make
the case
that there was something to do that didn't involve boiling the ocean or
requiring
everyone to convert to .md.

-Ekr

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Feb 2022 21:23:16 +0100

> So please, let's not go there

I think it would be great to go there, but it's not entirely necessary.

There are smaller steps to improve things: break things done into
smaller change sets concentrating on individual AUTH48 tasks, and feed
them back into the ID authoring process - with the goal that the spec
authors produce a new draft where the last thing left to do is to flip
the "this is an RFC" switch.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Feb 2022 13:31:32 -0700

On 2/28/22 1:18 PM, Eric Rescorla wrote:
>     (4) final page layup, etc. Right now one has to deal with all of 
> these at once,
>     whichis challenging.

True, this would be very helpful for authors. It might even be helpful 
for the RPC.

Related to one of the earlier topics of this thread, was AUTH48 ever 
something close to 48 hours? That is: were documents cleaner before they 
were shipped off to the RPC (and thus required fewer changes in the 
final stages)?

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 09:56:38 +1300

> I'm currently on a set of docs where we've been in AUTH48 for almost 2

I don't know recall first used the "AUTH48" designation, but it was
always clear that 48 hours was aspirational and a strong hint to those
involved to do their review ASAP. That said, of course, when it does
exceed a couple of weeks we need to worry. However, that's probably
inevitable for a cluster of several inter-dependent RFCs.

I agree that it would be helpful if there was, say, a one-week
warning that AUTH48 was coming, but if it comes when any one of
the authors is about to leave on vacation or start an urgent day
job commitment, there *will* be a delay.

> everything is ok, or take their time to evaluate every change. That

Of course. And the requirement that *all* co-authors sign off is
onerous (but who else is going to check that each Author's Address
is correct in every detail?). On the other hand, I've always found
that my motivation to complete AUTH48 is very strong.
  
> are essential language/grammar/style fixes and left everything else alone.

Not fair, IMHO. The editors regularly detect logical errors or ambiguities;
that's why they are technical editors as well as copy editors. I've sometimes
disagreed with a proposed fix but never seen an editor proposing a gratuitous
change to the intended meaning. What I have seen is an editorial fix to
ambiguous syntax that gave it an unintended meaning. You can't blame the
editor for that, because it was the author(s) who created the ambiguity.

Sometimes the editors suggest bigger changes, reorganising the text for
easier understanding. That's rare, but it's part of their job. "Leaving
everything else alone" is not an option in all cases.

All this cannot, IMHO, be done disjointly as a series of "pull requests"
or an equivalent. I positively want to see the entire draft with diffs.

I think complaining about long AUTH48s is rather like complaining about
SARS-CoV-2. It's part  of nature, as long as we require a final check.
In some cases it will be complex and rely on a whole lot of people,
and that takes time. Occasionally it will reveal a real bug in the
document that requires a new rough consensus to be reached.

We should certainly track AUTH48s that take too long.

Regards,
      Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Feb 2022 16:00:21 -0500

Trimming, then posting after your quesiton..

> were shipped off to the RPC (and thus required fewer changes in the 

Your question seems to have some assumptions I do not follow.  AUTH48 
You seem to be assuming that the length of auth48 is tied to the number 
of changes the RPC makes in the document.  While I am sure that is 
sometimes true, in my experience the responsiveness of authors, and the 
degree to which they choose to be picky about changes to their prose, 
tends to have a bigger impact on the time required for auth48.

It has however been a long time since 48 hours was anything other than 
aspirational.  (I don't think it was even reliably met in the early 90s.)

Yours,
Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 28 Feb 2022 16:14:01 -0500

Peter,

I'm putting on my old-timers hat here (GET OFF MY LAWN!), but yes, back in
the Good Old Days RFCs tended to be shorter and simpler (of course, with
some exceptions), and in many/most cases AUTH48 was mostly just getting the
final signoff from the authors (or more often back then, just the one
author), with maybe one go-round of fixes back from the author(s) to the
RFC Editor (at the time, Jon or Joyce).

Cheers,
Andy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Mar 2022 08:15:37 +1100

> On 1 Mar 2022, at 5:08 am, Joel M. Halpern <[email-masked]> wrote:
> 
> It seems to me it is untenable to expect the RPC to work with the soruce form of all the authors.
> And the community has nothing resembling agreement on what the source form should be.

Thankfully, I don't think that's necessary. Things can improve significantly when the RPC avoids spurious changes to the XML in their process.

For example, up until relatively recently, they hand-linewrapped the XML they produce, introducing a lot of noise in diffs. After this was pointed out, they stopped, with the result that it's easier to recreate the XML from whatever format the authors used and compare it to what the RPC has done.

Some of the adjustments have to come on the tool side for other formats; e.g., I've been opening issues against Carsten's tool when it's not capable of producing the XML that the RPC uses.

Aside from that, guidance about how to use the XML is sorely needed; the vocabulary we've designed is sprawling and its application is not always obvious. For example, the RPC seems to always want to use <dl> to document a registry entry, but AFAICT that isn't documented anywhere, and so many authors will use other constructs (like <ul>) that need to be converted by the RPC.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 22:57:42 +0100

On 28. Feb 2022, at 21:56, Brian E Carpenter <[email-masked]> wrote:
> or an equivalent.

That is a skill that can be learned.

It definitely helps to have the 100 edits that result from a capitalization decision separated from the ones that touch the meat of a complex technical explanation.

> I positively want to see the entire draft with diffs.

I want to see that, too, but that’s a trivial result from applying the PRs.

Grüße, Carsten

---

From: David Noveck <[email-masked]>
Date: Mon, 28 Feb 2022 16:58:25 -0500

On Mon, Feb 28, 2022, 10:46 AM Michael Richardson <[email-masked]>
wrote:

> time to do the full review required.

A full review should not be necessary.  The only review should be of the
changes made by the RFC editor.   Perhaps the problem was that these were
some excessive.

I had the advantage for RFC of only having two authors.  I wound up having
to say "no we don't want to do that" a bunch of times but it didn't add too
much time since my co-author was of the same opinion.

A significant issue was that it had
> spent a long time in the Q, and authors had swapped too much context out.

Ouch!

> Basically, the best way to make it all work faster would be to just do it

Good luck with that.

Part of the problem is that there is no clear definition of what the RFC
editor is to do.  I've found them helpful on commas and split infinitives
and formatting issues.   Was the problem that the RFC editor was trying to
do too much?

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 23:08:37 +0100

On 28. Feb 2022, at 19:59, Peter Saint-Andre <[email-masked]> wrote:
> 
> tl;dr - It's important to communicate and set expectations. I couldn't agree more. Let's capture that in the forthcoming I-D that I'm sure someone is already writing. ;-)

Ah.

No.

Actually: No, no, no.

It is the job of the RPC, the tools team, the LLC, and above all the RSCE to figure this out.

The authors can give input, and may be some of this input can even take the form of I-Ds.

It is *not* the job of the authors to tell the RPC (or even figure out) how to do its job.

We can tell what works in other contexts.  How an interactive rebase could make our lives easier.
But none of us understands the whole breadth of the work that results from an organization as diverse as the IETF, or even the realities of what is needed to make an organization like the RPC work.

I know that some of this misunderstanding is baked into the new RFC editor model, but I think we’ll learn to operate this in a way that respects these realities.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 23:16:09 +0100

> So please, let's not go there

I’ll call that the classical position on this issue.

Five years ago, I would have agreed.

By now, it is pretty clear to me that this position itself is untenable.

This may sound trivial, but the authors are an integral part of the authoring process.
Throwing them off-base for the last process-step by requiring them to work in a way that is unilaterally optimized for RPC work is a good part of the AUTH48 problems we have.
(Throwing the editors off-base by requiring them to work in a way that is unilaterally optimized for the authoring process is unlikely to work, either.
But categorically denying any progress can be made in this space strikes me as suboptimal.)

Grüße, Carsten

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Feb 2022 15:23:30 -0700

> But categorically denying any progress can be made in this space strikes me as suboptimal.)

We have a classic tussle on our hands.

We'll need to figure out a balance between the interests of authors 
(recognizing that different authors work different ways) and the 
interests of the editors, while keeping an eye on the costs (not only 
financial but also time to publication and so on).

Oh, let's also recognize authors who use a cutting-edge or "best 
practice" authoring workflow today (continuous integration etc.) will 
have moved on to something even more cutting edge five or ten years from 
now.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 23:42:50 +0100

> We have a classic tussle on our hands.

I don’t think that is a tussle.
After all, the RFC editor function is interested in doing a good job.
So let’s give them the input they need.

> We'll need to figure out a balance between the interests of authors (recognizing that different authors work different ways) and the interests of the editors, while keeping an eye on the costs (not only financial but also time to publication and so on).

Well, the RFC editor function has to figure that out.
Like so many areas of work where the simple answers produce suboptimal results.

We get there not by making grand five-year plans, but by running experiments like the one the authors of RFC9180 seem to have run.
(I’m looking forward to some data from the authors and the RPC on how well that worked and what made it work.)

> Oh, let's also recognize authors who use a cutting-edge or "best practice" authoring workflow today (continuous integration etc.) will have moved on to something even more cutting edge five or ten years from now.

Now that smacks of the old “we’ll get even better later so we don’t need to get better now” argument.
(But I agree we don’t want to push the RPC into our fads (*).)

Grüße, Carsten

(*) In 2006, I would have pushed for the authors and the RPC to collaborate via subversion.  In 2022, I’m felling quite well pushing for using git (and possibly GitHub).  That doesn’t mean the the 2006 push would have been wrong in any way.  Neither subversion nor git have been/are fads.  (And they replaced CVS, which I seem to remember I used to collaborate on my first few RFCs except the one we inexplicably did in Microsoft Word.)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Mar 2022 10:09:37 +1100

A large part of the problem here is that although we've chosen a bespoke format to capture the semantics of RFCs, rather than just restricting a presentation-oriented format (like HTML), we've ended up with something that is largely presentation markup, rather than semantic markup.

For example, there really should be a <registry-entry> XML element, so that authors don't have to decide whether to use <dl>, <ul>, <ol>, <table>, or something else.

Cheers,

> On 1 Mar 2022, at 10:03 am, Toerless Eckert <[email-masked]> wrote:
> 
> How about a standard RFC-editor style-guide or prettyprint tool for XMLv3
> that converts an XMLv3 input into the preferred format of RFC-editor
> Authors could then either include this into their automation workflow
> (eg. after mradown-rfc2629), or hand-edit in that format.
> 
> Goal being to make it as simple as possible for authors to avoif
> XML style mismatch with what rfc-editor would do.
> 
> Cheers
>    Toerless
> 
> On Tue, Mar 01, 2022 at 08:15:37AM +1100, Mark Nottingham wrote:
>> 
>> 
> ---
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Mar 2022 00:17:24 +0100

> A full review should not be necessary. 

I wish that were true...

> The only review should be of the changes made by the RFC editor.   Perhaps the problem was that these were some excessive.   

The RFC editor often makes suggestions when text is unclear.
In many cases these are great, in some cases these are wrong, but easily corrected (or rejected).
The interesting cases are where the authors then need to find out what was actually meant.

>> spent a long time in the Q, and authors had swapped too much context out.

Not just in the RFC editor queue (even though a MISSREF contributed a year in my example), also in the IESG processing, which can be very focused on narrow issues (and cause a lot of Brownian motion).
Have a look at the graphics and history in

https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

WGLC in 1H2019, IESG processing until early 2021, 1 year MISSREF…
So it’s been three years since we did the final heavy lifting.
Certainly swapped out by now.

(And that was a very successful development, pretty cutting-edge when we started it in 2011, with other SDOs then picking up on the way much of the innovation in their own subset derivatives.  It just took a lot of time to get the nooks and crannies right, with several author changes and job changes with the existing authors in that time.)

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Feb 2022 15:24:36 -0800

> > A full review should not be necessary. 

IMO a full review is necessary, not least to ensure that the document
remains self-consistent and that any changes applied during editing are
uniformly applied to all relevant parts of the document, not just in the
subset of places that the editor noticed.

This is analogous to a situation that arises when doing code review.
If you change an API's semantics, you had better go around and check
all the callers of that API to see if they need adjustments, not just the
callers of the API that your test suite happens to exercise.  With
specifications we do not have the rigid rules of function names to identify
the places to check, and the safe thing to do is read the whole document
with any changes that were made fresh in mind.

-Ben

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Feb 2022 19:11:01 -0500

--On Monday, February 28, 2022 15:24 -0800 Benjamin Kaduk
<[email-masked]> wrote:

> IMO a full review is necessary, not least to ensure that the
> document remains self-consistent and that any changes applied
> during editing are uniformly applied to all relevant parts of
> the document, not just in the subset of places that the editor
> noticed.
> 
> This is analogous to a situation that arises when doing code
> review. If you change an API's semantics, you had better go
> around and check all the callers of that API to see if they
> need adjustments, not just the callers of the API that your
> test suite happens to exercise.  With specifications we do not
> have the rigid rules of function names to identify the places
> to check, and the safe thing to do is read the whole document

Carsten,

(1) Full agreement with Ben.  I'd add that, long ago, we went
directly from IESG approval to the RFC Editor to publication
without an intervening check like AUTH48.   The check was
instituted after the IESG and community were very unhappy with
how a few documents came out of that process.

(2) The alternative to something very much like AUTH48 (as Ben
describes it) is to hand the document over to the RPC when we
(the IESG or a WG) would otherwise decide it was ready for Last
Call, get it edited into final form (plus or minus RFC rather
than I-D boilerplate), and then do the Last Call and IESG review
on  the edited and finished document.  Of course that means
that, if _any_ substantive changes show up during or after Last
Call, the document would need to be edited again and go through
Last Call again.   

After noting that some other SDOs do things quite similar to
that, the community has looked at similar options several times
and concluded that the additional time and costs it would
introduce are just not worth it.  Certainly the odds that it
would save time relative to the current model are very low.  At
least most times when people have argued for going down that
path in the past, the argument as been that it would improve
quality.  Whether that is true or not, and whether the quality
improvements would be worth the costs, would probably depend on
how closely IETF participants look at those supposedly final
documents.

    john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Feb 2022 19:42:06 -0500

Replying to this, having read your later message where you refer to teh 
RPC using git (of some variety) to work with authors.

Improving the interaction between the RPC and authors is desirable. 
(Whether using git is an actual improvement may be debated.  I  presume 
it is.  But that is not the point.)

However, that is VERY different from declaring that the authors need to 
develop their IDs in the same representation the RPC willl use in git.
And conversely, it is also VERY different from declaring that the RPC 
will use the authors input format, whatever that is, in their work with 
the authors via git.
Neither of those seem likely to work for this community.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 14:01:38 +1300

> It definitely helps to have the 100 edits that result from a capitalization decision separated from the ones that touch the meat of a complex technical explanation.

Agreed, but then please note that you are asking the copy editor to take the decision about which changes are just editorial and which ones might raise issues. So either we trust the editors to get this right, or we have to check everything anyway.

The editors already do this to some extent. When you receive an AUTH48 notification, you almost always receive an immediate follow-up list points on which the editors want input. It starts like this:

>> Authors,
>> 
>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>> 

I've always spent more time on those questions than on the rest of the diffs.

FYI and FYA, in my email archive I find evidence of more or less this same discussion as far back as July 2004.

    Brian

> .

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Mar 2022 02:05:08 +0100

On 1. Mar 2022, at 02:01, Brian E Carpenter <[email-masked]> wrote:
> 
> So either we trust the editors to get this right, or we have to check everything anyway.

Of course we have to check everything.  This is just so much easier with separate commits for different changes.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Mar 2022 02:17:27 +0100

On 1. Mar 2022, at 01:42, Joel M. Halpern <[email-masked]> wrote:
> 
> Replying to this, having read your later message where you refer to teh RPC using git (of some variety) to work with authors.
> 
> Improving the interaction between the RPC and authors is desirable. (Whether using git is an actual improvement may be debated.  I  presume it is.  But that is not the point.)

I’m sure this will need to be opt-in, but for many authors collaboration via git will be an improvement.
(We are all different!)

> However, that is VERY different from declaring that the authors need to develop their IDs in the same representation the RPC willl use in git.

Well, we are made to climb down to authoring-XML (“unprepped”) for AUTH48 at the moment.
As Mark said, it is possible (with effort) to backport those changes to the source; we could generate better tool support for that as a band-aid.

So doing proper separation of edits (as supported by git) can be a first step; doing that at the source level (as opposed at the authoring-XML level) can come next.

> And conversely, it is also VERY different from declaring that the RPC will use the authors input format, whatever that is, in their work with the authors via git.

And here I disagree.

It won’t work for every format, and it will require some additional help from the authoring tools.
But, in the end, an authoring tool that makes life easier for an author is also going to make at least similar work for an editor easier.
(Modulo training, which is probably a reason this won’t work too well with exotic formats.)

Grüße, Carsten

---

From: Christian Huitema <[email-masked]>
Date: Mon, 28 Feb 2022 18:49:43 -0800

On 2/28/2022 5:17 PM, Carsten Bormann wrote:
> On 1. Mar 2022, at 01:42, Joel M. Halpern<[email-masked]>  wrote:

Maybe it is an issue of when, not how. Imagine that there was an "editor 
review" during last call, much like the other directorate review. The 
editor review could flag all the places where the text is problematic, 
maybe propose alternatives. It would then be the duty of the authors to 
fix that before the RFC progresses, and thy could do it using their own 
tools.

There would still be a final pass, going from draft format to RFC 
format. But that would arguably be much simpler, and AUTH48 could be 
just that.

-- Christian Huitema