One document matched: draft-ietf-newtrk-cruft-00.txt

Network Working Group                                      H. Alvestrand
Internet-Draft                                             Cisco Systems
Updates: 2026 (if approved)                                      E. Lear
Expires: April 1, 2005                                Cisco Systems GmbH
                                                          October 1, 2004


     Getting rid of the cruft: A procedure to deprecate old standards
                      draft-ietf-newtrk-cruft-00.txt

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on April 1, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

    This document describes a procedure for performing the downgrading of
    old standards described in RFC 2026, as well as BCPs, without placing
    an unreasonable load on groups charged with performing other tasks in
    the IETF.

    It defines a new group, called the "Historical Standards Committee",
    which shall recommend to the IESG downgrading or progressing
    documents on the IETF standards track.  Ultimate decisions still rest



Alvestrand & Lear        Expires April 1, 2005                  [Page 1]


Internet-Draft                  On Cruft                    October 2004


    of with the IESG, with appeal to the IAB.

1.  Introduction and history

    RFC 2026, and RFC 1602 before it, specified timelines for review of
    immature (draft or proposed) standards.  The purpose of such review
    was to determine whether such documents should be advanced, retired,
    or developed further.[1]

    This procedure has never been followed in the history of the IETF.
    Since this procedure has not been followed, members of the community
    have suggested that the retiring of a document to Historic is a
    significant event, which should be justified carefully - leading to
    the production of documents such as RFC 2556 (OSI connectionless
    transport services on top of UDP Applicability Statement for Historic
    Status) and RFC 3166 (Request to Move RFC 1433 to Historic Status).

    Such documents require significant time and effort on the part of
    authors, area directors, and the RFC Editor.  Indeed such effort
    should be reserved for advancing or maintaining immature standards.
    Hence, no document should be required for an immature standard to be
    retired.

2.  Bulk Decommissioning Procedure

    In order to decommission a standard, the level of the standard MUST
    be "proposed" or "draft" and the period of time for advancement as
    specified by RFC 2026 MUST have elapsed.  Furthermore, the Committee
    will consider no document that is being actively revised by an IETF
    working group.

    N.B.  elapse of time beyond the periods specified in RFC 2026 offers
    an opportunity and NOT a mandate for review.  The Committee should
    make a judgement as to the appropriateness of a review.

    The review procedure is as follows:
    o  For each standard to be reviewed, the Committee sends out a
       message to the IETF list and the lists deemed relevant, asking for
       implementation experience and active usage.
    o  If there are reports of implementation experience and/or active
       usage, the RFC is moved into the Committee's Individual
       Decommissioning Procedure.
    o  The Committee sends to the IESG the remaining list of documents it
       recommends be reclassified as either Historic or Outdated along
       with a record of steps taken to identify that standard"s use.
       That record should include pointers to archives, as well as a log
       of actions taken to seek out usage.




Alvestrand & Lear        Expires April 1, 2005                  [Page 2]


Internet-Draft                  On Cruft                    October 2004


    o  The IESG will issue a Last Call for community input on all
       documents in question.
    o  The IESG will respond to the Committee's recommendation with a
       message to the IETF Announcement list, indicating which standards
       are marked Historic.
    o  Remaining standards are left unchanged, and are not to be further
       considered by the Committee for at least another twelve months.

3.  Individual Decommissioning Procedure

    This procedure is intended for use when one needs to consider more
    detailed evidence before deciding what to do with a document.

3.1  Procedure

    The Committee takes input from all sources it cares to take input
    from.  As it does so it will keep an archive and a record of all such
    input.  Once it determines a recommended action, it sends a
    recommendation to the IESG along with a pointer to the record, and
    the IESG will announce this to the IETF community if it agrees with
    the recommendation.

3.2  Evaluation criteria

    The decision on when to ask for reclassification is made by the
    Committee.

    Criteria that should be considered are:

    o  Usage.  A standard that is widely used should probably be left
       alone (better it should be advanced, but that is beyond the scope
       of this memo).
    o  Implementation.  A standard that is unimplemented is a clear
       candidate to be reclassified as Historic.
    o  Potential for harm.  A protocol that is unsafe where a clearly
       superior alternative is available should be considered for
       reclassification to Historic.
    o  Interest in further work.  If there is a reasonable expectation
       that the specification will be updated or advanced within a
       reasonable timeframe, the Committee should do nothing.

4.  Selection of the Committee

    NOTE IN DRAFT: This is intended to be simple, and convey the idea
    that signing up for this is an 1-year stint, not a permanent
    position.

    The IESG will send out a call for volunteers for the Cruft Committee



Alvestrand & Lear        Expires April 1, 2005                  [Page 3]


Internet-Draft                  On Cruft                    October 2004


    once a year, and will choose from the volunteers, and appoint a
    chair.  A current member of the Committee may volunteer again if he/
    she wants to.

    The chair will report every six months via electronic mail to the
    IETF Announce mailing list on the Committee's progress.

    The Committee otherwise organizes its own work.

    The IESG may cut short the term of the Committee and send out a new
    call for volunteers if it finds that reasonable.

5.  Acknowledgments

    Members of the NEWTRK working group reviewed drafts of this memo.

6  Normative References

    [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
         9, RFC 2026, October 1996.


Authors' Addresses

    Harald Tveit Alvestrand
    Cisco Systems
    Weidemanns vei 27
    Trondheim  7043
    NO

    EMail: harald@alvestrand.no


    Eliot Lear
    Cisco Systems GmbH
    Glatt-com
    Glattzentrum, ZH  CH-8301
    Switzerland

    Phone: +41 1 878 7525
    EMail: lear@cisco.com










Alvestrand & Lear        Expires April 1, 2005                  [Page 4]


Internet-Draft                  On Cruft                    October 2004


Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

    Copyright (C) The Internet Society (2004).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.


Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.




Alvestrand & Lear        Expires April 1, 2005                  [Page 5]