[MMUSIC] Comment on draft-ietf-mmusic-securityprecondition-00.txt

Stach Thomas <thomas.stach@siemens.com> Thu, 30 June 2005 16:12 UTC

Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28694 for <mmusic-archive@ietf.org>; Thu, 30 Jun 2005 12:12:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do243-0006Vf-72 for mmusic-archive@ietf.org; Thu, 30 Jun 2005 12:39:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1Vl-0006gk-Jg; Thu, 30 Jun 2005 12:03:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1Vj-0006gU-NW for mmusic@megatron.ietf.org; Thu, 30 Jun 2005 12:03:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27855 for <mmusic@ietf.org>; Thu, 30 Jun 2005 12:03:29 -0400 (EDT)
Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1vP-0006EJ-99 for mmusic@ietf.org; Thu, 30 Jun 2005 12:30:11 -0400
Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id j5UG3EYS010248 for <mmusic@ietf.org>; Thu, 30 Jun 2005 18:03:14 +0200
Received: from vies141a.sie.siemens.at ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j5UG3DZe005023 for <mmusic@ietf.org>; Thu, 30 Jun 2005 18:03:14 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2655.55) id <M55ZBN9K>; Thu, 30 Jun 2005 18:05:07 +0200
Message-ID: <B517DF063D33D611A2F20800060DA3268EB33E@vieg127a.gud.siemens.at>
From: Stach Thomas <thomas.stach@siemens.com>
To: "'fandreas@cisco.com'" <fandreas@cisco.com>, "'dwing@cisco.com'" <dwing@cisco.com>
Date: Thu, 30 Jun 2005 18:00:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: "'mmusic@ietf.org'" <mmusic@ietf.org>
Subject: [MMUSIC] Comment on draft-ietf-mmusic-securityprecondition-00.txt
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Fleming, Dan,
 
I think the draft in general is quite clear.
Is a WGLC planned for the near future?

Nevertheless, I propose to change the example call flows in Figure 1 and 2
to show usage of the UPDATE method for the second SDP offer/answer exchange.
It could look like this

                  A                                            B 
    
                  |                                            | 
                  |-------------(1) INVITE SDP1--------------->| 
                  |                                            | 
                  |<------(2) 183 Session Progress SDP2--------| 
                  |                                            | 
                  |----------------(3) PRACK ----------------->| 
                  |                                            | 
                  |<-----------(4) 200 OK (PRACK) -------------| 
                  |                                            | 
                  |---------------(5) UPDATE SDP3------------->| 
                  |                                            | 
                  |<----------(6) 200 OK (UDATE) SDP4 ---------| 
                  |                                            | 
                  |<-------------(7) 180 Ringing---------------| 
                  |                                            | 
                  |                                            | 
                  |                                            | 

And of course a normative reference to RFC 3262 for PRACK and RFC3311 for
the UPDATE method should be added.

Kind Regards 

Thomas 

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