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

Tom Kristensen <2mkristensen@gmail.com> Fri, 10 January 2014 10:50 UTC

Return-Path: <2mkristensen@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132021ADBCE for <mmusic@ietfa.amsl.com>; Fri, 10 Jan 2014 02:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1AjQhSAn4M8 for <mmusic@ietfa.amsl.com>; Fri, 10 Jan 2014 02:50:30 -0800 (PST)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A3ED61AD986 for <mmusic@ietf.org>; Fri, 10 Jan 2014 02:50:30 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id o15so3937614qap.17 for <mmusic@ietf.org>; Fri, 10 Jan 2014 02:50:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTFJXva56wexvva2iauk0rouoGE1OYloiH/8k8OEIRE=; b=JEEtRSsPn6rFLP2YkWiWrFlUx7kt72rW3eMbIISBPgYEIQZYDzBjRIJljcWPD4bYcS Ecm24Atfoew+dMb4k3/IoCF2D74YtW52BAJHTSRCOpQdFmmvBVZdL7b3gbNmq/YOeUU/ a4mGyfT3tUnqYvqrASlGcTSOJZgQPGIBX5Y/X+fZdWAxTHk0qoiET/S9lSbWFQmtOl97 o3Szxi5Pzcre2N4Rkdecghv7IR40CzdsbmPiPTQtmaBm6OS6BJvR7V+5+SrrhXjtg6YP IpiNARez3Vj9Yc7+UhBCmJFWQGlVPlJVlh2UNjEjdbCYq96kHjG//h/kbbveY8ZlGBKo RxKw==
MIME-Version: 1.0
X-Received: by 10.49.131.164 with SMTP id on4mr6026316qeb.16.1389351020681; Fri, 10 Jan 2014 02:50:20 -0800 (PST)
Received: by 10.229.189.9 with HTTP; Fri, 10 Jan 2014 02:50:20 -0800 (PST)
In-Reply-To: <A3B9A40D-0DA8-48B4-B383-F6E043E6EC1A@cisco.com>
References: <A3B9A40D-0DA8-48B4-B383-F6E043E6EC1A@cisco.com>
Date: Fri, 10 Jan 2014 11:50:20 +0100
Message-ID: <CAFHv=r9bOdNw18FS62yM15eHk4RY1fz1nRk82xKNY65Zo9by-w@mail.gmail.com>
From: Tom Kristensen <2mkristensen@gmail.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Content-Type: multipart/alternative; boundary=047d7bd751320e5fae04ef9b7e23
Cc: Tom Kristensen <tomkrist@cisco.com>, "bfcpbis-chairs@tools.ietf.org" <bfcpbis-chairs@tools.ietf.org>, "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" <draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org>, "<mmusic@ietf.org>" <mmusic@ietf.org>
Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 10:50:35 -0000

Great. Thanks for the review. Comments inline.

On 20 December 2013 14:26, Ali C. Begen (abegen) <abegen@cisco.com> 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/
## tomkrist@cisco.com  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/