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

Paul Kyzivat <pkyzivat@cisco.com> Tue, 09 February 2010 20:50 UTC

Return-Path: <pkyzivat@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 A25443A73F6 for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.55
X-Spam-Level:
X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 05C7VTKPRi8H for <dispatch@core3.amsl.com>; Tue, 9 Feb 2010 12:50:12 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6D3DC3A71C3 for <dispatch@ietf.org>; Tue, 9 Feb 2010 12:50:12 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.49,438,1262563200"; d="scan'208";a="85030280"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2010 20:51:19 +0000
Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o19KpJ1t027574; Tue, 9 Feb 2010 20:51:19 GMT
Message-ID: <4B71CAC6.90802@cisco.com>
Date: Tue, 09 Feb 2010 15:51:18 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Anders Kristensen <ankriste@cisco.com>
References: <4B7127E7.8050403@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB84EB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B7185D8.1090807@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20AFB8550@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4B71BFBD.6040202@cisco.com>
In-Reply-To: <4B71BFBD.6040202@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
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:50:13 -0000

Anders,

It was also my assumption going in that this is potentially a problem 
area of general interest.

But the existing solution (as best I understand it) is wed to a 
particular system architecture - not one that we would likely wish to 
see enshrined in a more general standard.

To get beyond that we would need somebody who is interested in doing the 
work to get something more general. I'm not seeing anybody stand up to 
do that. (I know I don't have the time to do it.)

Lacking that, I see no justification to block their getting their event 
package as long as it is suitably scoped.

	Thanks,
	Paul

Anders Kristensen wrote:
> 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
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>