[MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12

[Paul Kyzivat <[e-mail]>]

I just did a fairly careful WGLC review of 
draft-ietf-mmusic-sdp-bundle-negotiation-12. I have quite a lot of 
comments, but most of them are editorial.

(Note: others have commented on RTP/RTCP extension issues. I won't 
comment on those.)

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

In the same paragraph, s/allows/allow/

* 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/

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.

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

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

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

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. Perhaps this section should similarly 
defer to that draft for bandwidth bundling.

* 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;

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

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

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/

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

* Section 9.2: STUN, DTLS, SRTP

In the first paragraph, s/offer or answerer/offerer or answerer/

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

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

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.

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.

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

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

* 10.3.2.3: Generating the SDP Answer

My comment for 10.3.2.2 applies here as well.

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

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

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

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

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

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

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

THE END

	Thanks,
	Paul