Re: Plan for Last Call

From: Tim_Ellison@uk.ibm.com
Date: Fri, Sep 22 2000

  • Next message: Ron Jacobs: "RE: XML attribute"

    From: Tim_Ellison@uk.ibm.com
    To: ietf-dav-versioning@w3.org
    Message-ID: <80256962.005C8D5D.00@d06mta07.portsmouth.uk.ibm.com>
    Date: Fri, 22 Sep 2000 17:50:52 +0100
    Subject: Re: Plan for Last Call
    
    
    
    For those, like me, who need a refresher on the process (see
    http://www.ietf.org/rfc/rfc2026.txt)
    
    The Internet specifications go through stages called "maturity levels" on
    their road to becoming a standard.  The IESG decide whether to move the
    document along the Standards Track.
    It is suggested that we go to "Last-Call" before applying for "Proposed
    Standard" maturity.  This is a notice to the group of the pending IESG
    consideration of the document, and during Last-Call comments are accepted
    from anyone.
    
    From RFC2026 (6.1.2):
    
    In a timely fashion after the expiration of the Last-Call period, the IESG
    shall make its final determination of whether or not to approve the
    standards action, and shall notify the IETF of its decision via electronic
    mail to the IETF Announce mailing list.
    
    From RFC2026 (4.1.1):
    
    The entry-level maturity for the standards track is "Proposed Standard".  A
    specific action by the IESG is required to move a specification onto the
    standards track at the "Proposed Standard" level.
    
    A Proposed Standard specification is generally stable, has resolved known
    design choices, is believed to be well-understood, has received significant
    community review, and appears to enjoy enough community interest to be
    considered valuable.  However, further experience might result in a change
    or even retraction of the specification before it advances.
    
    Usually, neither implementation nor operational experience is required for
    the designation of a specification as a Proposed Standard.  However, such
    experience is highly desirable, and will usually represent a strong
    argument in favor of a Proposed Standard designation.
    
    The IESG may require implementation and/or operational experience prior to
    granting Proposed Standard status to a specification that materially
    affects the core Internet protocols or that specifies behavior that may
    have significant operational impact on the Internet.
    
    A Proposed Standard should have no known technical omissions with respect
    to the requirements placed upon it.  However, the IESG may waive this
    requirement in order to allow a specification to advance to the Proposed
    Standard state when it is considered to be useful and necessary (and
    timely) even with known technical omissions.
    
    Implementors should treat Proposed Standards as immature specifications.
    It is desirable to implement them in order to gain experience and to
    validate, test, and clarify the specification.  However, since the content
    of Proposed Standards may be changed if problems are found or better
    solutions are identified, deploying implementations of such standards into
    a disruption-sensitive environment is not recommended.
    
    
    
    
    
    
    "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com> on 2000-09-22 05:05:02 PM
    
    Please respond to "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
    
    To:   ietf-dav-versioning@w3.org
    cc:    (bcc: Tim Ellison/UK/IBM)
    Subject:  Plan for Last Call
    
    
    
    
    Good news! The members of the Delta-V design team feel that the WebDAV
    Versioning Specification has reached the point that it is ready for Last
    Call. We would like to submit by the end of this month (September). So if
    you can, give the spec a thorough review and if you have any pressing
    issues you'd like addressed before last call, let us know within the next
    week. The duration for last call will be six weeks giving plenty of time
    for review as well as a few weeks before the December IETF to address any
    issues that come up. We'll address these issues at a Delta-V working group
    meeting and design team meetings during the December IETF with the goal to
    resolve all remaining issues.
    
    I would like to thank everyone for their hard work in producing a quality
    draft covering a complex subject area. We've got something here that will
    really make a difference enabling client applications to access resources
    managed by a number of repository managers. In particular, I'd like to
    thank Geoff Clemm for his tireless efforts in editing the many drafts, and
    for his attention to detail and thoughtful explanations of difficult
    concepts. Thanks to everyone, we've tamed the versioning beast!
    
    So let's all gear up for the big push to get this thing through last call
    so we can get some implementations in the works and continue our journey
    down the path of draft proposed standard.