IETF Logo Mail Archive

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

Tom Kristensen <tomkrist@cisco.com> Thu, 13 February 2014 14:15 UTC

Return-Path: <tomkrist@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 4CD321A0273 for <mmusic@ietfa.amsl.com>; Thu, 13 Feb 2014 06:15:04 -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 UeiuqySqChD9 for <mmusic@ietfa.amsl.com>; Thu, 13 Feb 2014 06:15:02 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 680C41A02B5 for <mmusic@ietf.org>; Thu, 13 Feb 2014 06:14:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4508; q=dns/txt; s=iport; t=1392300883; x=1393510483; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=5wi+cRj1kkAzRgEHojJxC6nE85Pwql2l83WrtFEAdEI=; b=k77GL80FelOczB50M5rjJHcGE6nQXq6AZ29C4gaHhuhxmSX8/0U95t4A cHFXejvDeXVx/w9T6nVYoO1nDTaKFJjeLpfwtWeUPusmOqb/8ePinhZ5a o6LMgTSdFEd7AAfnfaQ+FO5Dcrao1GIdTUXH0EF+8pw8vO1mWjoTvAzm2 M=;
X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208,217";a="5010053"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 13 Feb 2014 14:14:41 +0000
Received: from [10.61.91.92] (ams3-vpn-dhcp7005.cisco.com [10.61.91.92]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DEEfgf013558; Thu, 13 Feb 2014 14:14:41 GMT
Message-ID: <52FCD350.90104@cisco.com>
Date: Thu, 13 Feb 2014 15:14:40 +0100
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Tom Kristensen <2mkristensen@gmail.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>
Content-Type: multipart/alternative; boundary="------------010708080104010105000003"
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>
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: Thu, 13 Feb 2014 14:15:04 -0000

On 02/13/2014 02:31 PM, Tom Kristensen wrote:
> 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.
>

[...]

>     6) From section 8.1:
>     "When the existing TCP connection is reset following the rules in [8
>     <http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-08#ref-8>],
>        the client SHOULD generate an offer towards the floor control
>     server
>        in order to reestablish the connection.  If a TCP connection cannot
>        deliver a BFCP message and times out, the entity that attempted to
>        send the message (i.e., the one that detected the TCP timeout)
>     SHOULD
>        generate an offer in order to reestablish the TCP connection."
>
>     I am not sure about these. I think they could be changed to "MUST".
>     Hopefully others can chime in.
>
>
> This might be considered being part of application logic/policy, but I 
> can't see a reason for not trying to reestablish the connection here 
> and now. Anyway, I'll leave these two as "SHOULD". Shout out if you 
> disagree.

I'm disagreeing with the previous version of me. This will be changed to 
"MUSTs" for the two cases, I cannot really see a reason for keeping the 
"SHOULDs".

-- Tom

<snip>

v2.23.0 | Report a Bug | By Email