Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08

[Tom Kristensen <[e-mail]>]

Great. Thanks for the review. Comments inline.

On 20 December 2013 14:26, Ali C. Begen (abegen) <[e-mail]> wrote:

> I am the assigned SDP directorate reviewer for this draft. For background
> on the SDP directorate, please see the FAQ at
>
> http://www.ietf.org/iesg/directorate/sdp.html
>
> Please wait for direction from your document shepherd or AD before posting
> a new version of the draft.
>

Aye aye, Captain!

Summary:
> - There are a few minor issues as indicated below.
>
> Issues:
> 1) Section 3 uses m=<media> <port> <transport> <fmt> and refers to 4566
> but 4566 actually uses m=<media> <port> <proto> <fmt> .
>
> The newly defined 4 values (TCP/BFCP, TCP/TLS/BFCP and the UDP
> equivalents) are actually the proto values that are registered with IANA
> (not transport values). Thus, I recommend changing the text to reflect this.
>

 I agree. This is inherited from RFC 4583, but as long as RFC 4566 is
referenced we should use a corresponding definition. I will change.


> 2) Definition of "floorctrl" attribute. I think the answer has to include
> only one role if the offer had this attribute. If that is correct, I
> suggest the following change:
>
> OLD:
>    If an SDP media description in an offer contains a 'floorctrl'
>    attribute, the answerer accepting that media MUST include one in the
>    corresponding media description of the answer.
>
> NEW:
>    If an SDP media description in an offer contains a 'floorctrl'
>    attribute, the answerer accepting that media MUST include only one in
> the
>    corresponding media description of the answer.
>

Yes, the answer must have one - and only one - floorctrl attribute value,
i.e. role. However, in the last sentence of Section 4 it is stated that:

   The following is an example of a 'floorctrl' attribute in an offer.
   When this attribute appears in an answer, it only carries one role:


I think that is sufficient and we haven't seen any cases of
misinterpretation of this in the field!

3) There are a few "SHOULD"s. I think they are OK but it is not clear when
> it is OK to ignore that SHOULD. If there are no such use cases, maybe they
> can be replaced with a "MUST"?
>

This is inherited from the original RFC 4583, that's the main reason for me
to suggest not changing this in this draft. Hopefully, that's fine?

-- Tom

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/