IETF Logo Mail Archive

Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11

<david.black@emc.com> Fri, 29 June 2012 19:23 UTC

Return-Path: <david.black@emc.com>
X-Original-To: bliss@ietfa.amsl.com
Delivered-To: bliss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6521F88A3; Fri, 29 Jun 2012 12:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level:
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8KxSv8lk2DY; Fri, 29 Jun 2012 12:23:42 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42821F889A; Fri, 29 Jun 2012 12:23:42 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TJNYLU021288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 15:23:35 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 29 Jun 2012 15:23:17 -0400
Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TJNHdw022925; Fri, 29 Jun 2012 15:23:17 -0400
Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub34.corp.emc.com ([::1]) with mapi; Fri, 29 Jun 2012 15:23:16 -0400
From: david.black@emc.com
To: dworley@avaya.com, alan.b.johnston@gmail.com
Date: Fri, 29 Jun 2012 15:23:15 -0400
Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-11
Thread-Index: Ac1WK/SS5AOXm0ZpSfqMaQa/q754dwAAIaQQ
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3A9A0@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> <CAKhHsXEzQ9hrsRpkUsAMa2xaNwt8E7QM4ZVadTmqyX7hg0XJ1Q@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B22726A1D0C@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A1D0C@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: mohsen.soroush@sylantro.com, ietf@ietf.org, gen-art@ietf.org, bliss@ietf.org, david.black@emc.com
Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 19:23:44 -0000

That works for me, Thanks, --David

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]
> Sent: Friday, June 29, 2012 3:18 PM
> To: alan.b.johnston@gmail.com
> Cc: Black, David; mohsen.soroush@sylantro.com; ietf@ietf.org; gen-
> art@ietf.org; bliss@ietf.org; vvenkatar@gmail.com
> Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11
> 
> On Thu, 2012-06-28 at 20:05 -0500, Alan Johnston wrote:
> > >
> > > 4.1 - REQ-16:
> > >
> > >   in this case, seizing the line is the same thing as dialing.
> > >
> > > That seems wrong - I would have thought it was a "prerequisite" as
> > > opposed to "the same thing" because seizing the line is immediately
> > > followed by a dialing request.
> >
> >
> > This requirement is about sending one request that causes both actions
> > to occur.  In a PSTN ringdown circuit (a very specialized circuit,
> > used for "hotlines"), the two operations are the same thing.  Besides
> > this statement, is REQ-16 itself not clear?  Perhaps I should just
> > remove this statement if it adds confusion rather than clarity to the
> > requirement.
> 
> IMHO, a good fix is:
> 
>    REQ-16 The mechanism should support a way for a UA to seize a
>    particular appearance number and also send the request at the same
>    time.  This is needed when an automatic ringdown feature (a telephone
>    configured to immediately dial a phone number when it goes off hook)
>    is combined with shared appearances - in this case, seizing the line
>    is >>>integrated with<<< dialing.
> 
> Dale

v2.23.0 | Report a Bug | By Email