From extest-admin@lists.bell-labs.com Sun Dec 1 05:21:09 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02261 for ; Sun, 1 Dec 2002 05:21:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gB1AO0222088 for ; Sun, 1 Dec 2002 05:24:00 -0500 Date: Sun, 1 Dec 2002 05:24:00 -0500 Message-Id: <200212011024.gB1AO0222088@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: spirits-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, spirits-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for spirits-archive@lists.ietf.org: List Password // URL ---- -------- spirits@lists.bell-labs.com unmora http://lists.bell-labs.com/mailman/options/spirits/spirits-archive%40lists.ietf.org From spirits-admin@lists.bell-labs.com Mon Dec 16 11:05:50 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09103 for ; Mon, 16 Dec 2002 11:05:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gBGG82200856; Mon, 16 Dec 2002 11:08:07 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gBGG7S200842 for ; Mon, 16 Dec 2002 11:07:28 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id gBGG7NhN057716 for ; Mon, 16 Dec 2002 11:07:23 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id B95C0443A5; Mon, 16 Dec 2002 11:07:18 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 8DB83443A4 for ; Mon, 16 Dec 2002 11:07:18 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gBGG7Ga72996 for ; Mon, 16 Dec 2002 11:07:16 -0500 (EST) Received: from pop-3.dnv.wideopenwest.com (gtwy.nap.wideopenwest.com [64.233.207.11]) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id gBGG6hoJ093173 for ; Mon, 16 Dec 2002 11:06:43 -0500 (EST) Received: from ieee.org (d233-144-198.nap.wideopenwest.com [64.233.198.144]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id gBGGEJX31479; Mon, 16 Dec 2002 10:14:19 -0600 Message-ID: <3DFDFA40.1020301@ieee.org> From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: spirits@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------080509020506010009050109" X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Subject: [SPIRITS] IETF Guidelines for I-Ds Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 16 Dec 2002 10:07:28 -0600 This is a multi-part message in MIME format. --------------080509020506010009050109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ladies and Gentlemen, IESG and our ADs require all authors to submit new IDs for publication using the attached guidelines: http://www.ietf.org/ID-nits.html Kind regards, Alec --------------080509020506010009050109 Content-Type: text/html; charset=us-ascii; name="www.ietf.org/ID-nits.html" Content-Disposition: inline; filename="www.ietf.org/ID-nits.html" Content-Base: "http://www.ietf.org/ID-nits.html" Content-Location: "http://www.ietf.org/ID-nits.html" Content-Transfer-Encoding: 7bit AD Review of I-Ds

AD Review of I-Ds

Date: November 2, 2002

All Internet Drafts which are offered for publication as RFCs must conform to the following requirements or they will be returned to the author(s) for revision.

The WG Chairs are responsible for having this list checked before submission to the ADs.

The content issues have to be checked early in the development of documents, being technically integral. The WG Chairs are responsible for this.

The ADs will check the list before submission to the IESG.

Responsibility for all checking is with the authors the case of an individual submission.

1. Form nits:

1.1 Formatting

  • See Section 3, "Instructions to RFC Authors" (draft-rfc-editor-rfc2223bis-02.txt) for details and further rules.
  • Not beyond the 72nd column of a line
    This is especially important for diagrams and code, which the RFC Editor may not be able to trivially reformat to fall within the margins.
  • Must be ragged right
  • No hyphenation for line-breaks
  • No footnotes
  • ASCII-only, no control characters (other than CR, NL & FF)
  • Do not number the "Status of Memo" or Abstract sections
  • Do not add a numbered reference in the ID boilerplate to RFC 2026 (makes it harder for the RFC editor to process the document when they strip off the ID boilerplate)
  • Reasonably well formatted for readibility and clarity.
  • Use network byte order in diagrams (see draft-rfc-editor-rfc2223bis-02.txt section 3.4)

 

1.2 Required sections - all IDs

1.3 Sometimes-required sections

  • IANA considerations
    • Required if IANA has to create a new registry or modify rules for an existing registry.

    • Required if the document requires IANA to assign or update values in an IANA registry before RFC publication

    • See RFC 2434, and also RFC 2780 in some cases.

2. Content issues

  • Abstract
    • o Should be meaningful to someone not versed in the technology; most abbreviations must be expanded on first use
    • o no citations
    • o See: draft-rfc-editor-rfc2223bis-02.txt section 4.5.
  • Security Considerations section
    Must have meaningful exploration of security issues raised by proposal, should include both risks and description of solutions or workarounds
  • If MUST etc used, the terms must be defined (or RFC 2119 referenced)
    Also read RFC 2119 to see what it says about using MUST etc
  • Specific IPR (e.g., patent claims & terms) must not be in an RFC - any claims must go to the IPR web page and notice that there is some IPR claim (RFC 2026 sec 10.4(D) must be included in the RFC
  • All user-visible text fields must be internationalizable
    See RFC 2277. For most cases, this means UTF-8.
    If text fields are included in some calculation, like matching, sorting etc, it must be described in detail how those operations are applied to the Unicode/ISO 10646 character set. see "stringprep" for more information on the recommended way of handling comparisons.
  • Use of formal languages should be in conformance with the IESG statement on the use of formal languages - See

    http:// www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt

    In particular:

    • All MIBs must compile cleanly using "smilint -l 9"
      An email service is available for the check.
      Extract the MIB form the document and send it in the body of an email to smilint@ibr.cs.tu-bs.de.
    • All ABNF must be checked. Tool available from href="http://www.apps.ietf.org"> www.apps.ietf.org
      See RFC 2234 for information about IETF ABNF. Include reference to RFC 2234.
  • Addresses used in examples should prefer use of fully qualified domain names to literal IP addresses, and prefer use of example fqdn's such as foo.example.com to real-world fqdn's
    See RFC 2606 for example domain names that can be used
    There is also a range of IP addresses set aside for this purpose. These are 192.0.2.0/24 (see RFC 3330). Private addressess that would be used in the real world should be avoided in examples.
  • References
    • o All references must be stable and resolvable.
    • o A bare HTTP URL is not generally considered a stable reference.
      For Web-only documents, adding a reference number, title and/or an author will help make the reference more stable.
    • Judgment can be used here; the stability of normative references is more important than the stability of informative references.
    • o In case of references to I-Ds, use the format author "title" (I-D file 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 file name stripped out by the RFC Editor and replaced with (work in progress).

3. Protocol Issues

  • Avoid IPv4 specificity. Both IPv4 and IPv6 must be supportable, unless the protocol is naturally IPv4 specific or IPv6 specific.
  • No application can cause catastrophic congestion. See RFC 2914 for details - applications using TCP or SCTP will normally fulfill this automatically.
  • If any sort of end-to-end checksum or integrity check is being used (especially, but not limited to, cryptographic checksums or MACs), specify precisely the contents of the fields to be checksummed, and exactly what order the operations are done in. Pay special attention to any area reserved for the checksum itself.
--------------080509020506010009050109-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits