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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 13 February 2019 20:16 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 788EC130E5A for <mmusic@ietfa.amsl.com>; Wed, 13 Feb 2019 12:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 DLVzz7R9UeVg for <mmusic@ietfa.amsl.com>; Wed, 13 Feb 2019 12:16:36 -0800 (PST)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 7DEF21310C4 for <mmusic@ietf.org>; Wed, 13 Feb 2019 12:16:36 -0800 (PST)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id u0Rdgbsv6kzMNu0xOgdZVY; Wed, 13 Feb 2019 20:16:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1550088994; bh=kYLLWoKEGMaZBw+npZSrezr1B2KJ3gDVaI9vBp+y9NI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fOxRkZlqRnyeU4XGad2uvcCzpBSjJ6vcYvneBsCizm8DI/U5iM++WcZ3GLeVuOVRS wcdmK4uh17c2YDthFstvmHJEcuGuQPUZ18Tt2uWwRGi0SPiflCSfyah4hokcd2sbdK AY6c4GLO9kZteE25ZmmBHKnPKsGsfC4LrxG3GIBzKFcl8HI8ciN7yh7qsGHIrJfOJ9 Y2zVnzrzSGxNaTBfWfDzNsQqXHFHk2ZdnQwIb4v+dnKELbdLxD5p3DCJ7KQHBQilIf zb9aS+7em55KYpVTjV8Qw6vbwWDC9mJNvjnjS6ND4d8reBc18QRFzXIKWNCKjZJInJ 4F/dpLv5KABnw==
Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with ESMTPA id u0xNgJdxIXnyHu0xNgz0h9; Wed, 13 Feb 2019 20:16:34 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedtledruddtfedgudefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefrrghulhcumfihiihivhgrthcuoehpkhihiihivhgrthesrghluhhmrdhmihhtrdgvughuqeenucfkphepvdegrdeivddrvddvjedrudegvdenucfrrghrrghmpehhvghloheprfgruhhlmfihiihivhgrthhsofeurfdrlhhotggrlhguohhmrghinhdpihhnvghtpedvgedriedvrddvvdejrddugedvpdhmrghilhhfrhhomhepphhkhiiiihhvrghtsegrlhhumhdrmhhithdrvgguuhdprhgtphhtthhopehmmhhushhitgesihgvthhfrdhorhhgpdhrtghpthhtohepughrrghfthdqihgvthhfqdhmmhhushhitgdqrhhftgegheeiiegsihhsrdgrlhhlsehivghtfhdrohhrghdprhgtphhtthhopegsvghnsehnohhsthhruhhmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-Xfinity-VMeta: sc=-100;st=legit
To: Ben Campbell <ben@nostrum.com>, draft-ietf-mmusic-rfc4566bis.all@ietf.org
Cc: mmusic WG <mmusic@ietf.org>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <e7e0042a-8079-8c0e-0ddd-1ea330f08e7c@alum.mit.edu>
Date: Wed, 13 Feb 2019 15:16:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/1wANIFtmcAWxeGx1rjk7wq97A-Q>
Subject: Re: [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: Wed, 13 Feb 2019 20:16:49 -0000

Ben,

Some clarifying questions inline...

On 2/11/19 10:45 PM, Ben Campbell wrote:
> Hi,
> 
> 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.
> 
> Thanks!
> 
> Ben.
> ----------------------
> 
> 
> *** 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_.

Agreed. Is it sufficient for me to remove the claim that they are 
essential? (Or do you want me to remove changes that aren't essential.) 
A good number of the changes were made to improve clarity for things 
have been found confusing over the years.

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

I don't think it would be helpful to enumerate *every* change. But I'll 
do a fresh diff against 4566 and try to identify the *material* changes. 
Possibly bucket some of them into categories and just list those.

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

I'm pretty sure this definition has been with us forever. But I'll put 
something in about the semantics.

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

I don't recall why that was removed. I'll try to find the discussion on it.

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

Hmm. That condition is what was added to the prior language. But the way 
it was was often violated with an assumption that something on the path 
would replace the address. And of course using ICE in this context also 
results in using a different (global) IP when leaving the scope. IIRC 
there was a desire to have a reference to ICE here, but I'll try to come 
up with some more general words for other hypothetical escapes from this 
rule.

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

Hmm. Note that we are not *forbidding* the use of the X- prefix. (For 
backward compatibility reasons I think.) Instead, we are saying the the 
X- prefix *SHOULD* NOT be used. So you aren't required to define a 
non-X-prefix (hence the SHOULD), but if you do define one then you MUST 
register it.

I remember there was quite a bit of wordsmithing of this. But I can try 
again. Perhaps we should be stronger, and say that X- prefixes may only 
be used for backward compatibility with existing work, and non-X- 
prefixes MUST be defined and registered for new work.

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

It continues to be mentioned because implementations may need to support 
it for backward compatibility with 4566. In that case they need to know 
where it goes.

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

I don't recall that we ever discussed the behavior. I think MUST NOT be 
sent is ok. How about MUST accept but MAY ignore?

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

IIRC it indeed was intentional, because of past interoperability 
problems. But I would like to pass the buck on this to an RTCP expert.

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

I didn't write this part. Again I want to pass the buck to an expert. 
I'll see if I can find who wrote this text.

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

OK. Good idea!

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

Will do.

> §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
> [RFC3840]).”
> 
> Should this spec update 3840?

Leaving 3840 as-is doesn't hurt anything. As long as these aren't used 
in m-lines then usage in 3840/3841 will be moot.

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

Good point. But I think it will be tricky to come up with a suitable 
rule. I think I will need help.

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

Can that be separated from you above point? Obviously we often have 
different authors for an update or bis, but it is ok because both are 
operating within the rules for the same document stream. I assume 
something similar applies for other SDOs. But I can't find the 
definition of "Specification Required" right now. Can there be a 
document that satisfies "Specification Required" that doesn't have such 
rules?

I need help here.

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

IMO they aren't. We struggle with contact info for IANA all the time. 
Most the time for new things we end up identifying a WG or IESG, or some 
other organization. When contact info for individuals is used the 
contact info other than name is likely be be obsolete before it is used. 
But doesn't an email address also run afoul of the GDPR rules? Clearly 
we need *some* means of contact. Maybe we should require email OR phone# 
OR postal address. (OR Facebook id, ...?)

Perhaps we should say that this SHOULD identify an organization rather 
than an individual. Organizations don't fall under GDPR do that?

> *** 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…”

OK

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

Obviously an intentional change. Don't know why. Will fix.

> §5:
> - “… 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.

OK

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

OK

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

IIUC this is an "Oxford comma", and the use of it is controversial. Does 
IETF have a policy on its use?

(Or we can leave it for the editor to decide.)

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

I don't know where that came from. I agree. Will fix.

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

Yes. Will fix.

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

OK

> §5.7:
> - "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?

That seems pretty circular. How about:

"The "c=" line (connection-field) contains information necessary to 
establish a connection.”?

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

Agree. Will fix.

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

I see the same text in both for this. OTOH we are using "per-media" in 
the same section. I will change it.

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

Yes, I can reword to say that this was defined in 4566. The next 
sentence already talks about intended usage now, and we already 
discussed changes to that above.

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

I reworked this considerably to resolve ambiguities that came up, 
particularly around z=. The ABNF was hard to follow and wrong after we 
concluded that z= only modifies the preceding r=. This led me to define 
time-description in the ABNF. (Because the syntax used to permit z= 
without r=, which is nonsense.) The time-description is a multi-line 
sequence that begins with t= that has optional r= and z= following, 
according to the syntax. Here we are trying to talk about it in English.

"initiate" seems fine to me (since I wrote it), but I can change it to 
something like "starts" or "marks the beginning of".

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

Yes, that seems better.

> §5.14:
> 
> - "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?

Yes. I will try to clarify.

> - "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…”?

I'll work on it. I agree that "imply" is wrong here. I think it is 
trying to say that there was some limited past practice of using the 
same transport address to indicate grouping. This is saying that such 
practice was wrong, and that grouping requires an explicit mechanism. 
But interestingly it doesn't say that in normative language. Do you 
think we need something normative here?

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

OK.

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

OK

> §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…"

I agree. Will do.

	Thanks,
	Paul