[MMUSIC] draft-holmberg-mmusic-sdp-dtls-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 17 June 2015 17:52 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 42EFD1AC3E0 for <mmusic@ietfa.amsl.com>; Wed, 17 Jun 2015 10:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lAJHDcBZ3f7q for <mmusic@ietfa.amsl.com>; Wed, 17 Jun 2015 10:52:15 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3521A8AD0 for <mmusic@ietf.org>; Wed, 17 Jun 2015 10:52:14 -0700 (PDT)
Received: from resomta-ch2-09v.sys.comcast.net ([]) by resqmta-ch2-04v.sys.comcast.net with comcast id hVrv1q0082GyhjZ01VsDoN; Wed, 17 Jun 2015 17:52:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by resomta-ch2-09v.sys.comcast.net with comcast id hVsD1q0073Ge9ey01VsDC7; Wed, 17 Jun 2015 17:52:13 +0000
Message-ID: <5581B3CC.7010501@alum.mit.edu>
Date: Wed, 17 Jun 2015 13:52:12 -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: IETF MMUSIC WG <mmusic@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1434563533; bh=hnsTdM1QobRMKAFCxAtA7lIqDddrdImbBzlbVsmSoBg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OidwVJl/2ra65Q6rdgkikVrxcEu1jRbyO2HBCjF2gJlOZpUsmVRg3R16vDvLXtNhR 9hqK8COaEymZO6YQONKAoBc4t1vinwNooQ5Z/npvfQyF2j+HAk6PVX8ssqYCk+SW5i HFU8J/z/50o8liuKuzRsrEuHacbg4hweQRAOsB8nTCC/D4VpL3PGX6EQa0fEXKNDSo cwMwHGAWHFC8W9TTPAfBouhmYrS4JKU9XyzliVCvqq9xQtnnH/8+VngP+bQR2NJLx4 VjyrC9FF+APLGidsoQ2jd7GuNzsJu/6f5ChdoBEwqCtD6bR8QKV/yVgxq4vRfO7n6Z THglvRDizab4g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RbVZNH3TWOXKbFdqBNjryQHjKWE>
Subject: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00
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: Wed, 17 Jun 2015 17:52:16 -0000

(Resending. I initially sent to wrong address.)

Christer, I'm glad that you have submitted this document - it is needed. 
I have a few comments.

Section 5.1 starts out talking about the 'connection' attribute, but 
gives no reference. There should be a reference to RFC4145.

In section 6.3:

In the 2nd sentence ("The same...'new'...) *that* occurrence of 'new' 
should be 'existing'.

Then the following paragraph:

    If the answerer does not accept the establishment (or re-
    establishment) of the DTLS association, it MUST reject the offer

isn't right. The answerer may reject the m-line while still accepting 
the offer. (I expect that is what was intended, but it doesn't say that.)

I'd also like to dig a bit more into forking. As noted in section 4.5, 
if forking occurs, then separate DTLS associations will be made with 
each callee. In this case, those distinct DTLS associations will share 
common host candidates. (Can they also end up sharing some relay 
candidates?) Yet the 5-tuples will differ.

Now, suppose that the same endpoint then needs to make a change. For 
instance, maybe it needs to change its fingerprint. In this case it 
needs to create new DTLS associations. In that case it must also use new 
host candidates. Is it permitted to use the same (new) candidates to 
recreate *both* DTLS associations? I can't see any reason why not. I 
also don't see any specific prohibition in the text. But it would be 
good to be explicit about it.