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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2019 10:32:18 -0400

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

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

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Mon, 11 Mar 2019 17:43:34 +0000

> On 11 Mar 2019, at 14:32, Paul Kyzivat <[email-masked]> wrote:
> 
> Colin and Ben,
> 
> I gather you mean here that not mentioning it in security considerations is a good thing.

Correct.

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

> 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
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2019 17:26:32 -0400

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

My thinking is that we don't like to have redundant normative 
specification, just in case they aren't consistent. The ABNF is 
normative. This section is of necessity an approximation.

But I defer to Ben or whoever.

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

I thought the point was that the RTP specs are normative and this is 
only an example, and so shouldn't be normative.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 11 Mar 2019 19:22:35 -0400

Sent from my iPhone

> On Mar 11, 2019, at 5:26 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> My thinking is that we don't like to have redundant normative specification, just in case they aren't consistent. The ABNF is normative. This section is of necessity an approximation.
> 

I agree with both of you. :-) 

That is, we should avoid duplication normative requirements when possible, because it increases the chance of  spec errors. But we should still try to make sure the sections agree.

> I thought the point was that the RTP specs are normative and this is only an example, and so shouldn't be normative.

I do not have the text in front of me, but I agree that examples should not be stated normatively.

Thanks! 

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Mar 2019 11:08:39 +0000

> On 11 Mar 2019, at 23:22, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
> 

This is documenting a perhaps unexpected interaction between SDP and RTP. That is, when set to recvonly in SDP, an RTP endpoint SHOULD send RTCP. I do think that it’s important that we spell this out clearly here, with normative language. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Mar 2019 11:41:30 -0400

> This is documenting a perhaps unexpected interaction between SDP and RTP. That is, when set to recvonly in SDP, an RTP endpoint SHOULD send RTCP. I do think that it’s important that we spell this o…

I'm neutral here whether its normative or not. If it is to be a 
normative SHOULD, can we please include some "unless" text indicating 
the conditions when it may be omitted? Better yet, turn it into an "if 
NOT x then MUST ..." form.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 14 Mar 2019 15:02:05 +0000

> On 12 Mar 2019, at 15:41, Paul Kyzivat <[email-masked]> wrote:
> I'm neutral here whether its normative or not. If it is to be a normative SHOULD, can we please include some "unless" text indicating the conditions when it may be omitted? Better yet, turn it into an "if NOT x then MUST ..." form.

I don’t think I can summarise the rules around when RTCP is, or is not, to be sent as a simple condition. If more detail is needed, I suggest “An RTP-based system in recvonly mode SHOULD still send RTCP packets as described in [RFC3550] Section 6”.

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2019 12:23:43 -0400

> I don’t think I can summarise the rules around when RTCP is, or is not, to be sent as a simple condition. If more detail is needed, I suggest “An RTP-based system in recvonly mode SHOULD still send…

I'll put this in if it is the consensus. But this appears to give 
license to someone to ignore RFC3550. (I have talked to people who have 
said "SHOULD isnt a firm requirement so I don't need to do it.)

If that SHOULD is changed to MUST, then it will still mean that RTCP can 
be avoided in whatever cases RFC3550 allows. Specifically:

"An RTP-based system in recvonly mode MUST still send RTCP packets as 
described in [RFC3550] Section 6.”

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 14 Mar 2019 16:26:36 +0000

> On 14 Mar 2019, at 16:23, Paul Kyzivat <[email-masked]> wrote:
> I'll put this in if it is the consensus. But this appears to give license to someone to ignore RFC3550. (I have talked to people who have said "SHOULD isnt a firm requirement so I don't need to do it.)
> 
> If that SHOULD is changed to MUST, then it will still mean that RTCP can be avoided in whatever cases RFC3550 allows. Specifically:
> 
> "An RTP-based system in recvonly mode MUST still send RTCP packets as described in [RFC3550] Section 6.”

I’m happy for you to change this to a MUST in that manner.

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2019 12:56:19 -0400

On 3/14/19 12:26 PM, Colin Perkins wrote:
>> On 14 Mar 2019, at 16:23, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>>> On 12 Mar 2019, at 15:41, Paul Kyzivat <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>>> 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…”..
>>>>>>>>>
>>>>>>> I thought the point was that the RTP specs are normative and this 
>>>>>>> is only an example, and so shouldn't be normative.
>>>>>>
>>>>> This is documenting a perhaps unexpected interaction between SDP 
>>>>> and RTP. That is, when set to recvonly in SDP, an RTP endpoint 
>>>>> SHOULD send RTCP. I do think that it’s important that we spell this 
>>>>> out clearly here, with normative language.
>>>>
>>>> normative SHOULD, can we please include some "unless" text 
>>>> indicating the conditions when it may be omitted? Better yet, turn 
>>>> it into an "if NOT x then MUST ..." form.
>>> I don’t think I can summarise the rules around when RTCP is, or is 
>>> not, to be sent as a simple condition. If more detail is needed, I 
>>> suggest “An RTP-based system in recvonly mode SHOULD still send RTCP 
>>> packets as described in [RFC3550] Section 6”.
>>
>> license to someone to ignore RFC3550. (I have talked to people who 
>> have said "SHOULD isnt a firm requirement so I don't need to do it.)
>>
>> If that SHOULD is changed to MUST, then it will still mean that RTCP 
>> can be avoided in whatever cases RFC3550 allows. Specifically:
>>

OK. I'll do it that way.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2019 13:32:24 -0400

> That is, we should avoid duplication normative requirements when possible, because it increases the chance of  spec errors. But we should still try to make sure the sections agree.

That is what I have tried to do. AFAIK they are consistent within the 
limits of the expressiveness of the informal syntax in the Section 5 figure.

The only divergence I am aware of is in the time description. The figure 
can't express that z= may only be used if it is preceded by an r=. It 
used to be that the abnf was consistent with the figure as written - 
permitting a z= without an r=. But that was nonsense because we have 
clarified that the z= only affects the immediately preceding r=.

IMO trying to indicate that subtlety in this figure would be 
counter-productive, by making the figure harder to follow.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2019 22:07:26 -0500

> On Mar 14, 2019, at 12:32 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> That is what I have tried to do. AFAIK they are consistent within the limits of the expressiveness of the informal syntax in the Section 5 figure.
> 
> The only divergence I am aware of is in the time description. The figure can't express that z= may only be used if it is preceded by an r=. It used to be that the abnf was consistent with the figure as written - permitting a z= without an r=. But that was nonsense because we have clarified that the z= only affects the immediately preceding r=.
> 
> IMO trying to indicate that subtlety in this figure would be counter-productive, by making the figure harder to follow.

I am convinced.

How far are we from having a revision ready for IETF LC? (I’ll be glad to approve an embargo override if needed.)

Thanks!

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Mar 2019 11:28:14 -0400

Ben,

On 3/19/19 11:07 PM, Ben Campbell wrote:

> How far are we from having a revision ready for IETF LC? (I’ll be glad 
> to approve an embargo override if needed.)

Right after I issued -33 I sent an email 
(https://mailarchive.ietf.org/arch/msg/mmusic/o_067yHrNY1ZEK5iuYBkuzFP6OU) 
describing changes, including some questions, and asking for help on a 
few things I couldn't do myself. Most notably remaining undone are the 
couple of security consideration issues where I need help. Can you 
suggest something for those, or somebody who might be able to help with 
them?

Otherwise, can you check all the places where I asked for your 
comment/approval?

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Mar 2019 11:30:25 -0500

Ah, right. I will look again.

Thanks!

Ben.

> On Mar 20, 2019, at 10:28 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Ben,
> 
> Right after I issued -33 I sent an email (https://mailarchive.ietf.org/arch/msg/mmusic/o_067yHrNY1ZEK5iuYBkuzFP6OU) describing changes, including some questions, and asking for help on a few things I couldn't do myself. Most notably remaining undone are the couple of security consideration issues where I need help. Can you suggest something for those, or somebody who might be able to help with them?
> 
> Otherwise, can you check all the places where I asked for your comment/approval?
> 
> 	Thanks,
> 	Paul
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Mar 2019 22:21:50 -0500

Hi,

Please see comments inline. Apologies for the late response, I somehow missed that this was still waiting on me.

Thanks!

Ben.

> On Feb 22, 2019, at 2:58 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Ben,
> 
> I just submitted -33. It attempts to address most, but not all, of your comments. See my detailed replies below. I need help for some of the remainder, specifically security considerations.
> 
> There will need to be another revision to address the remaining items.
> 
> 	Thanks,
> 	Paul
> 
> 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_.
> 
> I removed this claim.
> 
>> Along the same lines, §10 does not seem to capture all material changes.
> 
> I've tried to summarize all the important 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.
> 
> I've added my attempt at describing the semantics. (I posted a query about this but didn't get a response that seemed to work.
> 
> Please comment if you want a further change.

It looks good to me.

> 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

Would it make sense to say that “private sessions” have been superseded by the use of things like DTLS-SRTP and RFC 8224

> 
>> §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.
> 
> After reading 5.2 again I realized it is talking about an address in an o= line, not c=. Hence there is no intent that anybody connect to this, and ICE doesn't apply here. The address is primarily here to add to the uniqueness of the o= line. And note that the <sess-id> is required to make up any lack of uniqueness in the combination of the other fields. And privacy is leading to people not wanting to put real addresses or names in here.
> 
> So I removed all the discussion of ICE.
> 
> Please comment if you think this isn't sufficient or appropriate.

WFM

> 
>> §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”.
> 
> I twiddled with this. Does it work for you now?

All I see in 33 is a punctuation change. Did I miss something?

> 
>> §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.
> 
> I left this unchanged.
> 

Okay.

>> §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 beefed up the language for this.

WFM

> 
>> §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?
> 
> I brought this to the list. The feedback I got was that is change is correct.

Okay

> I need help with this from a security person

I’m willing to accept this as legacy text. (But I guess we will see what the SEC ADs have to say.)

> 
>> §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”.”
> 
> Done.
> 
>> §8.2: "The contact address for all parameters registered below is:
>> IETF MMUSIC working group <[email-masked]>”
>> Please consider “The IETF MMUSIC working group <[email-masked]> or its successor as designated by the IESG.”
> 
> Done.
> 
>> §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.
> 
> I left this as-is.
> 

okay

>> §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?
> 
>> 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.
> 
> Specification Required calls for a designated expert to review the registration. I revised the language to ask the expert to consider these issues.

WFM

> 
>> §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.
> 
> I removed the requirement for a phone number. (This makes it consistent with the template for attribute registrations that already didn't ask for a phone number.)
> 

Okay

>> *** 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…”
> 
> Done.
> 
>> §4.1: "This address and port is the destination address and destination port”: Plural disagreement. (It was correct in 4566.)
> 
> Fixed.
> 
>> §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.
> 
> Done
> 
>> - "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.
> 
> I cleaned this up and made it explicit that the ABNF is normative and this section is only a summary of the ABNF.
> 
>> - "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?
> 

<channeling-Adam>
Well, yes. The RFC Editor follows the Chicago Manual of Style, which IIUC calls for use of the Oxford comma. However, this isn’t one. The Oxford comma is for a serial conjunction list, e.g. “a, b, and c”. This instance is just a normal conjunction, e.g. “a or b”. “a, or b” is generally incorrect unless there’s some other reason for the comma.
</channeling-Adam>

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

Sure, it would make an interesting pub bet to see what they do :-)

> 
> I've left this unchanged for now.

> 
>> - "An SDP description may contain URIs”
>>  I'm not sure this change makes sense. Should it say ''session description”?
> 
> After investigating further, I realized that “session description” and “SDP description” are used synonymously through the document. So this change isn’t *wrong*. IIRC I did it to be consistent with the other usage of "SDP description" in the vicinity of this.
> 
> I suspect that “session description” might have been considered an abstract concept, with an "SDP description" being a specific realization of that. But the document doesn’t really make this distinction. And “SDP description” is redundant (Session Description Protocol description).
> 
> So perhaps every occurrence of “SDP description” should be changed to “Session Description”. Alternately, we could change every occurrence of "Session Description" to "SDP description".
> 
> For now I have left things as-is.

Okay. I read “SDP Description” as a “description of SDP”, but I see it was mean otherwise. I can live with it.

> 
>> - "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.
> 
> Done.
> 
>> §5.5: "The "u=" line (uri-field) provides URI (Uniform Resource Identifier)
>> as used by WWW clients”
>> Missing article before URI
> 
> Done.
> 
>> §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. Instead I changed it to:
> 
> "The "c=" line (connection-field) contains information necessary to establish a connection.”

WFM

> 
>> - 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).
> 
> This turns out to be tricky: "IP4" and "IP6" are the encodings used in the m-line. They are also used in the names of ABNF rules such as "IP4-address" and "IP4-multicast”.

Ah, of course, My bad.

I guess we saved a lot of “v”s with those encodings. One wonders why we didn’t try to save the “I”s and “P”s. ;-)

> 
> Most of the text usage seems to be talking about these encodings or rules. Just a few seem to be talking about the abstract protocols. I’ve changed those few.
> 
> Please see if that works for you.

WFM.

> 
>> - "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. This led me to investigate the use of "media-level" vs. "media level" and "session-level" vs. "session-level". It turned out to be a mess. So I have attempted to regularize the usage throughout. I now use "session level" and "media level" when referring to levels, and using "media-level" and "session-level" when the usage is as an adjective.
> 
> Let me know what you think.
> 

That sounds like the correct usage.

>> §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?
> 
> I revised to indicate this came from 4566.
> 
> The text already says NOT RECOMMENDED which is pretty much the same as deprecated and is normative. I considered saying both in that sentence but it seemed peculiar.

Okay.

> 
>> §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 changed "initiate" to "begins".
> 
> There has been a lot of confusion and questions raised bout how t=/r=/z= work together. I revised the ABNF to clarify that, and then reworked this text to be consistent with and coordinate with the ABNF.

Okay. (Wow, that’s a lot of work for an editorial comment :-) )

> 
>> §5.13: "(Attribute scopes in addition to media- and
>> session- specific may also be defined”
>> Should “specific” be “level”?
> 
> Yes. Done.
> 
>> §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?
> 
> I rewrote this to make it clearer.

WFM

> 
>> - "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 rewrote the paragraph. Hopefully it is better.
> 

Looks good.

>> §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.)
> 
> Done.
> 
>> §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 went back and gathered and acknowledged all the people who authored or were acknowledged in any of the documents obsoleted by this one or 4566.
> 
> Can you think of anyone else who should be acknowledged?

Thanks, I think you have it covered.

> 
> 	Thanks,
> 	Paul
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Mar 2019 10:28:29 -0400

Ben,

On 3/20/19 11:21 PM, Ben Campbell wrote:

I've trimmed this to just the points that seem to call for a reply.

> Would it make sense to say that “private sessions” have been superseded by the use of things like DTLS-SRTP and RFC 8224

The section on private sessions appears to have made sense in the 
distant past when the primary (or only) use of SDP was SAP. Then most 
sessions were public. Now almost all use of SDP is in establishing 
private sessions.

I'm not convinced it is necessary to say anything about this, but I 
could reinstate a §4.3 on private sessions, with text saying what I just 
said above.

> All I see in 33 is a punctuation change. Did I miss something?

There is also a small change in the prior paragraph. I changed it to 
indicate that this is a legacy of 4566.

Re SHOULD vs MUST: IIRC the intent was to leave a little wiggle room for 
X-, while saying that non-X- names MUST be registered.

Can we agree on what we mean to say here? Then I can try to reword to 
say that more clearly.

ISTM that we want to say that *new* uses of X- are forbidden while 
existing ones may continue. And non-X- names MUST be registered. (What 
about existing non-X- and unregistered names?)

> I’m willing to accept this as legacy text. (But I guess we will see what the SEC ADs have to say.)

OK. Then *they* can supply the text.

> Well, yes. The RFC Editor follows the Chicago Manual of Style, which IIUC calls for use of the Oxford comma. However, this isn’t one. The Oxford comma is for a serial conjunction list, e.g. “a, b,…

Oh duh! Agree. If I need to make more changes then I will include this one.

> Okay. (Wow, that’s a lot of work for an editorial comment :-) )

No. All the ABNF changes were done long ago. This time I simply changed 
"initiate" to "begins".

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Mar 2019 09:36:02 -0500

> On Mar 21, 2019, at 9:28 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Ben,
> 
> The section on private sessions appears to have made sense in the distant past when the primary (or only) use of SDP was SAP. Then most sessions were public. Now almost all use of SDP is in establishing private sessions.
> 
> I'm not convinced it is necessary to say anything about this, but I could reinstate a §4.3 on private sessions, with text saying what I just said above.

In that case, a mention in the “changes” section should be good enough. Would that fall under the “removed references to SAP” comment? It might be worth mentioning that this removal included private sessions.
> There is also a small change in the prior paragraph. I changed it to indicate that this is a legacy of 4566.
> 
> Re SHOULD vs MUST: IIRC the intent was to leave a little wiggle room for X-, while saying that non-X- names MUST be registered.
> 
> Can we agree on what we mean to say here? Then I can try to reword to say that more clearly.
> 
> ISTM that we want to say that *new* uses of X- are forbidden while existing ones may continue. And non-X- names MUST be registered. (What about existing non-X- and unregistered names?)
> 

Okay, on re-reading, I think I am okay with it. I just wanted to make sure we were looking at the same text.

> OK. Then *they* can supply the text.

We can worry about that when it happens :-) (i.e. IESG evaluation)

> No. All the ABNF changes were done long ago. This time I simply changed "initiate" to "begins”.

Ah, okay.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Mar 2019 10:43:33 -0400

Ben,

Based on your comments, I need to change the "Changes" section to 
mention the removal of private sessions, and remove the offending comma. 
I think that is all.

Given the freeze, what is the process to submit an update?

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Mar 2019 09:50:10 -0500

Send the draft to me and I will ask the secretariat to force publication.

Thanks!

Ben.

> On Mar 21, 2019, at 9:43 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Ben,
> 
> Based on your comments, I need to change the "Changes" section to mention the removal of private sessions, and remove the offending comma. I think that is all.
>