Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02

Anders Kristensen <ankriste@cisco.com> Tue, 09 February 2010 20:03 UTC

Return-Path: <ankriste@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8411628C0FB for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ux3R+BJQY52 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:03:05 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7EF1728C0D0 for <dispatch@ietf.org>; Tue, 9 Feb 2010 12:03:05 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPdOcUurRN+K/2dsb2JhbADCJ5gngkIHggsEjkc
X-IronPort-AV: E=Sophos;i="4.49,438,1262563200"; d="scan'208";a="148322035"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2010 20:04:13 +0000
Received: from [128.107.147.3] (dhcp-128-107-147-3.cisco.com [128.107.147.3]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o19K4D7D021609 for <dispatch@ietf.org>; Tue, 9 Feb 2010 20:04:13 GMT
Message-ID: <4B71BFBD.6040202@cisco.com>
Date: Tue, 09 Feb 2010 12:04:13 -0800
From: Anders Kristensen <ankriste@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B7185D8.1090807@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Prorgessing draft-avasarala-dispatch-comm-div-notification-02
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2010 20:03:06 -0000

IIUC the IMS use case (or one of them) is that users may configure call 
forwarding services and forget that they've done so. The CDIV feature 
then allows them to learn of calls being forwarded and take corrective 
action. This is not at all IMS specific - the same use case can be said 
to exist in non-IMS deployments.

I suspect addressing this problem in a general way is no more work than 
to do it in an IMS specific way but would make for a better standard. 
What's more, if I'm right and this is inherently not an IMS specific 
problem then the solution is likely to be picked up and used in other 
contexts regardless of whatever stern wording is on the front page of 
the RFC.

Thanks,
Anders

On 2/9/2010 8:53 AM, DRAGE, Keith (Keith) wrote:
> I think that is a given and if that is the way to go, I'm sure we'll all make sure the words on the front cover go that way.
>
> But there seemed to be some prior responses trying to take potential use cases beyond that, and I wanted to make sure that if they existed, they were explicitly declared.
>
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Tuesday, February 09, 2010 3:57 PM
>> To: DRAGE, Keith (Keith)
>> Cc: Gonzalo Camarillo; DISPATCH; Mary Barnes
>> Subject: Re: [dispatch] Prorgessing
>> draft-avasarala-dispatch-comm-div-notification-02
>>
>> I don't have a problem with it being IMS-specific.
>> I just want it to *say* that it is IMS-specific.
>>
>> 	Thanks,
>> 	Paul
>>
>> DRAGE, Keith (Keith) wrote:
>>> At the moment, I think those of us looking at this from the
>> 3GPP way of doing things do not see a more general
>> application of this.
>>>
>>> I do not have a problem with doing it more generally, but I
>> guess the people who see a clear use case for that need to
>> speak up and identify their use cases.
>>>
>>> Otherwise we end up designing a general event package that
>> no one else ever uses. As opposed to the alternative of
>> clearly stating the restricted use to a particular
>> applicability, approving it, and moving on to something else
>> with our restricted amount of resources.
>>>
>>> regards
>>>
>>> Keith
>>>
>>>> -----Original Message-----
>>>> From: dispatch-bounces@ietf.org
>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
>>>> Sent: Tuesday, February 09, 2010 9:16 AM
>>>> To: DISPATCH
>>>> Cc: Mary Barnes
>>>> Subject: [dispatch] Prorgessing
>>>> draft-avasarala-dispatch-comm-div-notification-02
>>>>
>>>> Hi,
>>>>
>>>> there have been a set of messages on the list providing
>> comments on
>>>> the draft below:
>>>>
>>>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
>>>> otification-02
>>>>
>>>> As you know, the process for defining SIP event packages is
>>>> documented here:
>>>>
>>>> http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#se
>>>> ction-4.1
>>>>
>>>> Based on the feedback received, the authors need to decide whether
>>>> they want to generalize their solution so that is is generally
>>>> applicable to the public Internet or if they want to (further)
>>>> clarify that this mechanism is intended to work only in
>> IMS networks
>>>> that provide a CDIV service.
>>>>
>>>> If the authors choose the latter approach, we (the DISPATCH
>>>> chairs) will choose a "Designated Expert" who will check the draft
>>>> against the 7 points described in the document above.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>> DISPATCH co-chair
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>