Subject: [BEHAVE] RE: [MMUSIC] ICE deployment data before LC for RFC

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 17 Jul 2007 11:48:09 -0700

Keith,

Thanks for the attention and sorry our mail has crossed.

Feel free to proceed as you best think. (I have made my point as well).

Henry

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 10:56 AM
To: Henry Sinnreich; [email-masked]; [email-masked]
Cc: Cullen Jennings; [email-masked]
Subject: RE: [MMUSIC] ICE deployment data before LC for RFC

As SIP WG chair and the document shepherd for
draft-ietf-sip-ice-option-tag this is what I shall be doing with regard
to the ancillary document in this process...

I went to RFC 2026 and carefully read the section on proposed standard:

4.1.1  Proposed Standard

   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.

My judgement is that at least the in terms of its draft, the SIP WG has
fulfilled the requirements for a request to publish a proposed standard.
It appears to me that any further decision about implementation rests
with the IESG, who should obviously take into account any submissions
made during the IESG last call process.

It is therefore my intent to proceed with the publish request for
draft-ietf-sip-ice-option-tag.

Regards

Keith

________________________________

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Monday, July 16, 2007 11:38 PM
	To: [email-masked]; [email-masked]
	Cc: Cullen Jennings; [email-masked]
	Subject: [MMUSIC] ICE deployment data before LC for RFC

	The work on ICE is truly impressive and so are the numerous I-Ds
associated with ICE.

	However, before sending the <ice-17> I-D for LC to the IESG, it
would be prudent and responsible to the industry (that spends
considerable resources on ICE in good faith) implementing ICE, to either
(1) make it an informational RFC or (2) publish some deployment data
showing such items as:

	*	NAT scenarios that have been tested, 
	*	The % of success, 
	*	Performance, such as call setup delay using SIP. 

	I have not seen any such public data on ICE deployment, for
example with SIP. A private report has raised my concern about the
performance of ICE.

	In the best IETF tradition, it would also help to have open
source code available for ICE, before declaring it a standard.

	ICE is too important for the IETF (good work Jonathan and other
authors!) not to publish (1) deployment results and (2) publish open
source code as well.

	The various nits discussed on the lists are only of secondary
importance to the LC compared to the above and would get resolved with
such a process anyway.

	These are my personal two cents.

	Henry Sinnreich

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 17 Jul 2007 20:58:55 +0200

A further word on this.

Attempting to do any status change is going to create all sorts of
downreferencing problems, which while not unresolvable, will certainly
delay getting this out.

In order to register a new SIP option tag, draft-ietf-sip-ice-option-tag
must be a standards track document. RFC 3427 mandates this.

Draft-ietf-sip-ice-option-tag normatively references
draft-ietf-mmusic-ice. If the former is standards track and the latter
is either informational or experimental, I understand that would be a
down reference. 

I was unable to fire up the reference dependency tool to find out what
other intended standards track documents normatively referenced
draft-ietf-mmusic-ice, but I suspect there are a number.

I would therefore suggest you investigate the potential referencing
impact further if you wish to proceed.

Regards

Keith

> Sent: Tuesday, July 17, 2007 7:48 PM
> To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
> Cc: Cullen Jennings; [email-masked]; [email-masked]
> draft-ietf-sip-ice-option-tag this is what I shall be doing 
> with regard to the ancillary document in this process...
> 
> My judgement is that at least the in terms of its draft, the 
> SIP WG has fulfilled the requirements for a request to 
> publish a proposed standard.
> It appears to me that any further decision about 
> implementation rests with the IESG, who should obviously take 
> into account any submissions made during the IESG last call process.
> 
> It is therefore my intent to proceed with the publish request 
> for draft-ietf-sip-ice-option-tag.
> 
> Regards
> 
> Keith
> 
> 
> 	The work on ICE is truly impressive and so are the 
> numerous I-Ds associated with ICE.
> 
> 	 
> 
> 	However, before sending the <ice-17> I-D for LC to the 
> IESG, it would be prudent and responsible to the industry 
> (that spends considerable resources on ICE in good faith) 
> implementing ICE, to either
> (1) make it an informational RFC or (2) publish some 
> deployment data showing such items as:
> 
> 	 
> 
> 	I have not seen any such public data on ICE deployment, 
> for example with SIP. A private report has raised my concern 
> about the performance of ICE.
> 
> 	 
> 
> 	In the best IETF tradition, it would also help to have 
> open source code available for ICE, before declaring it a standard.
> 
> 	 
> 
> authors!) not to publish (1) deployment results and (2) 
> publish open source code as well.
> 
> 	The various nits discussed on the lists are only of 
> secondary importance to the LC compared to the above and 
> would get resolved with such a process anyway.
> 
> 	 
>