SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    New list of nits for IDs being submitted to the IESG



    
    This IESG memo should show up on the IETF web site soon as a supplement
    to or replacement for http://www.ietf.org/ID-nits.html, but I thought
    I'd post it here now, as we have a number of drafts that are currently
    in need of nit-checking.
    
    Thanks,
    --David
    
    ---------------------------------------------------------------
    
    AD Review of I-Ds
    Date: October 4, 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
        o 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
    
    - Internet Draft boilerplate
      o Must contain boilerplate that permits publication as an RFC
        (see http://www.ietf.org/ietf/1id-guidelines.txt)
    
    - List of authors/editors
      o There should not be > 5 authors/editors
        (see http://www.rfc-editor.org/policy.html)
    - Abstract
    - Table of Contents is required if > 15 pages
    - Introduction
    - Security Considerations
    - References
      o Must be split into normative and non-normative sections
        (see http://www.rfc-editor.org/policy.html)
    
    
    
    - Author's Address
    - IPR notices
        o From RFC 2026 sec 10.4 (A) and 10.4(B) and possibly 10.4(D)
    - Copyright Notice
        o From RFC 2026 sec 10.4(C)
    
    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.
    
    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
        o 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)
        o 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
        o See RFC 2277. For most cases, this means UTF-8.
        o 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.
    
    - 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 smilint@ibr.cs.tu-bs.de.
    
    - All ABNF must be checked. Tool available from www.apps.ietf.org
        o 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, prefer use of example fqdn's
        such as foo.example.com to real-world fqdn's.
    
    - 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.
    
    3. Protocol Issues
    
    - Avoid IPv4 specificity, both IPv4 and IPv6 must be supportable
    
    - 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.
    


Home

Last updated: Fri Oct 25 21:18:56 2002
11981 messages in chronological order