[rfc-i] Proposed scheme for handling RFC errata

Bob Braden braden at ISI.EDU
Wed Aug 29 09:37:39 PDT 2007


Thanks for your thoughtful comments.

  *> This looks good.  Three observations...
  *> (1) Needing to distinguish among published documents (as
  *> distinct from documents being considered) by stream is an
  *> innovation with which I'm not not completely happy.  However, if

I'm sorry, I don't grok this.  How is it an innovation?  Since the
stream concept came up, we have been keeping track of the stream in our
database (which is what matters here).  Prior to that, we were keeping
track*  of the two streams IETF vs.  independent submissions.

[[*Unfortunately, for several years we were confused ourselves about
individual submissions vs independent submissions, so some of our
earlier stream designations are wrong and will have to be manually
fixed.  Even more unfortunately, this confusion is still reflected
in the publication queue organization, though we have known better
for quite a long time.  Our bad, our fix.]]

I guess we ought to make it visible in the rfc-index, and clean up
the screwed up stream classification in the queue display.

  *> we are going to do it, I suggest it is time to do it, replacing
  *> the traditional "Network Working Group" going forward with,
  *> e.g., 
  *> Internet Engineering Task Force (IETF)
  *> Internet Research Task Force (IRTF)
  *> Internet Architecture Board (IAB)
  *> Independent Submission

Keeping track of the stream in the index and queue is separable from
what appears on the RFCs.  In fact, we agree with yout.  The RFC Editor
talked to our masters about what appears on the RFC, in favor of
the change you suggest.  We were told that the IAB believes that is in
their bailiwick and are preparing a document on the subject.  We asked
to be included as a co-author on that document, and were batted down.
Bad dog; sit!  In any case, it is presumably in the pipeline.  Maybe
it would do some good if you asked the IAB yourself what the status is.

  *> (2) A side-effect of the procedures in the document is that the
  *> IESG acquires more or less permanent responsibility for
  *> AD-sponsored individual submissions, even non-standards-track
  *> ones.  Probably that is as it should be, but some IESGs have
  *> taken the whole idea somewhat more casually.  Also, if the
  *> suggestion above is followed, some of us are going to insist to
  *> the IESG that the implied claim of "IETF document" means that
  *> there needs to be an IETF Last Call and evidence of IETF
  *> consensus to publish for all IESG-sponsored ("AD-sponsored")
  *> documents.   Again, I think that is reasonable, but it may
  *> increase load on the independent submission path.

WADR, I don't think your conclusion follows from you premise here.
Whether or not they are "casual" about it, the IESG **IS** responsible
for the content and quality of non-standards track individual
submissions.  That is the implication of an RFC being an individual
submission, not an independent submission. It rtherefore seem only
reasonable that the IESG should be responsible for vetting errata to
non-standards track individual submissions.  It is their stream, after
all.  What am I missing?

  *> (3) While I'm in favor of the web and web pages, I do not
  *> believe that any component of the RFC publication model should
  *> _require_ online web access.  That implies, first, that I prefer
  *> some variation to the rfcNNNN.err.txt model (even if it is also
  *> available via a link from the HTML form of an RFC) to forms that
  *> are only web-available.  Second, it implies that the email
  *> retrieval system ("mailserv at ietf.org") and similar arrangements
  *> should return any relevant errata as well as the text of the
  *> RFC... something that you will need to work out with the IETF
  *> tools group.

Good point.

Bob Braden for the RFC Editor

  *>    john

More information about the rfc-interest mailing list