Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32

Colin Perkins <> Mon, 11 March 2019 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89BDC124BF6 for <>; Mon, 11 Mar 2019 10:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gb7dT72Aw7vO for <>; Mon, 11 Mar 2019 10:43:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE80412008A for <>; Mon, 11 Mar 2019 10:43:42 -0700 (PDT)
Received: from [] (port=51897 by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <>) id 1h3Oxe-0007mn-1l; Mon, 11 Mar 2019 17:43:38 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 11 Mar 2019 17:43:34 +0000
Cc: Ben Campbell <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2019 17:43:46 -0000

> On 11 Mar 2019, at 14:32, Paul Kyzivat <> wrote:
> Colin and Ben,
> On 2/25/19 6:02 PM, Colin Perkins wrote:
>>>> - Deleted text formerly in §4.3: The removal of the “private sessions” section in its entirety deserves some explanatory text.
>>> I posted a query about this. The consensus was that the removal here is right, but that more discussion is needed in the Security Considerations section. But I don't know what to write. I need some help on that.
>> The former §4.3 just said two things. The first was that if you want to keep the SDP session description private, then you need encryption to protect for distribution. That seems obvious, but I guess a statement to that effect could be added to the security considerations (“If it’s desired to keep a session description confidential, then confidentiality protection SHOULD be used”).
> I'll put that in if desired, but it sure seems like a "duh" to me.
> Ben?
>> It also said that a private session description can be used to convey encryption keys. I’m not sure that’s something we want to encourage.
> Since the text has been removed, it no longer "encourages" it.
> I gather you mean here that not mentioning it in security considerations is a good thing.


>> §5 has several changes to normative language. Most are okay, but I think the change from “all MUST appear in exactly the order given here” to “all must appear” weakens it too much, and I’d prefer that to remain a MUST.
> The reason for changing that is because the *normative* specification of the ordering is from the ABNF. The text here is explanatory and non-normative. (Note that a couple of paragraphs prior to this is a new statement emphasizing that the ABNF is normative.)

Sorry, but I think this change is problematic. The text needs to use normative language that is consistent with the ABNF. 

>>>> §7, last paragraph:
>>>> What is the impact of this on RFC 4568 (security descriptions)? That RFC seems to allow the use of “k=“ lines at a MAY level. Does this draft need to update that? But more importantly, is it worth distinguishing the case of E@E protection of keying material vs the HBH protection offered by security descriptions?
>>> This text is unchanged since 4566.
>>> I need help with this from a security person.
>> SDP security descriptions has problems, but I’d argue that those should be addressed in an RFC updating RFC 4568, or moving it to historic, rather than in the base SDP specification. Is this not something SIPBRANDY will be producing?
> Ben, does passing the buck on this work for you?
>>>> §6.7.1: "(e.g., an RTP-based system in
>>>> recvonly mode SHOULD still send RTCP packets”
>>>> Please don’t use normative keywords in examples. Examples should never be normative.
>>> Done.
>> This is a normative requirement of RTP, however. If we want to avoid normative examples, which I’d agree makes sense, then this needs to be rewritten as just “An RTP-based system in recvonly mode SHOULD…”.
> That is the way it was. The change from "SHOULD" to "should" was to make it non-normative.
> Or were you requesting to remove “e.g."?

Remove the “e.g.”, yes, but also change “should” back to “SHOULD”. 

Colin Perkins