Subject: RE: A list of AD nits for IDs being submitted to the IESG

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Mon, 7 Oct 2002 10:32:02 -0400

Suggest following minor changes:

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: Monday, October 07, 2002 6:49 AM
> To: [email-masked]
> Subject: A list of AD nits for IDs being submitted to the IESG

> ...
> We'd like your comments.  Is it complete, clear? Useful?

Yes.

> Once we have integrated your feedback, we will publish the document on the 
> IETF web pages.

Below is my feedback.

> AD Review of I-Ds
> Date: October 4, 2002

> ...

> - Table of Contents is required if > 15 pages

I always include a Table of Contents.

> 1.3 Sometimes-required sections
> 
> - IANA considerations
>       o Required if IANA has to create a new registry or modify rules for
>                 an existing registry.
>       o See RFC 2434, and also RFC 2780 in some cases.

Including an IANA Considerations section is also useful if the approval
of the draft will have the effect of reserving a value.

> - Addresses used in examples should prefer use of fully qualified
>     domain names to literal IP addresses, prefer use of example fqdn's
>     such as foo.example.com to real-world fqdn's.

Add reference to RFC 2606 which lists a variety of specially reserved
domains for indicating example fqdns, invalid fqdns, and test fqdns.

> - References
>     o All references must be stable and resolvable.
>     o An HTTP URL only is not generally considered a stable reference;
>         exceptions can be made in some cases
> 
>     o In case of references to I-Ds, use the format
>           "title" (work in progress) (I-D name).
>         Normative references to IDs will cause a standards-track or BCP
>             document to wait for the referenced RFCs to be published.
>         Non-normative references will have the I-D name stripped out
>             by the RFC Editor.

Replace "I-D name" with "I-D file name" for greater clarity.

Donald

---

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Mon, 7 Oct 2002 12:28:44 -0400

Despite the desires of the W3C and their exhortations for URL stability ("Cool URL's Don't Change" http://www.w3.org/Provider/Style/URI.html) surveys commonly find between 1/4 and 1/3 of the links of the average web page to be broken. The W3C is committed to maintaining the web prescence and URL stability of all of its formal documents (Recommendations on down) and so might qualify for the exemption but few other organizations are. For example, the NIST web structurce changes occasionally in arbitrary fashion without notice, so a stable URL to a FIPS is problematic. Thus it is much better to reference a FIPS as a printed document.

Many standards organizations provide for their documents to expire in 5 years or the like, but the IETF does not do so and the longer a document is valid, the more likely URLs to it and URLs it contains will break. RFC's are like books on a shelf that are always available for reference within the IETF universe under their RFC number as an absolute identifier. There are sources of paper, CD, etc., compilations of RFCs. While an RFC may become technically irrelevant or be explicitly obsoleted by a subsequent RFC, they don't change and would always be of historic interest.

There is no defined or guarateed fixed URL for an RFC. In fact, they are referenced in slightly different ways in different places. For example, the URLs for the RFCs under ietf.org are padded to four digit numbers with leading zeros (e.g.: http://www.ietf.org/rfc/rfc0802.txt) and so might be presumed to all have to change, breaking all links using them, when RFC 10000 appears :-) while the URLs of RFCs under rfc-editor.org do not have that particular problems (e.g.: ftp://ftp.rfc-editor.org/in-notes/rfc802.txt). But I doubt that there is some finite list of such problems that could be "fixed". The time scale and dynamic nature of the Internet just makes stable URLs on it over a time scale of decades (the time scale over which the RFC series has so far extended) implausible, except in rare cases. We have many proofs by example that paper documents and the like can survive and be referenceable by title, date, and author for hundreds of years. We have no such proof for computer !
!
effemera referenced by URL.

Donald

-----Original Message-----
From: The Purple Streak, Hilarie Orman [mailto:[email-masked]]
Sent: Monday, October 07, 2002 11:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: A list of AD nits for IDs being submitted to the IESG

Inimitably, on Mon, 07 Oct 2002 at 12:48:41 +0200 Harald Tveit
>        exceptions can be made in some cases

I've seen objections to using citations that contain a URL but have no
title or author, on the grounds that if the content moves then even a
search engine cannot find it.  But the statement above seems to be
even stronger - a prejudice against publications done solely through
the Internet.  Like RFC's.  Would they generally qualify for an exception
in some cases?  Why?

Hilarie

---

From: "Harrington, David" <[email-masked]>
Date: Mon, 7 Oct 2002 14:08:59 -0400

Hi,

[email-masked] is under change control of its authors. I think it
is important to have an IETF-approved version of the utility if we want to
insist that authors check their mibs before submission. 

I recommend asking the authors if they would be willing to provide a version
with the needed fixes, minus the author's preferences (or a switch to
disable them), for use by the IETF. Then I recommend making that version
available from www.ietf.org.

dbh
---
David Harrington            
[email-masked]           
co-chair, IETF SNMPv3 WG

> From: Andy Bierman [mailto:[email-masked]]
> Sent: Monday, October 07, 2002 1:33 PM
> To: Harald Tveit Alvestrand
> Cc: [email-masked]
> At 12:48 PM 10/7/2002 +0200, Harald Tveit Alvestrand wrote:
> >>...
> >- All MIBs must compile cleanly using "smilint -l 9"
> >   o An email service is available for the check.
> >       Extract the MIB form the document and send it
> >       in the body of an email to [email-masked].
> 
> This is a good idea in theory, but the practice has some problems:
> 1) all messages beyond -l4 are not errors and represent the
>    smilint authors preferences, not SMIv2 rules
> 2) there are valid SMIv2 constructs that smilint flags as errors,
>    which need to be ignored
> 3) there are invalid SMIv2 constructs that smilint misses, which
>    need to be fixed
> 
> Andy
>  
>