[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC Errata Delinquents

Bob,

some thoughts here, none of which may be directly helpful:

- in order to make those calls for verification, you seem to need to maintain an updated address archive for authors. Do you in fact maintain such an archive? If so, how do you get updates?

- for "Status: UNKNOWN" RFCs like 724, it seems appropriate to ask the authors to comment on the technical validity of the errata. But for a Draft Standard like RFC 2046, it seems to me that if the errata actually introduces technical change, it needs community verification, not just author verification. Who defines (or should define) the procedure for RFC Errata vetting, and where is it documented?

- in the interest of the errata mechanism remaining lightweight, I might suggest something like saying "if the author cannot be contacted, the errata will be verified with at least one expert in the field of the RFC in question, and will be posted with a note saying 'Note - not verified with authors'" after a timeout on the author request.

More discussion may be in order....

--On 11. september 2003 09:09 -0700 Bob Braden <braden@ISI.EDU> wrote:



IESG,

When someone reports an erratum for a published RFC, the RFC Editor
obtains verification from at least one of authors before posting the
item on our Errata web page.  Recently we have been getting no response
from a number of authors -- see list below.  Most of these appear to be
technical rather than merely typographic changes, BTW.

If you have a suggestion on how we could get more cooperation, we would
appreciate hearing it.

Thanks!

RFC Editor
_________________________________________________________

RFC 724 - "Proposed official standard for the format of ARPA Network
messages" D. Crocker; dcrocker@brandenberg.com
K.T. Pogran; UNKNOWN email
J. Vittal; UNKNOWN email
D.A. Henderson; UNKNOWN email

RFC 2046 - "Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types" N. Freed; ned.freed@mrochek.com
N. Borenstein; nsb@nsb.fv.com

RFC 2132 - "DHCP Options and BOOTP Vendor Extensions"
S. Alexander; sca@engr.sgi.com
R. Droms;  droms@bucknell.edu

RFC 2426 - "vCard MIME Directory Profile"
F. Dawson; Frank_Dawson@Lotus.com or fdawson@earthlink.net
T. Howes; howes@netscape.com

RFC 2518 - "HTTP Extensions for Distributed Authoring - WEBDAV"
Y. Goland; yarong@microsoft.com
E. Whitehead; ejw@ics.uci.edu
A. Faizi; asad@netscape.com
S. Carter; srcarter@novell.com
D. Jensen; dcjensen@novell.com

RFC 2633 - "S/MIME Version 3 Message Specification"
B. Ramsdell; blaker@deming.com

RFC 2679 - "A One-Way Delay Metric for IPPM"
G. Almes; almes@advanced.org
S. Kalidindi; kalidindi@advanced.org
M. Zekauskas; matt@advanced.org

RFC 2681 - "A Round-trip Delay Metric for IPPM"
G. Almes; almes@advanced.org
S. Kalidindi; kalidindi@advanced.org
M. Zekauskas; matt@advanced.org

RFC 2733 - "An RTP Payload Format for Generic Forward Error Correction"
J. Rosenberg; jdrosen@dynamicsoft.com
H. Schulzrinne; schulzrinne@cs.columbia.edu

RFC 2740 - "OSPF for IPv6"
R. Coltun; rcoltun@siara.com
D. Ferguson; dennis@juniper.net
J. Moy; jmoy@sycamorenet.com

RFC 2834 - "ARP and IP Broadcast over HIPPI-800"
J.M. Pittet; jmp@sgi.com or jmp@acm.org

RFC 2919 - "List-Id: A Structured Field and Namespace for the
Identification  of Mailing Lists"
R. Chandhok; chandhok@qualcomm.com
G. Wenger; gwenger@qualcomm.com




----- End Included Message -----


----- End Included Message -----