Subject: Re: RFC-Editor 48-hour process (was: Input solicited: IETF probl em pi npointing at the plenary?)

From: Bob Braden <[email-masked]>
Date: Fri, 15 Nov 2002 20:00:54 GMT

*> >
  *> > I would *love* to have been able to describe corrections during
  *> > the last round of RFC-edits in nroff terms.  When there are problems
  *> > with layout, indentation, and so on, it'd be much easier than sending
  *> > text diffs back and forth.
  *>
  *> Hi Randy-
  *>
  *> FYI, the RFC Editor prefers to have the AUTH48 changes submitted in
  *> the OLD:..., NEW:... format to make it easier to ensure that no
  *> technical (i.e., substantive) changes get slipped in at the last
  *> minute.  There have been times in the past where this has occured and
  *> it allows the relevant AD to be flagged to gain their approval.
  *>
  *> --aaron (who is supporting the RFC Editor)
  *>

And I would add that the RFC Editor team is aware that the present
encoding of AUTH48 changes is clumsy, and we would be happy to find a
better alternative.  However, Aaron Falk's point is right to the mark.
Those not directly involved with the process may not be aware that this
issue (last minute changes that are actually substantive) comes up
quite often.  This same issue comes up with the use of CVS.

Bob Braden for the RFC Editor

---

From: Robert Sparks <[email-masked]>
Date: 25 Nov 2002 13:26:27 -0500

So the requirement is to preserve, or better improve, the ability
to recognize substantive changes. Providing edits through a version
control system seems to only make that better. I _think_ it would
not be too difficult to provide a program that would take version
n-1 and version n of the nroff source and render a document in
the OLD:/NEW: form, so at the very least, no capabilities would be lost.

So, guarding against substantive changes shouldn't be used as an
argument against using a system like CVS for providing AUTH48 edits.

RjS