Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments

Christer Holmberg <> Tue, 14 March 2017 08:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 384A3129441; Tue, 14 Mar 2017 01:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wnbIrnka0n2k; Tue, 14 Mar 2017 01:59:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5997B12943B; Tue, 14 Mar 2017 01:59:29 -0700 (PDT)
X-AuditID: c1b4fb2d-2dacd98000006193-f9-58c7b0ef6fa0
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id ED.56.24979.FE0B7C85; Tue, 14 Mar 2017 09:59:27 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 09:59:26 +0100
From: Christer Holmberg <>
To: Ben Campbell <>, "" <>, mmusic <>
Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
Thread-Index: AQHSnKFIZPUXLA+RFUGrIb2KhDlggg==
Date: Tue, 14 Mar 2017 08:59:26 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7h+77DccjDLYs0rOY33ma3WLH3R1s FlOXP2ZxYPZYsuQnk8esnU9YApiiuGxSUnMyy1KL9O0SuDKOXt7CVNAgWrFjQTtjA+MlgS5G Dg4JAROJv685uhi5OIQE1jFKvD/znRHCWcwosfnRWhaQIjYBC4nuf9ogcRGByYwS/btamUDi wgJREjcmcnUxcgLFoyXunf3CCmHrSey5+pQNxGYRUJU4eeMcmM0rYC2x/MB7FhCbUUBM4vup NUwgNrOAuMStJ/PBbAkBAYkle84zQ9iiEi8f/wObKQo0c/nzNVBxJYkfGy6xQPQaSLw/N58Z 5BxmoPnvp9dDhLUlli18zQyxVlDi5MwnLBMYRWYh2TYLSfcshO5ZSLpnIelewMi6ilG0OLW4 ODfdyFgvtSgzubg4P08vL7VkEyMwVg5u+a27g3H1a8dDjAIcjEo8vB82H4sQYk0sK67MPcQo wcGsJML7d+XxCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4 pRoY1TnUClrNSm9vcrkv8frOOo4Zwss6dszu02NM82RWeet81M6f19yY127TmqAfee2m59Wf 7vE4KdK72O1RaY+JrZCZ1YRZiYv75qw4rbmZI6nS+9DewF/H11+S5lcraNh96Xiq6IujlUw5 tz4e0WTIkHdZOj+Mc7HP53euQkqvb87aWyuezc2kxFKckWioxVxUnAgAwKlEjZECAAA=
Archived-At: <>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 08:59:31 -0000

Hi Ben,

Thanks for your review! Please see inline.

>This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like to
>resolve my substantive comments and questions prior to IETF last call.
>Substantive Comments:
>- section 4: "If an offer or answer does not
>    contain a ¹dtls-id¹ attribute (this could happen if the offerer
>    answerer represents an existing implementation that has not been
>    updated to support the ¹dtls-id¹ attribute), the offer or answer
>    be treated as if no ¹dtls-id¹ attribute is included. "
>That seems to say that if dtls-id is not included, the offer or answer
>must be treated as if it's not included. Since that's tautologically
>true, I suspect you meant to say something more?

This is related to the first sentence, saying that there is no default
value defined for the attribute.

I could say ³Hence, if an offer or answer does not containŠ², if it makes
the text more clear.


>-8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision a
>scenario where it would make sense to not follow them?

I can¹t think of any scenario, so I am happy to use MUST.


>-9.2, new text for section 5, 5th paragraph:
>Since we are touching this section, shouldn't we update the 4474
>reference to 4474bis, and update the language about what gets signed in
>4474bis? And can we take this opportunity for a MUST level requirement
>for some kind of integrity protection of fingerprints, even if not
>4474/4474bis? (At least when not considering opportunistic crypto

See my reply to your comment on section 10.


>-- 4th paragraph from end of new text:
>should "the certificate fingerprint" say "a certificate fingerprint"?
>(Since you can have multiple fingerprints now...)

Yes. I will fix that.


>If you accept my suggestion to move from 4474 to 4474bis in the updated
>text for 5763, that will create changes that should probably be
>mentioned here. For example, 4474bis signatures cover fewer things than
>do 4474 signatures. The hope that 4474bis may be more deployable than
>4474, and therefore really used, may also be worth a mention here.

RFC 5763 contains 20+ references to RFC 4474, in a number of different

We would have to update all of those sections (at least the reference,
possibly also normative text), because I don¹t think we should mix 4474
and 4474bis. In my opinion, that should be done as a separate task.

(I will reply to your editorial comments in a separate e-mail)