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

From: Ben Campbell <[email-masked]>
Date: Mon, 11 Feb 2019 21:45:30 -0600

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

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 <[email-masked]>”
Please consider “The IETF MMUSIC working group <[email-masked]> 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
[RFC3840]).”

Should this spec update 3840?

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

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

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

- "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
information-field”:
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

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

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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Feb 2019 10:41:33 -0500

> 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 com…

Thanks Ben. I will start working on these. I may have some questions as 
I work through them. It will take some digging to figure out where some 
of these things came from and why.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Feb 2019 10:18:21 -0600

> On Feb 12, 2019, at 9:41 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Thanks Ben. I will start working on these. I may have some questions as I work through them. It will take some digging to figure out where some of these things came from and why.
> 

Thanks!

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Feb 2019 15:16:33 -0500

Ben,

Some clarifying questions inline...

> 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 com…

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.

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

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

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

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

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

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.

> 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 defin…

OK. Good idea!

> Please consider “The IETF MMUSIC working group <[email-masked]> or its successor as designated by the IESG.”

Will do.

> 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 someo…

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 mi…

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?

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

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.

> - “… 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 no…

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

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

> This is ambiguous. Are we talking about text that contains fields, or text-containing fields? From context, I assume the latter.

Yes. Will fix.

> Missing article before URI

OK

> 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 consisten…

Agree. Will fix.

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

> 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 def…

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.

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

> Should “specific” be “level”?

Yes, that seems better.

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

> Consider something like "occurrence of recvonly, sendrecv, sendonly, or inactive”. (Please don’t use slashes to substitute for conjunctions.)

OK.

> 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 acknowledgem…

I agree. Will do.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Feb 2019 23:32:51 +0000

Hi,

Some comments inline.

> On 13 Feb 2019, at 20:16, Paul Kyzivat <[email-masked]> wrote:
> 
> Ben,
> 
> 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.
> 
> 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.
> 
> I'm pretty sure this definition has been with us forever. But I'll put something in about the semantics.
> 
> I don't recall why that was removed. I’ll try to find the discussion on it.

http://mailarchive.ietf.org/arch/msg/mmusic/W82Ba0vOboPUqbfWiZ0yJZqZMTQ 

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

“obsoleted" -> "obsolete” maybe?

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

In general, this might be different for declarative and offer/answer uses of SDP? A lot of the obsolete attributes are things that were only ever really used in declarative applications of SDP.

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

I agree that MUST send RTCP even if started inactive is correct.

> 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:
> 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.
> 
> Good point. But I think it will be tricky to come up with a suitable rule. I think I will need help.
> 
> 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.

Specification Required is RFC 8126, section 4.6. Essentially it punts to the designated expert for the registry, but says nothing about priority between SDOs.

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

Does IANA not have a policy for this?

> IIUC this is an "Oxford comma", and the use of it is controversial. Does IETF have a policy on its use?
> 
> "The "c=" line (connection-field) contains information necessary to establish a connection.”?
> 
> I see the same text in both for this. OTOH we are using "per-media" in the same section. I will change it.
> 
> 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.
> 
> 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".
> 
> 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?
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2019 15:23:55 -0500

>> §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 having trouble finding a suitable semantic definition of Media 
Description.

My first thought is that it provides the information necessary to 
establish a media session. But while *Multimedia Session* is described, 
media Session isn't defined in the document.

I looked at RFC7656 (Taxonomy) for a definition, but it doesn't have one 
either. It defines RTP Session, and Multimedia Session as one or more 
RTP Sessions. That is close, but in SDP media sessions need not be RTP.

Is there any suitable existing definition???

If not, then how about:

"A Media Description contains the information needed for one party to 
establish an application layer network protocol connection to another 
party." ???

OR

"A Media Description contains the information needed for one party to 
establish a Media Session with another party."

"A Media Session is an application layer network protocol connection 
between two parties."

It seems important to get this right! It is essentially a broadening of 
RFC7656 beyond RTP.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2019 15:49:29 -0500

That is a reply from Christer. The relevant part says:

> My suggestion would be to remove the whole section. I can't remember any discussion where one would have used private vs public sessions. The Security Considerations should then cover encryption etc of SDP information.

We managed to do the part that deletes the Private Sessions section, but 
not the update to Security Considerations. When looked at from this 
perspective, Security Considerations does seem lacking.

Ben, will you be happy if this is addressed in Security Considerations? 
If so I'll open another discussion about that.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Feb 2019 15:10:57 -0600

> On Feb 18, 2019, at 2:49 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> We managed to do the part that deletes the Private Sessions section, but not the update to Security Considerations. When looked at from this perspective, Security Considerations does seem lacking.
> 
> Ben, will you be happy if this is addressed in Security Considerations? If so I'll open another discussion about that.

To be clear, I was asking for language along the lines of “4566 had this thing; we’re taking it out. Here’s why”. I’m fine if that is covered in the security considerations section. The “Summary of Changes” section could also work. This might be orthogonal to the security considerations language that Christer had in mind (which we should also add.)

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Feb 2019 15:13:32 -0600

> On Feb 18, 2019, at 2:23 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> 
> 
> I'm having trouble finding a suitable semantic definition of Media Description.
> 
> My first thought is that it provides the information necessary to establish a media session. But while *Multimedia Session* is described, media Session isn't defined in the document.
> 
> I looked at RFC7656 (Taxonomy) for a definition, but it doesn't have one either. It defines RTP Session, and Multimedia Session as one or more RTP Sessions. That is close, but in SDP media sessions need not be RTP.
> 
> "A Media Description contains the information needed for one party to establish an application layer network protocol connection to another party." ???
> 
> OR
> 
> "A Media Description contains the information needed for one party to establish a Media Session with another party."
> 
> "A Media Session is an application layer network protocol connection between two parties."
> 
> It seems important to get this right! It is essentially a broadening of RFC7656 beyond RTP.

I am okay with either of those. :-)

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Feb 2019 21:33:43 +0000

Hi,

The first thing we need to make clear, because it has caused some confusion in the past, is whether a "media description" only covers the m- line, OR whether it covers the m- line AND each SDP attribute (a- line) associated with it.

BUNDLE says the following:

     "m=" section: SDP bodies contain one or more media descriptions,
     referred to as "m=" sections.  Each "m=" section is represented by
     an SDP "m=" line, and zero or more SDP attributes associated with
     the "m=" line.  A local address:port combination is assigned to
     each "m=" section.

...which doesn't provide any semantics, but does indicate that the attributes are part of the media description.

After a quick scan through BUNDLE, I couldn't find any semantics, other than a media description is used to "describe media".

But, BUNDLE also says that BUNDLE is used for "using a single transport for sending and receiving media associated with SDP multiple media descriptions".

So, while I don't have exact wording at the moment, my suggestion would be to say that an SDP media description describes a TRANSPORT for a media flow, or something like that... 

Regards,

Christer

On 18/02/2019, 23.14, "mmusic on behalf of Ben Campbell" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Feb 2019 21:58:26 +0000

....or, "transport and properties (codecs etc) of a media flow", because it is more than the IP address and port.

Regards,

Christer

On 18/02/2019, 23.34, "mmusic on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    

    

    Regards,
    
    Christer

        

        Ben.

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

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 19 Feb 2019 06:52:10 +0000

Hi Paul,
I am not sure why we need to  change the definition.

A media description describes the media and it start with a m= line  ... (and so on)

If want to expand maybe say that it must start with an m= line and will include the sdp types as listed in section 5

Media description, if present
         m=  (media name and transport address)
         i=* (media title)
         c=* (connection information -- optional if included at
              session level)
         b=* (zero or more bandwidth information lines)
         k=* (encryption key)
         a=* (zero or more media attribute lines)

Media description is not about RTP since the proto attribute in the m-line can define others see https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2  

for example in draft data-channel-sdpneg we have:  m=application 10001 UDP/DTLS/SCTP webrtc-datachannel which is not RTP.

Roni Even

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, February 18, 2019 10:24 PM
To: Ben Campbell; [email-masked]
Cc: Magnus Westerlund; mmusic WG; 'Colin Perkins'
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description

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

If not, then how about:

OR

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2019 10:47:50 -0500

> If want to expand maybe say that it must start with an m= line and will include the sdp types as listed in section 5

This came up because Ben felt that the current definition was inadequate 
because it is only syntactic. He asked for a semantic definition to be 
added.

IMO the fact that it seems hard to come up with a suitable semantic 
definition makes it more important to do so.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Feb 2019 16:06:32 +0000

Hi,

The media description describes the properties, associated with a data flow, that an endpoint provides in order to properly be able to process data associated with the data flow. It includes IP address and port, and properties specific to the transport protocol and media type associated with the data flow.

...or something like that.

I don't think we need to make it more complicated.

Regards,

Christer

On 19/02/2019, 17.48, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2019 11:22:12 -0500

> The media description describes the properties, associated with a data flow, that an endpoint provides in order to properly be able to process data associated with the data flow. It includes IP add…

I would rather not define it in terms of other undefined things. So I 
have a problem with "data flow".

It clearly has to do with a network connection, but only defines half of 
one.

When used with O/A, it defines only the receiving end of a connection, 
while with declarative SDP it defines both a sending and receiving end.

And while the c= line and the port from the m= line typically specify 
part of a *transport* protocol, the intent in the proto and fmt is to 
identify an application level protocol.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2019 14:10:26 -0500

Ben,

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

When I came back to this 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.

I suggest we trim this back to:

    <unicast-address>  is an address of the machine from which the
       session was created.  For an address type of IP4, this is either a
       fully qualified domain name of the machine or the dotted-decimal
       representation of an IP version 4 address of the machine.  For an
       address type of IP6, this is either a fully qualified domain name
       of the machine or the compressed textual representation of an IP
       version 6 address of the machine.  For both IP4 and IP6, the fully
       qualified domain name is the form that SHOULD be given unless this
       is unavailable, in which case a globally unique address MAY be
       substituted.

And perhaps we should recommend that something bogus may be used to 
preserve some privacy.

I would like some feedback here!

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 13:13:06 -0600

> On Feb 20, 2019, at 1:10 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Ben,
> 
> When I came back to this 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.
> 
> And perhaps we should recommend that something bogus may be used to preserve some privacy.
> 

Works for me.

Thanks!

Ben.

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 20 Feb 2019 23:39:05 +0300

On Wed, Feb 20, 2019 at 10:10 PM Paul Kyzivat <[email-masked]> wrote:

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

Maybe use RFC 7022 for the privacy goal?

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 21 Feb 2019 08:03:15 +0000

Hi Paul,
I think the semantics is that it includes all attributes that describe a specific media on top of the session description and can override session attributes for this specific media
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, February 19, 2019 5:48 PM
To: Roni Even (A); Ben Campbell; [email-masked]
Cc: Magnus Westerlund; mmusic WG; 'Colin Perkins'
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description

On 2/19/19 1:52 AM, Roni Even (A) wrote:
> If want to expand maybe say that it must start with an m= line and 
> will include the sdp types as listed in section 5

This came up because Ben felt that the current definition was inadequate because it is only syntactic. He asked for a semantic definition to be added.

IMO the fact that it seems hard to come up with a suitable semantic definition makes it more important to do so.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Feb 2019 15:58:17 -0500

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

> 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 com…

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.

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

> 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 

So I removed all the discussion of ICE.

Please comment if you think this isn't sufficient or appropriate.

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

I twiddled with this. Does it work for you now?

I left this unchanged.

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

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

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

This text is unchanged since 4566.

I need help with this from a security person.

> 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 defin…

Done.

> Please consider “The IETF MMUSIC working group <[email-masked]> or its successor as designated by the IESG.”

Done.

I left this as-is.

> 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 mi…

Specification Required calls for a designated expert to review the 
registration. I revised the language to ask the expert to consider these 
issues.

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

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

Done.

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

Fixed.

> - “… 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 no…

I cleaned this up and made it explicit that the ABNF is normative and 
this section is only a summary of the ABNF.

I've left this unchanged for now.

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

> This is ambiguous. Are we talking about text that contains fields, or text-containing fields? From context, I assume the latter.

Done.

> Missing article before URI

Done.

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

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 consisten…

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

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.

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.

> 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 def…

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.

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

> Should “specific” be “level”?

Yes. Done.

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

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

I rewrote the paragraph. Hopefully it is better.

> Consider something like "occurrence of recvonly, sendrecv, sendonly, or inactive”. (Please don’t use slashes to substitute for conjunctions.)

Done.

> Please don’t use normative keywords in examples. Examples should never be normative.

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 acknowledgem…

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,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Feb 2019 23:02:41 +0000

Paul, Ben,

(inline)

> On 22 Feb 2019, at 20:58, 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.
> 
> 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.
> 
> 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”). 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.

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

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

Agree.

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

> Specification Required calls for a designated expert to review the registration. I revised the language to ask the expert to consider these issues.
> 
> 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.)
> 
> I cleaned this up and made it explicit that the ABNF is normative and this section is only a summary of the ABNF.
> 
> 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".
> 
> "The "c=" line (connection-field) contains information necessary to establish a connection.”
> 
> 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".
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 

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

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