IETF Logo Mail Archive

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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 19 February 2014 16:11 UTC

Return-Path: <eckelcu@cisco.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 A26221A021B for <mmusic@ietfa.amsl.com>; Wed, 19 Feb 2014 08:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level:
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ira_--8BORfz for <mmusic@ietfa.amsl.com>; Wed, 19 Feb 2014 08:11:10 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id E6E631A0209 for <mmusic@ietf.org>; Wed, 19 Feb 2014 08:11:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7756; q=dns/txt; s=iport; t=1392826267; x=1394035867; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NZVW3nI6V1JvK2jltznsZR05R1a/jtHkIMNLAXlh3Wc=; b=BspOpYPoNfy4Rv+tBGzqkcCSojN4FKTS8ee4NFSabVhutRUVhvuxLIR7 7A6drGbW9OYPYQyuLjbOhOo83eqSNjKKrP0Ft36G1TukK2bYcPAf78Yjr e0/vBQBv6wmX3G5j1SqkKk+zSvaAyQI09VE1Og1P3WiDYS6FgZb+JRzRq E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFALLWBFOtJXG//2dsb2JhbABZgkJEgQ+/eYEXFnSCJQEBAQR5EAIBCA4DAwECKAchERQJCAIEDgWHcQMRxX8Nh34XjE+CBBEHhDgElkSBbIxehUaDLYIq
X-IronPort-AV: E=Sophos; i="4.97,506,1389744000"; d="scan'208,217"; a="21593012"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 19 Feb 2014 16:11:04 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1JGB3d3018683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 16:11:03 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 10:11:03 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Tom Kristensen <2mkristensen@gmail.com>
Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08
Thread-Index: AQHO/YcWZ2DzntYTsE+pusHe8am5zZp+TQkAgABw7wCABL+ZAIAwa9+AgAkUVYA=
Date: Wed, 19 Feb 2014 16:11:03 +0000
Message-ID: <CF2A162F.1F4C5%eckelcu@cisco.com>
References: <A3B9A40D-0DA8-48B4-B383-F6E043E6EC1A@cisco.com> <CAFHv=r9bOdNw18FS62yM15eHk4RY1fz1nRk82xKNY65Zo9by-w@mail.gmail.com> <C4438E90-A049-4A0F-B959-AE135B4B5819@cisco.com> <CEF9D183.1A631%eckelcu@cisco.com> <CAFHv=r_MvOubfhCp8m0w09dJpszVabOekn=sE4KG+UvxygUutQ@mail.gmail.com>
In-Reply-To: <CAFHv=r_MvOubfhCp8m0w09dJpszVabOekn=sE4KG+UvxygUutQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.74.217]
Content-Type: multipart/alternative; boundary="_000_CF2A162F1F4C5eckelcuciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7ZgFxCQVbOsX6LSE5-qOXJfujG8
Cc: "bfcpbis-chairs@tools.ietf.org" <bfcpbis-chairs@tools.ietf.org>, "<mmusic@ietf.org>" <mmusic@ietf.org>, "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" <draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
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: Wed, 19 Feb 2014 16:11:12 -0000

Hi Tom,

The proposed changes look good. One question inline with the rest of the text omitted.

From: Tom Kristensen <2mkristensen@gmail.com<mailto:2mkristensen@gmail.com>>
Date: Thursday, February 13, 2014 at 5:31 AM
To: Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>
Cc: "Ali C. Begen (abegen)" <abegen@cisco.com<mailto:abegen@cisco.com>>, Tom Kristensen <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>, "bfcpbis-chairs@tools.ietf.org<mailto:bfcpbis-chairs@tools.ietf.org>" <bfcpbis-chairs@tools.ietf.org<mailto:bfcpbis-chairs@tools.ietf.org>>, "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org>" <draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org>>, "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08

On 14 January 2014 03:05, Charles Eckel (eckelcu) <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> wrote:
I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to
deal with them.

<snip>

5) There are several SHOULDs in section 7, which defines the new bfcpver
attribute. As this attribute did not exist in RFC 4583, the SHOULDs are
warranted for backward compatibility. However, they can be made mandatory
for implementations of BFCP/UDP as well as those compliant with this
update to RFC 4583.

True, and as proposed in the accompanying BFCPbis WG PROTO review thread merging in this requirement for implementations of the upcoming RFCXXX of this draft. The paragraph will then read:

  "Endpoints that use the offer/answer model to establish BFCP
   connections SHOULD support the 'bfcpver' attribute. A floor control
   server acting as an offerer or as an answerer SHOULD include
   this attribute in its session descriptions.   However, endpoints that
   support RFCXXXX, and not only the RFC 4583 subset, are
   REQUIRED to support and, when acting as a floor control server
   to use the 'bfcpver' attribute.  [...]"

Why is the condition ", when acting as a floor control server” relevant here?

Cheers,
Charles

v2.23.0 | Report a Bug | By Email