Subject: [newtrk] issue lists & errata

From: Larry Masinter <[email-masked]>
Date: Wed, 16 Jun 2004 09:41:07 -0700

I made several suggestions for improving IETF practice; one of them
was to regularize and support the maintenance of 'issue lists'. I thought
I might do a quick survey of issue lists on the web, to see if there
might be a 'best practice'. Googling for 'rfc issue list', I came
across:

http://gbiv.com/protocols/uri/rev-2002/issues.html
   is the issue list for RFC 2396 (draft standard) -> standard
http://www.webdav.org/wg/rfcdev/issues.htm
   is the issue list for RFC 2518 (proposed standard) -> draft standard

http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm
   is the issue list for RFC 3253 (proposed standard) -> draft standard

http://www.w3.org/Protocols/HTTP/Issues/
   was the issue list for HTTP proposed standard -> draft standard

http://www.softwarestudio.org/iCal/2445Issues.html
    is an issue list for RFC 2445 (I don't know status)

I'm not sure the practice of maintaining issue lists is common for
other IETF specifications. It seems to be used in other organizations:

http://www.w3.org/2000/xp/Group/xmlp-issues
http://www.w3.org/2001/ppwg/rf-patent-policy-lc-issues.html
http://www.w3.org/2003/06/09-dom-core-issues/issues.html
http://www.w3.org/2001/sw/WebOnt/webont-issues.html
http://www.w3.org/XML/2001/05/xinclude-issues
http://www.w3.org/2001/XKMS/Drafts/XKMS20021017/xkms-issues-list.html
http://www.w3.org/2000/05/12-xmlschema-lcissues.html
http://www.w3.org/2001/tag/issues.html

http://www.hixie.ch/specs/xbl/issues.html

On the other hand, RFCs have errata, which are like 'resolved
issues',  but have no official status:

    http://www.rfc-editor.org/errata.html

What's "best current practice" here? Personally, I think each issued
RFC (or at least standards track RFC) having an easy to find, standard
web page which contains (or points to) the issue list for it would
help with many of the problems identified in the IETF standards track.

Larry

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Jun 2004 11:37:28 -0600 (MDT)

Larry,

	FWIW, I have tried to discuss errata maintenance with RFC
Editor in April:
http://www.rfc-editor.org/pipermail/rfc-interest/2004-April/000062.html

I was not very optimistic, but was still surprised by the "it's seems
fine and who needs errata anyway?" response:
http://www.rfc-editor.org/pipermail/rfc-interest/2004-April/000069.html

I tried to identify specific needs and improvement directions, but got
no response.
http://www.rfc-editor.org/pipermail/rfc-interest/2004-April/000071.html

It looks like there is just no sufficient enthusiasm/understanding on
the other side. There were a few useful errata suggestions/ideas from
other folks on that thread. Hopefully, grass roots demand will be
enough to trigger changes, but I am more pessimistic about that than I
was in April.

	Thanks for posting your quick survey results. I hope your
pointers will be useful for NEWTRK, ICAR and other IETF efforts.

Alex.

.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 16 Jun 2004 14:01:10 -0700

> 	FWIW, I have tried to discuss errata maintenance with RFC

'errata' are explicitly limited to changes that do not
change the sense of a document

  www.rfc-editor.org/errata.html: 
  "Suggested changes that appear to modify the sense of
  an RFC will not be posted"

but the issue lists are part of progressing documents
from one level of maturity to the next, and frequently
do include technical changes.

If we make 'issue maintenance' part of the formal standards
track process (where issues can be raised, solutions including
technical changes that modify the sense of the document can
be proposed and at least tentatively accepted), then it
will facilitate the "new track", and might also subsume
the 'RFC editor errata' for those issues which are deemed
to be editorial in nature.

Larry

.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Jun 2004 16:39:04 -0600 (MDT)

> change the sense of a document

... but may include important technical changes (e.g., protocol bug
fixes).

>   an RFC will not be posted"

While "sense of a document" is not defined, I think most will agree
that the "same sense" limit is there to avoid new functionality to be
introduced or old working functionality to be changed in the protocol.

> but the issue lists are part of progressing documents from one level
> of maturity to the next, and frequently do include technical
> changes.

Yes, of course. Issue tracking involves more than what RFC errata
involves, but both would benefit from IETF support and can use the
same set of IETF-managed tools.

> If we make 'issue maintenance' part of the formal standards track
> process (where issues can be raised, solutions including technical
> changes that modify the sense of the document can be proposed and at
> least tentatively accepted), then it will facilitate the "new
> track",

Yes, absolutely.

> and might also subsume the 'RFC editor errata' for those issues
> which are deemed to be editorial in nature.

RFC errata is not limited to editorial changes (i.e., typos).  Errata
entries often contain protocol-level bug fixes. Just look at HTTP (RFC
2616) errata, for example. That's why RFC errata is both very
important and similar enough to issue tracking.

In short, errata is an issue tracking after a document has been frozen
as an RFC (with all the side-effects that implies).

Alex.
.