Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 19 April 2017 07:52 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E613149B for <mmusic@ietfa.amsl.com>; Wed, 19 Apr 2017 00:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CCYjq-lrub9Q for <mmusic@ietfa.amsl.com>; Wed, 19 Apr 2017 00:52:12 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D7D131549 for <mmusic@ietf.org>; Wed, 19 Apr 2017 00:52:11 -0700 (PDT)
X-AuditID: c1b4fb3a-baef298000005492-e3-58f7172ad97a
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 76.2A.21650.A2717F85; Wed, 19 Apr 2017 09:52:10 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Wed, 19 Apr 2017 09:51:46 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, Roman Shpount <roman@telurix.com>
CC: Ben Campbell <ben@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "Paul Kyzivat" <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572
Thread-Index: AQHSuHh8UB3Rm+4deESPQDlsxlQ7eaHLp62AgAC7HgCAAAHYAA==
Date: Wed, 19 Apr 2017 07:51:45 +0000
Message-ID: <D51CF259.1B44B%christer.holmberg@ericsson.com>
References: <CAD5OKxuBp6=EJTmVr6RLFv_w6-gnfOgNkmCiCjRs847KBd8oiw@mail.gmail.com> <CABkgnnVLA8KfAZ6DiU6PyAHeT1mfa32RgohTXr62UUjjD+ddvQ@mail.gmail.com> <D51CF012.1B43D%christer.holmberg@ericsson.com>
In-Reply-To: <D51CF012.1B43D%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A55762CB0B025C45B9CD2988628732BC@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7t66W+PcIg6mrJS3md55mt7h25h+j xdTlj1ksVmw4wGox48JUZgdWj7/vPzB57Jx1l91jyZKfTB6zdj5h8bg1pSCANYrLJiU1J7Ms tUjfLoEr4+yuy+wFZ6QrJjfwNTDuFuti5OSQEDCR6Hy+j6WLkYtDSGA9o8T7n+2MEM4SRonX h/cydzFycLAJWEh0/9MGiYsItDFKfOpvZwfpZhYolJh68ysbiC0sECgx5/0VMFtEIEii/dwB dgjbSWL6pN9gc1gEVCV+b0oFCfMKWEtcuLKXBcQWEjjJKDHhdzaIzSlgI3H50UUmEJtRQEzi +6k1TBCrxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7GC2KICehL7/kGcIyGgKPHx1T5GiF49iRtT p7BB2NYSqxZtg4prSyxb+JoZ4h5BiZMzn7BMYBSfhWTdLCTts5C0z0LSPgtJ+wJG1lWMosWp xcW56UZGeqlFmcnFxfl5enmpJZsYgXF6cMtvqx2MB587HmIU4GBU4uF9IP0tQog1say4MvcQ owQHs5II77oPXyOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi 4JRqYEw+zM7upqNtbaOaslyeV7jm7uuK6V8nzt2bcuL73venLmWua0/aox9rrPygrXZtgfSa 2XFbDBw6J7bd28+U/nRrW96T/KPmDmdvH3n27cu+ZbKrzjPw3L7K1OB49damNE6ZuzvylFKM 5nAc3KdoeK6Fob7myKEjOyP+rlrlt/jKoi9/a9b+zPBXYinOSDTUYi4qTgQAkc6nec8CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/orH61gVLNAkDa6uGwL-mCOrHNn4>
Subject: Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 19 Apr 2017 07:52:15 -0000

Hi,

Sorry, I messed up the RFCs.

I do NOT think we need to update 8122. The text says that the new
procedures are used ³in conjunction² with the 8122 procedures, and the
text suggested by Paul fits into that.

Regards,

Christer


On 19/04/17 10:45, "mmusic on behalf of Christer Holmberg"
<mmusic-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>
wrote:

>Hi,
>
>I agree that the draft should be an update to 8122 (not 4572). That was
>actually my intention, but I forgot about it.
>
>The changes suggested by Paul look good.
>
>Regards,
>
>Christer
>
>
>
>On 19/04/17 02:39, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
>>I agree with Roman, we can and should just ensure that this is a new
>>feature, not a rewrite.  I don't think that we need to invalidate RFC
>>4572 implementations.  This is an enhancement (a very useful one, but
>>an enhancement only).
>>
>>p.s., Any updating should be done to RFC 8122 now, if at all.  That
>>probably removes any heat from the discussion as pertains to updating
>>of old specs.
>>
>>On 19 April 2017 at 05:17, Roman Shpount <roman@telurix.com> wrote:
>>> Re-sending to mmusic list and changing the title:
>>>
>>> On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>
>>> wrote:
>>>>
>>>> Section 8 has a number of normative requirements around the use of
>>>> 'tls-id'. This seems to break interoperability with existing
>>>>implementations
>>>> that follow RFC4572.
>>>>
>>>> What is the intent here regarding interoperability with RFC4572?
>>>> Perhaps this doc should now also be a formal update to that.
>>>
>>>
>>> Should we reword those requirements that they only apply when tls-id is
>>> used?
>>>
>>> So instead of
>>>
>>> If an offerer or answerer inserts an SDP 'connection' attribute with a
>>>'new'
>>> value in the offer/answer, the offerer/answerer MUST also insert an SDP
>>> 'tls-id' attribute with a new unique value.
>>>
>>> We would say:
>>>
>>> If an offerer or answerer inserts an SDP 'connection' attribute with a
>>>'new'
>>> value in the offer/answer and also provides SDP 'tls-id' attribute, the
>>> value of tls-id' attribute MUST be new and unique.
>>>
>>> And instead of
>>>
>>> If an offerer or answerer inserts an SDP 'connection' attribute with a
>>> 'existing' value in the offer/answer, and if a previously established
>>>TLS
>>> connection exists, the offerer/answerer MUST also insert an SDP
>>>'tls-id'
>>> attribute with the previously assigned value in the offer/answer.
>>>
>>> We would say
>>>
>>> If an offerer or answerer inserts an SDP 'connection' attribute with a
>>> 'existing' value in the offer/answer, if a previously established TLS
>>> connection exists, and if the offerer/answerer provided 'tls-id' value
>>>in
>>> the previous offer/answer which established this TLS connection, the
>>> offerer/answerer MUST also insert an SDP 'tls-id' attribute with the
>>> previously assigned value in the offer/answer.
>>>
>>> If we reword these statements like this, do we still need to specify
>>>that
>>> this document updates RFC4572?
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic