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

Network Working Group                                      H. Alvestrand
Internet-Draft                                             Cisco Systems
Updates: 2026 (if approved)                                      E. Lear
Expires: February 24, 2005                            Cisco Systems GmbH
                                                          August 26, 2004


     Getting rid of the cruft: A procedure to deprecate old standards
                   draft-alvestrand-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 February 24, 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 "Cruft Committee", which shall
    recommend to the IESG downgrading or progressing documents on the
    IETF standards track.  Ultimate decisions still rest of with the



Alvestrand & Lear      Expires February 24, 2005                [Page 1]


Internet-Draft                  On Cruft                     August 2004


    IESG, with appeal to the IAB.  A new status of "Outdated" is created.

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.

1.1  Outdated Status

    In this specification we define a new status of outdated.  The reason
    we do not simply reuse historic for everything is that there is at
    least the perceived implication that historic is dangerous.  Whether
    this is true, the distinction between merely "old and crufty" and
    "old, crufty, and dangerous" seems like a good one to make, and so we
    make it here.

1.2  Related Work

    At the time of this writing there is work under way to revamp
    standards status information.  In particular, the NEWTRK working
    group has considered a proposal to move such information into web
    pages and out of the technical documents.  This effort is
    complimentary.  Should that effort be accepted by the community, this
    document should be applied to the document describing the status of a
    given document or set of documents.

2.  New Decommissioning Procedure

    The decommissioning procedure for standards has the following steps:
    o  The Committee determines that a set of documents is eligible for
       reclassification according to RFC 2026.  It's up to the Committee
       to decide which documents to tackle next.



Alvestrand & Lear      Expires February 24, 2005                [Page 2]


Internet-Draft                  On Cruft                     August 2004


    o  The Committee attempts to find out whether there are mailing lists
       or contactable individuals relevant to the technology described in
       the documents.
    o  For each standard in question, 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.
    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 Announce list.  If it agrees to the change in
       status, the standard is marked Historic.  It may also request more
       information from the Committee or outright disagree.

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.

    Because of the time that has passed without applying the 2026 rule,
    this document describes three alternatives, not two:
    o  Maintenance on the standards track (per 2026)
    o  Reclassification as Historic (per 2026)
    o  Reclassification as Outdated.
    Maintenance on the standards track at this point demands attention
    from the IETF if a document is not full standard.  Such a document
    should either be advanced by the IESG, or a working group should be
    formed to address its shortcomings.

    Standards that are unsafe to use should be marked Historic and
    annotated as mentioned below.  The last alternative is intended for
    cases where the technology is safe, but not reasonable to advance or
    retain on the standards track.

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



Alvestrand & Lear      Expires February 24, 2005                [Page 3]


Internet-Draft                  On Cruft                     August 2004


    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  Implementations.  A spec that is unimplemented should go to
       Outdated.
    o  Usage.  A protocol or feature that is safe to use but is no longer
       generally useful should go to Outdated.
    o  Potential for harm.  A protocol that is unsafe shall be marked
       Historical.  In the latter case, the danger must be documented in
       the permanent record either with a brief RFC under current
       practice, or with a notation kept with the standard status (as
       envisioned in NEWTRK).
    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
    once a year, and will choose from the volunteers.  A current member
    of the Committee may volunteer again if he/she wants to.

    The IESG will appoint as many members to the commission as it deems
    appropriate, along with a chair.  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  Normative References

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






Alvestrand & Lear      Expires February 24, 2005                [Page 4]


Internet-Draft                  On Cruft                     August 2004


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 February 24, 2005                [Page 5]


Internet-Draft                  On Cruft                     August 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 February 24, 2005                [Page 6]