Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 29 September 2015 21:26 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 862BF1B50FF for <mmusic@ietfa.amsl.com>; Tue, 29 Sep 2015 14:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, 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 6uPxRn2f1B8m for <mmusic@ietfa.amsl.com>; Tue, 29 Sep 2015 14:26:21 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599041B50FD for <mmusic@ietf.org>; Tue, 29 Sep 2015 14:26:21 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-01v.sys.comcast.net with comcast id P9RT1r0042TL4Rh019SLv3; Tue, 29 Sep 2015 21:26:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id P9SK1r00J3Ge9ey019SLxy; Tue, 29 Sep 2015 21:26:20 +0000
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B37A85E29@ESESSMB209.ericsson.se> <560A2FC9.5030809@nteczone.com> <786615F3A85DF44AA2A76164A71FE1ACDF7907B1@FR711WXCHMBA01.zeu.alcatel-lucent.com> <CAD5OKxvzw7P2x6D91mrGfkDcdvMAX+nawdJFUzU+K4k3JmysrA@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <560B01FB.2090809@alum.mit.edu>
Date: Tue, 29 Sep 2015 17:26:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxvzw7P2x6D91mrGfkDcdvMAX+nawdJFUzU+K4k3JmysrA@mail.gmail.com>
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=1443561980; bh=Vf05S6iq4Yh1W0pJgqyZFIwYy1we8uVaUTzB9SFHz4c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=DYPhtgiZBROhejcHLq9vqMqxGgO4CBc4QQcoSc8Iw3ixgs8mjbw3PPFJTxvim6P5I QKXGYvjK3XYV8d408J12/DusUwtRKvOwGhwd+49OhMLoIcY2rcKo27M9rEsVHNcQuH m24qRQzF34EyOzm4ma4xG+vYMwkF1UjcJqtxpp9c6V/LksvCVFuqi06xBTC5puQ36g lX95Fg++Ep/nYwkO4uwR6hS+4FlBnuXTEi8+SA1YFzLdIb63noVYJDeDwkubeRLiMs TBTLhYUU293LvvBdRhIl7oWKSfZEn/HoJsJ63OK1SHcDISBDpbfAiLpNzJYu+e2IXY yXrr+CQbmOEdQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/KwA-cYkRr3GUhZPQcyZUKCUCco0>
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 29 Sep 2015 21:26:22 -0000

On 9/29/15 3:40 PM, Roman Shpount wrote:
> On Tue, Sep 29, 2015 at 4:23 AM, Schwarz, Albrecht (Albrecht)
> <albrecht.schwarz@alcatel-lucent.com
> <mailto:albrecht.schwarz@alcatel-lucent.com>> wrote:
>
>     there might be another approach by qualifying the "generic"
>     attribute with protocol (stack) information.
>     Paul made a good proposal as far as I remember:
>
>     see
>     Re: [MMUSIC] SCTP-SDP: SDP connection attribute considerations
>     http://www.ietf.org/mail-archive/web/mmusic/current/msg14156.html
>
>     => a=setup ... and "And do the same thing for a=connection."
>
>
> This proposal is good except that it is unclear how to deduce which
> version of connection or setup attribute is supported by the remote end
> point. Without such indication there is a high chance that remote end
> point will not be able to correctly parse and process the connection or
> setup attribute with transport suffix.

Can you clarify what situation you are concerned about?

As long as we are defining behavior for cases that aren't currently 
supported at all, then it is simply a matter of writing the specs the 
way we want them.

Are you concerned with backward compatibility with implementations in 
the wild?

	Thanks,
	Paul