Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00

fanyanping <fanyanping@huawei.com> Tue, 26 May 2009 00:53 UTC

Return-Path: <fanyanping@huawei.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 935B93A6B4E for <dispatch@core3.amsl.com>; Mon, 25 May 2009 17:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.131
X-Spam-Level: ****
X-Spam-Status: No, score=4.131 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_50=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_12=1, MIME_CHARSET_FARAWAY=2.45]
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 UjaKueNzHNHa for <dispatch@core3.amsl.com>; Mon, 25 May 2009 17:53:09 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CFC9C3A6B8B for <dispatch@ietf.org>; Mon, 25 May 2009 17:53:08 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK8009566TWV3@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 26 May 2009 08:32:20 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK80080E6TVY2@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 26 May 2009 08:32:20 +0800 (CST)
Received: from f00134301 ([10.85.29.39]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK800JOP6TV2K@szxml06-in.huawei.com> for dispatch@ietf.org; Tue, 26 May 2009 08:32:19 +0800 (CST)
Date: Tue, 26 May 2009 08:32:19 +0800
From: fanyanping <fanyanping@huawei.com>
To: dispatch@ietf.org, scott.lawrence@nortel.com
Message-id: <003c01c9dd99$6de66400$271d550a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_M8LXu9JZcdg6tqGfsrLLlw)"
Thread-index: AcndmW20ce8n31vtSN+JP/fjWh/3TA==
Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
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, 26 May 2009 00:53:14 -0000

Hi Scott,

I spend some time reading your draft,there is one place i don’t understand
clearly, could you please explain more detail, thanks.

“The requirement for adjacency interferes with a property of SIP that is
otherwise one of its great strengths: that a proxy (or other well-behaved
Intermediate) need not understand every aspect of the requests and responses
it forwards. 。。。。。。。。“

I’m understanding that you imply a new feature needs the Intermediate
entites which make the authorization decision to be upgraded. However,Is
there something associated with adjacency?

 

In addition, i agree that the issues described in your draft are really very
important. But I don’t understand clearly how the requirement of
“Authorizing Third Party” can solve them. I can’t get the requirements
you proposed from these problems.

 

 

 

PS: 

there is one suggestion about the section 2.2, I think the following
paragraphs could be in the section 2.2.1 and have a new title “User Agent
Based Authorization”. Because all of them are describing the problems of
“User Agent Based Authorization”.

 

Specific paragraphs as below:

from

“   Most specifications of SIP mechanisms expect that a request will be

    subjected to an authorization decision by the receiving User Agent

    Server.  If the Alice's UA sends a request to Bob's UA, it is Bob's

    UA that decides (presumably after authenticating that the request is

    really from Alice) whether or not Alice should be allowed whatever

    access the request requires.  This model is the correct one in many

    cases, especially those in which the actual authorization decision

 

to

      The request might be such that the user either could not

      understand the question or be such that the user cannot reasonably

      be expected to understand why permission should be granted.  If

      Bob were asked whether or not Alice should be allowed to receive

      dialog event notices regarding the call he is on now, he would

      probably not understand the question and be annoyed at the

      interruption of his call; he could not tell whether this was in

      support of a future request to Join the call, a future request

      that Alice be able to call him when he becomes available, or just

      in support of lighting the Busy Lamp for his line on Alice's

      phone.”

 

If there is any problem, please correct me. thanks :)

 

 

Best Regards.

nancy

*******************************************************************
This email and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above.
Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons
other than the intended recipient(s) is prohibited. If you receive this
e-mail in error,
please notify the sender by phone or email immediately and delete it!
*******************************************************************