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

Roman Shpount <roman@telurix.com> Tue, 18 April 2017 19:17 UTC

Return-Path: <roman@telurix.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 C3FE9128CD5 for <mmusic@ietfa.amsl.com>; Tue, 18 Apr 2017 12:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 IGwp2CtA-jhQ for <mmusic@ietfa.amsl.com>; Tue, 18 Apr 2017 12:17:55 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4A81270AC for <mmusic@ietf.org>; Tue, 18 Apr 2017 12:17:55 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id 194so1041889pfv.3 for <mmusic@ietf.org>; Tue, 18 Apr 2017 12:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bIsk51PiYOFMWOcMY48c0OP7c4wLynvTbf7evcGkFz4=; b=NMKssFqhd3TvXyTr5O7i9VHq4OXTwKZ2FsBhhWfKok58wlueO1N84fmBgAj+/u0xQW Z3cOUIRzaw7uO+0FzIjbZhqjIGkRWxPpxjEbP7Ztzbphb1HQZ5jm5imI5t8dHs2tfxsq cI5hr67s7to3bC5cxV2GfD5GmUGeAHdWQW+lWhcMMI8GpuCo2GrvAvo5P/RBssRtEI4s eGbBP/qYmyxCVZHQBtOfjiF2DRJO/moYWZHNxVqrFDJNEnLLs77VgxktZpBhQoQinRDk 35cB5mi2GbjwSkEntvX6E68s/xn9BJW0VpAyu7lv4jl49UmseaZlYNiNSq9bq6Rp7rGW vw1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bIsk51PiYOFMWOcMY48c0OP7c4wLynvTbf7evcGkFz4=; b=m3C/ASuBmLG52f12zxODI6+wePSbcfAV7JR0ApXkLnD6UF043y7wL/VPbW8FDcDdbA xO324kXsGAvTGV0jcVJ83AQHrEyaZDcc0EyrQlAc4mJ26bv+DeDB9VVzBRn3DNp33qaW eReaERETIZeJGAYY60kHMYtU/fdhRgvEWKRNsXkZxdh5YP6Y/vyFBAP71YjEAnalZM+F UdqyZ/rrOo/P6Zkcf8jRcK7uN16H2O1Vzel9AHh3gvmkNRb1m9kCn90NW/Y9Fy2AOOSu 94UPnxhW1EGCI23pqujwSFM2c2X3CtxD9QXARGn7i54QWScUhBzG6ylY4y1xaK3HGFsE y69A==
X-Gm-Message-State: AN3rC/4nmmhj84fmOf9MbijrNnL5XYl7qrPS7y0/MKXikDa/xwHtAOWj 6drEZP5NKkJuXdn9
X-Received: by 10.99.185.1 with SMTP id z1mr19829749pge.165.1492543075067; Tue, 18 Apr 2017 12:17:55 -0700 (PDT)
Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com. [74.125.83.41]) by smtp.gmail.com with ESMTPSA id o124sm54558pfb.92.2017.04.18.12.17.54 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 12:17:54 -0700 (PDT)
Received: by mail-pg0-f41.google.com with SMTP id 72so1132884pge.2 for <mmusic@ietf.org>; Tue, 18 Apr 2017 12:17:54 -0700 (PDT)
X-Received: by 10.99.140.67 with SMTP id q3mr20378633pgn.210.1492543073900; Tue, 18 Apr 2017 12:17:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.151 with HTTP; Tue, 18 Apr 2017 12:17:53 -0700 (PDT)
From: Roman Shpount <roman@telurix.com>
Date: Tue, 18 Apr 2017 15:17:53 -0400
X-Gmail-Original-Message-ID: <CAD5OKxuBp6=EJTmVr6RLFv_w6-gnfOgNkmCiCjRs847KBd8oiw@mail.gmail.com>
Message-ID: <CAD5OKxuBp6=EJTmVr6RLFv_w6-gnfOgNkmCiCjRs847KBd8oiw@mail.gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>, Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary=f403045e2196bb656d054d75c3f7
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/TF-2aX7bHf0MFlYL_v_Swx320M4>
Subject: [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: Tue, 18 Apr 2017 19:17:57 -0000

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