[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 [127.0.0.1]) 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-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 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 ([69.252.207.105]) 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 ([50.138.229.151]) 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 [RFC3264]. 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. Thanks, Paul
- [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00 Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00 Roman Shpount
- Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00 Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00 Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00 Christer Holmberg