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

Ben Campbell <ben@nostrum.com> Tue, 12 February 2019 03:45 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B008212D4EF; Mon, 11 Feb 2019 19:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BOG0BPN0HLcy; Mon, 11 Feb 2019 19:45:35 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0E5F012D4E9; Mon, 11 Feb 2019 19:45:34 -0800 (PST)
Received: from [] (cpe-70-122-203-106.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1C3jVGT010362 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Feb 2019 21:45:33 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549943134; bh=4tBhuZ4skrxTuvjNrD26EOKnJ+YLMYmi8EmEyUvpM0g=; h=From:Subject:Date:Cc:To; b=OES6wPRZJye3Isqukp+yolZ5SrLXPd9aCKZUgSfWMuqZ9Vsi/mDYAPU6SCsAmiaG+ bUsORnMJFKeKouyoyIWFBWMCz0dsIwJ5fgRo4nPe5K/zXT0tDNM86/vaZ3y4uC0m3q L4+GzNBiNenqww0m4IXPPvJDZmNa5S+S0J1t5+AU=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [] claimed to be []
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_872EDD49-79E8-405C-8393-67AA4D69D5E4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com>
Date: Mon, 11 Feb 2019 21:45:30 -0600
Cc: mmusic WG <mmusic@ietf.org>
To: draft-ietf-mmusic-rfc4566bis.all@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/lPP5aZ5nPfTIqdS80X3G71RrE_w>
Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Feb 2019 03:45:38 -0000


This is my AD evaluation of draft-ietf-mmusic-rfc4566bis-32. I have several minor substantive comments, and a number of editorial comments and nits. I’d like to resolve at least the substantive comments prior to IETF last call.



*** Substantive Comments ***

§1, last paragraph: The statement that this update is limited to essential corrections is demonstrably untrue. For example, this version changes a lot of spellings from British English to US English. While that might be best for the sake of consistency, it would be hard to argue that it is _essential_.

Along the same lines, §10 does not seem to capture all material changes.

§2, “Media Description”: While true, the text here is not a definition of anything but syntax. Please add a sentence or two to say what the media description semantically represents.

- Deleted text formerly in §4.3: The removal of the “private sessions” section in its entirety deserves some explanatory text.

§5.2: "Unless an SDP extension for NAT traversal is used
(e.g., ICE [RFC8445], ICE TCP [RFC6544]), a local IP address MUST
NOT be used in any context where the SDP description might leave
the scope in which the address is meaningful”

That doesn’t apply to just any NAT traversal extension does it? It seems to require extensions that have scope-resolution properties similar to those of ICE.

§5.8: "Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-"
prefix) <bwtype> names SHOULD be defined, and then MUST be registered
with IANA in the standard namespace.”

“SHOULD be defined” seems to be in tension with “MUST be registered”.

§5.13: "The "k=" line (key-field) is obsolete and MUST NOT be used.”
Should it be removed from the field order definition in §5?

§6.1: Please state what behavior is meant by “This attribute is obsoleted”. For example, MUST not send but SHOULD accept? Something different? (This pattern occurs for multiple attributes.)

§6.7.4: "Note that an RTP-based system MUST still send RTCP (if RTCP
is used), even if started inactive.”
Other similar attributes use SHOULD instead of MUST. Is the inconsistency intentional?

§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?

§8 and subsectionsl:

I think there needs to be more clarity about what this draft defines vs what was defined in previous versions, and what has changed. For example, language to the effect of "XXX was originally defined in RFC 4566. This document requests IANA to change the reference to “RFC-this”.”

§8.2: "The contact address for all parameters registered below is:
IETF MMUSIC working group <mmusic@ietf.org>”
Please consider “The IETF MMUSIC working group <mmusic@ietf.org> or its successor as designated by the IESG.”

§8.2.1: "Until that is done, applications SHOULD NOT use these
types and SHOULD NOT declare support for them in SIP capabilities
declarations (even though they exist in the registry created by

Should this spec update 3840?

§ This section needs some guidance about the maturity of specs needed to update attributes defined in previous specs. While the registration policy is “spec required”, what happens if someone defines FOO in a standards-track RFC, and someone else wants to update it with some lower-maturity instrument?

Along the same line, is there any restriction from party B updating an attribute defined by party A without consent? That is clear for IETF stream RFCs where the IETF retains change control, but might not be clear for other specification forms.

§8.2.8: Are telephone numbers still necessary? Under GDPR rules, we should be careful about requiring data unless there is a clear need for it.

*** Editorial Comments and Nits ***

§3.3, 2nd paragraph: "Note that descriptions of multicast sessions made only via email or…”

The sentence no longer makes sense with the change from “announcement” to “description”. If you want to avoid the term “announcements”, consider something like “… descriptions of multicast sessions sent only via email…”

§4.1: "This address and port is the destination address and destination port”: Plural disagreement. (It was correct in 4566.)

- “… the end of the whole session description - whichever…”: A dash usually separates two independent clauses, much like a semicolon. That is not the cast here; a comma would be more appropriate.

- "Some lines in each description are REQUIRED and some are OPTIONAL,” : While I recognize these are unchanged from 4566, the REQUIRED and OPTIONAL terms seem like statements of fact rather than normative statements.

- "media-, or session-specific basis” : Incorrect comma usage.

- "An SDP description may contain URIs”
 I'm not sure this change makes sense. Should it say ''session description”?

- "Text containing fields such as the session-name-field and
This is ambiguous. Are we talking about text that contains fields, or text-containing fields? From context, I assume the latter.

§5.5: "The "u=" line (uri-field) provides URI (Uniform Resource Identifier)
as used by WWW clients”
Missing article before URI

- "The "c=" line (connection-field) contains connection data.”
The section heading was changed from “connection data” to “connection information”. Should that change apply here, too?

- There are a number of places in this section (and maybe elsewhere) where IPv6 was changed to IP6. While I realize 4566 was inconsistent on this, wouldn’t it make more sense to change to consistently use the more conventional “IPv6”?  (Probably also true for IP4/IPv4).

- "Multiple addresses or "c=" lines MAY be specified on a per media
description basis”
4566 correctly hyphenated “per-media-description basis”. Why were the hyphens removed here?

§5.8: "A prefix "X-" is defined for <bwtype> names. This is intended for
experimental purposes only.”

Please consider active voice for “is defined”, since in this case it obscures the fact that this was defined by an earlier version of the spec. Would it make sense to say that previous versions defined it, but it is now deprecated?

§5.9: "A "t=" line (time-field) initiates a time description that specifies
the start and stop times for a session.”

I don't understand what it means to "intitiate" a time description. The text from 4566 seemed more clear.

§5.13: "(Attribute scopes in addition to media- and
session- specific may also be defined”
Should “specific” be “level”?


- "If noncontiguous
ports are required, they must be signaled using a
separate attribute. (There is currently no attribute defined that
can accomplish this. The "a=rtcp:" defined in [RFC3605] does not
handle hierarchical encoding.)”

 This is oddly stated. Is the point that, if non-contiguous ports are needed, someone will have to specify a new attribute?

- "This implies that, unlike
limited past practice, there is no implicit grouping defined by
such means and an explicit grouping framework”

This does considerably more than “imply” it. It states it explicitly. Perhaps “This means that, unlike…”?

§6.7: "At most one of recvonly/sendrecv/sendonly/inactive MAY appear at
session level”
Consider something like "occurrence of recvonly, sendrecv, sendonly, or inactive”. (Please don’t use slashes to substitute for conjunctions.)

§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.

§11: It seems a shame to completely drop the acknowledgements from 4566, since the fact that this will obsolete it means people should no longer need to read it. I recognize that those acknowledgements do not apply to _this_ draft, but one could always include a paragraph of the form of “RFC 4566 also acknowledged…"