Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 20 June 2015 17:47 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62EC1A8A4A for <mmusic@ietfa.amsl.com>; Sat, 20 Jun 2015 10:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAXkniVkCD-E for <mmusic@ietfa.amsl.com>; Sat, 20 Jun 2015 10:47:14 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951441A8A49 for <mmusic@ietf.org>; Sat, 20 Jun 2015 10:47:13 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with comcast id ihmd1q0032Udklx01hnCWY; Sat, 20 Jun 2015 17:47:12 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id ihnC1q00F3Ge9ey01hnCUk; Sat, 20 Jun 2015 17:47:12 +0000
Message-ID: <5585A71F.4080808@alum.mit.edu>
Date: Sat, 20 Jun 2015 13:47:11 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D8F4457@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F4457@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1434822432; bh=Vm3wu2EMzwZs16SZgiGbrZmkIU2xnz/LHgfDx1Lqzkg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dwokKIBrw2IRY6A2/fDrx65NCNZqg2MWcCyjX2KHQAJMxatO+3DFR/EIdurHUrQVm cX6RVojzG8xibdGkWIjGJDgpnzqlPQOy8WHoucio0pX+p+c0BXwiHCg4sX+j4IxbE9 EM8552l7wtoGlwKJN6m9KTJijczUFgxyG/auleURTxz7smhi3rVKLxq1OsxccODFly /p0Ti941utF4gGCGMrFoM5zX4pNm8yEEeEeHMc7VsG/7KqGImprQQdlQpnD4S7X3+l bvtFQL5QavE+o5OlE9AFf/mArrR5M6sROt1Nux5odxaEWhHQ9UECDXY1pja9HK3QJY UlDEa3Ghn+i3g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/1_IjB1GS8X4uD3P85F35SRw5AYs>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jun 2015 17:47:15 -0000

I have a few comments on this version:

* Section 2.1:

    When a new DTLS association is established, an endpoint MUST use a
    new set of transport parameters (IP address and port combination).

The above seems slightly ambiguous: does "an endpoint" mean "each 
endpoint" or "one (of the two) endpoints"?

IIUC we have established that the important point is that the 5-tuple 
must change. So at least one side must change the address or port. But 
if one side is known to do so, then the other side need not do so. So I 
suggest changing the above to:

    When a new DTLS association is established, one of the endpoints
    MUST use a new set of transport parameters (IP address and port
    combination).

But there may be more to sort out about the o/a protocol for 
guaranteeing this. I can see a few:

- if the offer has connection:new then the offer must have new
   transport parameters. Else, if the offer has connection:existing
   but the answer has connection:new then the answer must have new
   transport parameters.

- if the answer has connection:new and the offer didn't have new
   transport parameters, then the answer must have new ones.

Something about the above should probably go into section 6.

* Section 5.1

    A 'connection' attribute value of 'new' indicates that a new DTLS
    association MUST be established.  A 'connection' attribute value of
    'existing' indicates that a new DTLS association MUST NOT be
    established.

I think this is wrong - that the answerer is permitted to answer with 
connection:new.

* Section 6.3

    If an answerer receives an offer that contains an SDP 'connection'
    attribute with a 'new' value, the answerer MUST insert a 'new' value
    in the associated answer.  The same applies if the answerer receives
    an offer that contains an SDP 'connection' attribute with a 'new'
    value, but the answerer determines (based on the criteria for
    establishing a new DTLS association) that a new DTLS association is
    to be established.

I think I previously commented on this: the 2nd sentence "The same 
applies if ... attribute with 'new' value ...". *That* 'new' should be 
'existing' - it is covering an alternative to the first sentence. And 
this aligns with my comment above about section 5.1.

	Thanks,
	Paul