[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
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
