Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments

[Christer Holmberg <[e-mail]>]

Hi Paul,

Thanks for your review! See inline.

-------------------------

>*< Abstract:
>
>The following language is a little awkward:
>
>    Both endpoints can negotiate the use of bundle and to support that
>    negotiations, this specification ...
>
>How about the following:
>
>    To assist endpoints in negotiating the use of bundle this
>    specification ...

OK.

> In the same paragraph, s/allows/allow/

OK.

-------------------------

>* Section 1: Introduction:
>
>In the third paragraph is:
>
>    The BUNDLE address is used to send and receive
>    all media associated with the BUNDLE group.
>
>In the above, s/address is/addresses are/

OK.

-------------------------

>The 6th paragraph says:
>
>    This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
>    [RFC3264].  The update allows an answerer to assign a non-zero port
>    value to an "m=" line in an SDP answer, even if the "m=" line in the
>    associated SDP offer contained a zero port value.
>
>The statement of the update is overly broad, because it doesn't state that the relaxation on answering with a non-zero port only applies within a bundle. I suggest the following:
>
>    This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
>    [RFC3264].  The update allows an answerer to assign a non-zero port
>    value to a bundled "m=" line in an SDP answer, even if the "m=" line
>    in the associated SDP offer contained a zero port value.

I can do that change, but keep in mind that the new RFC 3264 text does not talk about BUNDLE, but more generically say that an extension can define new semantics for a port zero value in an offer.

-------------------------

>* Section 2: Terminology
>
>In the following:
>
>    BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer
>    exchange, for which each endpoint uses a single 5-tuple to send and
>    receive media.  Each endpoint uses its BUNDLE address, associated
>    with the BUNDLE group, to send and receive the media.
>
> are we *requiring* symmetric media usage? Certainly you must *receive* on your bundle address, but AFAIK *sending* on that address is, in general, optional though various options that > might be used with it (such as ICE) may require it.

The definition of "BUNDLE address" states that the address is used for both sending and receiving media.

-------------------------

>* Section 6: SDP 'bundle-only' Attribute
>
>I would like to see the definition follow the new style introduced in draft-ietf-mmusic-rfc4566bis-12. This draft is nearer to completion to that one, and there is some risk that the new style >will be revised in that draft. I don't propose to hold this draft up for that one - there should not be any formal dependency.

I'll look into that.

One comment, that I will provide in a separate e-mail, I have on the new style is that it should define (or, at least refer to) the Offer/Answer procedures for the attribute.

-------------------------

>* Section 7.3: Bandwidth
>
>Says:
>
>    The total proposed bandwidth for a BUNDLE group is the sum of the
>    proposed bandwidth for each bundled "m=" line.
>
>What if some of the bundled m-lines have no b= line, while others do? It probably doesn't make sense to treat them as having zero bandwidth. I guess maybe some default value should be >used. But what?

You do whatever you'd do for a non-BUNDLED "m=" line. Normally I guess you have a default value, or a value based on the media type and/or payload formats.

>Or, I guess there could be a rule that if any of the bundled m-lines have b= then all of them must.
>
>Also, I guess there needs to be a separate sum for each bandwidth type.
>
>Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes.
>
>I note that section 7.3 defers to draft-ietf-mmusic-sdp-mux-attributes
>for attribute bundling rules. 

I assume you mean section 7.4?

>Perhaps this section should similarly defer to that draft for bandwidth bundling.

The "b=" parameter is not covered by that draft (as it's not an SDP attribute).

-------------------------

>* Section 8.2.1: Generating the Initial SDP Offer: General
>
>The use of "assign" in the second bullet item seems inappropriate:
>
>    o  Assign an SDP 'group:BUNDLE' attribute to the offer;
>
>I suggest instead:
>
>    o  Add a new SDP 'group:BUNDLE' attribute to the offer
>       for the new BUNDLE group;

OK.

-------------------------

>* Section 8.2.2: Request offerer BUNDLE address selection
>
>I think the name of this section is slightly confusing - "Request" could be a verb (intended) or a noun. I suggest changing it to:
>
>"Suggesting an offerer BUNDLE address"

I use "Request" in other places (e.g. "offerer requested the BUNDLE group") so I'd like to keep the text.

In addition, aren't you the one who suggested "Request" terminology in the past? :)

-------------------------

>* Section 8.3.2: Answerer Selection of Offerer Bundle Address
>
>I have a few wording changes to suggest for clarity:
>
>In this section, the use of 'the "m=" line' seems a little vague. I think it would be better to change it to 'that "m=" line' throughout.

I do agree that we could use the following modified sentence:

	"The answerer MUST check whether that "m=" line fulfils the following criteria:"

But, after that, I think all instances of 'the' refers to that 'that' :)

>Also
>- s/fulfils/fulfills/
>- s/criteria above is fulfilled/criteria above are fulfilled/
>- s/criteria is not fulfilled/criteria are not fulfilled/
>- s/represents/identifies/

OK.

-------------------------

>* Section 8.4.1: Offerer Processing of the SDP Answer: General
>
>In the following:
>
>    When an offerer receives an answer, if the answer contains a BUNDLE
>    group, the offerer MUST check that any bundled "m=" line in the
>    answer was indicated as bundled in the associated offer.  If there is
>    no mismatch, the offerer MUST apply the offerer BUNDLE address,
>    selected by the answerer [Section 8.3.2], to each bundled "m=" line.
>
> the use of the word "apply" is a little unclear. While the intent can be inferred, it isn't defined anywhere, or used in this way anywhere else. 
>I suggest it could be written as:
>
>    ... the offerer MUST use the offerer BUNDLE address, selected by
>    the answerer [Section 8.3.2], as the address for each bundled
>    "m=" line.

OK.

-------------------------

>* Section 9.2: STUN, DTLS, SRTP
>
>In the first paragraph, s/offer or answerer/offerer or answerer/

OK.

>Replace the following:
>
>   ... If an offer or answerer in offers or answers include
>    bundled "m=" lines that represent these protocols, the offerer or
>    answerer MUST support ...
>
>with:
>
>    ... If an offer or answer includes bundled "m=" lines that represent
>    these protocols, the offerer or answerer MUST support ...

OK.

>Another thing: I *think* that *plain* RTP can also coexist with STUN, DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if this is true?)

I'll ask Colin.

>Also, there is *no* mention of SCTP in this document. ISTM that there should be something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle.

The document does not cover SCTP - unless it is transported on top of DTLS, in which case it is implicitly covered by the 2nd paragraph.

What would you like to mention about SCTP?

>IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS payload packets. So *one* m-line with a protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines.

I think that is covered, as SRTP is distinguished from DTLS.

But, if you think that needs to be more clear, maybe the following modified sentence:

	"[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..."

-------------------------

>* Section 10.1.1: Single RTP Session: General
>
>The second bullet:
>
>    o  The "proto" value in each bundled "m=" line MUST be identical
>       (e.g.  RTP/AVPF).
>
>should only apply to RTP m-lines. E.g.:
>
>    o  The "proto" value in each bundled RTP-based "m=" line MUST be
>       identical (e.g.  RTP/AVPF).

OK.

-------------------------

>* 10.3.2.2: Generating the Initial SDP Offer
>
>Similar comment to the previous one:
>
>   s/each bundled "m=" line/each bundled RTP-based "m=" line/
>
>(It occurs twice in the paragraph.)

OK.

-------------------------

>* 10.3.2.3: Generating the SDP Answer
>
>My comment for 10.3.2.2 applies here as well.

OK.

>The MUST NOT in the 2nd paragraph concerns me:
>
>    If the answerer accepts usage of RTP/RTCP multiplexing within the
>    BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each
>    bundled "m=" line in the answer.  The answerer MUST NOT assign an SDP
>    'rtcp' attribute to any bundled "m=" line in the answer.  The
>    answerer will use the port number of the selected offerer BUNDLE
>    address for sending RTP and RTCP packets associated with each bundled
>    "m=" line towards the offerer.
>
>I don't understand why the rtcp attribute MUST NOT be used. I understand that the port from the offer is 
>used by the answerer to send RTCP. But without the attribute there is no explicit indication of where the 
>offerer is to send RTCP. What is wrong with including the rtcp attribute in the answer???
>
>Also, in general (ignoring bundle), isn't it valid to use the 'rtcp' attribute without the 'rtcp-mux'? (I thought 
>it was invented for cases where NATs prevented getting an even/odd pair of ports.) So in bundle, shouldn't 
>it also be valid to use the 'rtcp' attribute without the 'rtcp-mux' attribute? (Identical in all m-lines.)

The reason we don't allow 'rtcp' in the answer (even if RTP/RTCP multiplexing is not used) is because in the offer we only allow the value of the "m=" line (i.e. the value used for RTP) for 'rtcp'. 

So, either multiplexing is used, or port+1 is used. If we'd change that, we should also allow the offerer to assign whatever value it wants to the 'rtcp' attribute...

-------------------------

>* Section 12: Update to RFC 3264
>
>The way in which the changes are presented are great for somebody who is not familiar with 3264 and is truly reading this instead. (Or for somebody who is authoring >3264bis.) But it is quite difficult to understand what the differences are between the two. I had to copy the text out into separate old and new files and then diff them to >clearly understand what has changed.
>
>I'd appreciate some sort of diff that highlights the fundamental distinctions. (But I'm not sure what kind would be clear and work with the constraints of a draft.)

The Introduction states that the change is related to the usage of port zero, so having that information I think it is not that difficult to see what has been changed.

Also, my experience from the IESG reviews is that there are always different suggestions on how to update text. So, I'd prefer to keep it as it is, because it may still come up as part of the IESG review.

-------------------------

>* Section 12.5: New text replacing section 8.2 (2nd paragraph)
>
>I take issue with one change here - the addition of "(like the offer)". 
>I don't know if you intend it that way, but to me it seems to suggest that you can only omit attributes if they were omitted in the offer.
>
>So I think that particular part of the change should be removed.

The intention is not to indicate that one can only omit attributes if they were omitted in the offer.

I am ok to remove "(like the offer)".

-------------------------

>* Section 16: Examples
>
>The ordering of fields in the examples in not valid according to the rules of 4566. It requires "c=", "b=", "a=" in that order.

OK.

The examples were provided by Harald, so I hope they are not based on a Chrome trace ;)

-------------------------

>* Section 16.3
>
>I gather that this example is intended to continue on from the the example in 16.1. It would be helpful to say that.

OK.

-------------------------

>* Section 16.4
>
>I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that.

OK.

-------------------------

>* Section 16.5
>
>I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that.

OK.

-------------------------

Thanks!

Regards,

Christer