Re: [MMUSIC] Re: ADs - Re: Status of draft-ietf-mmusic-sdescriptions-12.txt?

Colin Perkins <csp@csperkins.org> Wed, 08 February 2006 09:22 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6lXF-0000Ed-L3; Wed, 08 Feb 2006 04:22:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6lXC-0000Cj-BV for mmusic@megatron.ietf.org; Wed, 08 Feb 2006 04:22:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03085 for <mmusic@ietf.org>; Wed, 8 Feb 2006 04:20:56 -0500 (EST)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6ljc-0004Hz-FJ for mmusic@ietf.org; Wed, 08 Feb 2006 04:35:37 -0500
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63888 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1F6lWa-0003kJ-Gn; Wed, 08 Feb 2006 09:22:08 +0000
In-Reply-To: <4C9E629C-F08C-4D3F-80DA-F2F70C9DFE95@cisco.com>
References: <24EAE5D4448B9D4592C6D234CBEBD59701503196@stntexch03.cis.neustar.com> <05A1B749-4885-4A86-99EC-C898F8C1FADB@csperkins.org> <4C9E629C-F08C-4D3F-80DA-F2F70C9DFE95@cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1363A77E-D304-4A9A-983A-608C9B1F13A3@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [MMUSIC] Re: ADs - Re: Status of draft-ietf-mmusic-sdescriptions-12.txt?
Date: Wed, 08 Feb 2006 09:22:05 +0000
To: IETF MMUSIC working group <mmusic@ietf.org>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: Flemming Andreasen <fandreas@cisco.com>, Dan Wing <dwing@cisco.com>, Mark Baugher <mbaugher@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>, Allison Mankin <mankin@psg.com>, Brian E Carpenter <brc@zurich.ibm.com>, Joerg Ott <jo@acm.org>
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org

Folks,

In the interests of making progress, please provide any comments on  
this proposal to the mailing list before 15th February.

Colin



On 8 Feb 2006, at 03:01, Mark Baugher wrote:
> Hello,
>
> An issue arose during RFC Editor review of draft-ietf-mmusic- 
> sdescriptions-12 just prior to publication.  An Internet Draft  
> document, Security Preconditions, appears among the Normative  
> references.  The authors did not intend for it to be a Normative  
> reference; it should have been in the Informative References  
> section.  Still, this triggered a review and discussion.  Before  
> proceeding to publication, the chairs and ADs wish for the WG to  
> consider some of the issues of publishing draft-ietf-mmusic- 
> sdescriptions without Security Preconditions.
>
> SDP security descriptions (sdesc) as defined in draft-ietf-mmusic- 
> sdescriptions-12.txt is designed to support a variety of signaling  
> protocols that use SDP.  One of the most important is SIP. The way  
> sdesc is defined, an answer has to be received before incoming  
> media can be processed correctly by the offerer; this is  
> unavoidable in cases where there are multiple crypto suites among  
> the SDP offers.  Without the answer, there is no way to determine  
> which crypto offer has been selected by an answerer that sends  
> media upon receiving the first SDP message.  This is a problem  
> whenever media commences prior to receipt of the SDP answer.
>
> The authors recognized this problem while working on the sdesc  
> specification, and as a result, two of the authors wrote Security  
> Preconditions (see draft-ietf-mmusic-securityprecondition-01.txt).  
> However not everyone in the SIP community likes preconditions due  
> to the added state machine complexity and signaling latency.  The  
> current sdesc merely offers security preconditions as one possible  
> solution, however it incorrectly lists it as a Normative reference.  
> One alternative has already been offered (draft-wing-mmusic-sdes- 
> early-media-00.txt) and at least one more extension to sdesc to  
> address these issues is in the works.
>
>  In lieu of the above, the authors would like to change the current  
> Normative reference to security preconditions to be an Informative  
> reference instead. There is a concern, however, that with such a  
> change, we would not have a complete normative solution for SIP.   
> So, we're asking the WG members for comments.  draft-ietf-mmusic- 
> sdescriptions-12.txt has finished last call in the WG and the IESG,  
> but the document that completed last call relied upon security  
> preconditions, which may not be the ultimate solution.  We would  
> like to know if anyone in the WG objects to progressing this I-D  
> without security preconditions being normative and without another  
> normative solution to address the above issues. If you object,  
> please speak up and let us know what the normative solution should be.
>
> Thanks,
>
> Mark, Flemming & Dan
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic