Subject: [P2PSIP] Progressing ICE

From: Colin Perkins <[email-masked]>
Date: Fri, 20 Jul 2007 12:43:30 +0100

[This note is sent to MMUSIC, with bcc to BEHAVE, SIP, and P2PSIP  
since the discussion has included those groups. Replies to MMUSIC  
only please, as ICE is an MMUSIC working group draft]

The MMUSIC chairs have reviewed the mailing list discussion  
pertaining to ICE over the last few days. While we agree that further  
implementation experience and publication of deployment results would  
be valuable, as it is for any new protocol, we do not believe this  
sufficient cause to revisit the consensus to request publication of  
draft-ietf-mmusic-ice-17.txt as a Proposed Standard.

The characteristics of Proposed Standard specifications are described  
in RFC 2026 section 4.1.1 as follows:

>    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.

Our judgement is that ICE meets these requirements, and that there is  
general working group consensus to request publication. Accordingly,  
our intention is to proceed as we previously announced, and request  
that ICE be published as a Proposed Standard RFC.

Colin Perkins, Jörg Ott, and Jean-François Mulé
MMUSIC chairs

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip