Re: [Sipping] FW: New Versiondraft-vanelburg-sipping-private-network-indication-01

"Leis, Peter (NSN - DE/Muenich)" <peter.leis@nsn.com> Wed, 27 February 2008 06:58 UTC

Return-Path: <sipping-bounces@ietf.org>
X-Original-To: ietfarch-sipping-archive@core3.amsl.com
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBE828C473; Tue, 26 Feb 2008 22:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.853
X-Spam-Level:
X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 gsq+Bxz7A1zo; Tue, 26 Feb 2008 22:58:08 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5860728C2EA; Tue, 26 Feb 2008 22:58:01 -0800 (PST)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7291D28C376 for <sipping@core3.amsl.com>; Tue, 26 Feb 2008 22:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 ijTPmK0B+nj4 for <sipping@core3.amsl.com>; Tue, 26 Feb 2008 22:57:58 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0754E3A6AA1 for <sipping@ietf.org>; Tue, 26 Feb 2008 22:57:53 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1R6vgXG026641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 07:57:42 +0100
Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1R6veu6002506; Wed, 27 Feb 2008 07:57:42 +0100
Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Feb 2008 07:57:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 27 Feb 2008 07:57:39 +0100
Message-ID: <81D3255A15981A4B912531E3648B1E16925A81@DEMUEXC005.nsn-intra.net>
In-Reply-To: <2C685FA24AE8004CA8F0DCCC7AF6AD0801CE23AA@esealmw109.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] FW: New Versiondraft-vanelburg-sipping-private-network-indication-01
Thread-Index: Ach1rcdsygjM1DEQRHm0bSg5AXSnLQABfREgAKe5+EAAAkkXMAAsLPCA
References: <2C685FA24AE8004CA8F0DCCC7AF6AD0801C4FB26@esealmw109.eemea.ericsson.se> <81D3255A15981A4B912531E3648B1E169258A5@DEMUEXC005.nsn-intra.net> <2C685FA24AE8004CA8F0DCCC7AF6AD0801CE23AA@esealmw109.eemea.ericsson.se>
From: "Leis, Peter (NSN - DE/Muenich)" <peter.leis@nsn.com>
To: ext Hans Erik van Elburg <hanserik.van.elburg@ericsson.com>, sipping@ietf.org
X-OriginalArrivalTime: 27 Feb 2008 06:57:40.0289 (UTC) FILETIME=[0B1B2310:01C8790E]
Cc: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
Subject: Re: [Sipping] FW: New Versiondraft-vanelburg-sipping-private-network-indication-01
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hans Erik

you are right, 7.2.2 does not have to talk about removing the new
indication. This is covered in 7.2.3.

on 7.2.3 it needs to be sufficiently clear, that a "regular" user (i.e.
a non-enterprise user) never gets the indication. Maybe some words can
be indluded in 7.2.3. However, this leaves me with the question "how
does the edge proxy know, that the next hop is a regular user and not
belonging to an enterprise"? 


regs
Peter 

> -----Original Message-----
> From: ext Hans Erik van Elburg 
> [mailto:hanserik.van.elburg@ericsson.com] 
> Sent: Tuesday, February 26, 2008 4:38 PM
> To: Leis, Peter (NSN - DE/Muenich); sipping@ietf.org
> Cc: DRAGE, Keith (Keith)
> Subject: RE: [Sipping] FW: New 
> Versiondraft-vanelburg-sipping-private-network-indication-01
> 
> Hi Peter,
> 
> Thanks for reading the draft.
> 
> On 7.2.1:
> Breakin can happen inside the public network. But I think we 
> need to add
> some extra information here saying that the indication only 
> needs to be
> added if the next hop or sip trunk send to does not 
> implicitly mean that
> the traffic is private.
> 
> On 7.2.2:
> To be able to apply the special processing behaviours you have to
> understand the extension. So you must support the extension. 
> The special
> processing behaviour are dependent on the specific business agreements
> and regulatory requirements.
> 
> PL> - I propose to add that in case the indication is received from a
> entitiy that is not trusted, then the Proxy MUST remove the indication
> I think this is covered by 7.2.3, do you think that needs to be
> clarified?
> 
> on 7.2.3:
> The traffic should not be delivered to a user outside the enterprise
> with an indicator. Because effectively the traffic has left 
> the private
> network (it is public network traffic). Do you think that 
> such would be
> clarified by having descriptive text elsewhere in the draft describing
> breakout and breakin functions?
> 
> Best Regards,
> /Hans Erik
> 
> -----Original Message-----
> From: Leis, Peter (NSN - DE/Muenich) [mailto:peter.leis@nsn.com] 
> Sent: Tuesday, February 26, 2008 9:48 AM
> To: sipping@ietf.org
> Cc: Hans Erik van Elburg
> Subject: RE: [Sipping] FW: New
> Versiondraft-vanelburg-sipping-private-network-indication-01
> 
> 
>  Hans Erik
> 
> some comments
> 
> 7.2.1
> I don't understand why incoming public traffic to a corporate needs to
> be marked as Private. I thought the "private" indication is 
> only usefull
> in public networks.
> 
> 7.2.2
> - "MUST support" this extension is rather vague. What is the real
> requirement here in terms of protocol usage? Are there any procedures
> expected to happen in the proxy?
> 
> - I propose to add that in case the indication is received from a
> entitiy that is not trusted, then the Proxy MUST remove the indication
> 
> 7.2.3
> what is meant with "converting private traffic to public traffic"?  Is
> forwarding a request that contains the new indication towards a user
> (not beloinging to any corporate) also regarded as "converting private
> traffic to public traffic"?
> 
> 
> Peter
> 
> > -----Original Message-----
> > From: sipping-bounces@ietf.org
> > [mailto:sipping-bounces@ietf.org] On Behalf Of ext Hans Erik van 
> > Elburg
> > Sent: Saturday, February 23, 2008 1:39 AM
> > To: sipping@ietf.org
> > Subject: [Sipping] FW: New
> > Versiondraft-vanelburg-sipping-private-network-indication-01
> > 
> > 
> > A new version of I-D,
> > draft-vanelburg-sipping-private-network-indication-01.txt has been 
> > successfuly submitted.
> > 
> > http://tools.ietf.org/html/draft-vanelburg-sipping-private-net
> > work-indic
> > ation-01
> > 
> > Revision Information
> > - Added a solution based on a new header.  
> > - Added Overview, Behaviour and Header Definition sections.  
> > - Updated the trust domain definition.  Improved some of 
> the existing 
> > text
> >   based on received comments.
> > 
> > Filename:	 draft-vanelburg-sipping-private-network-indication
> > Revision:	 01
> > Title:		 Requirements for explicit private 
> > network indication
> > Creation_date:	 2008-02-22
> > WG ID:		 Independent Submission
> > Number_of_pages: 15
> > 
> > Abstract:
> > This document describes why a private network indication is needed.
> > A private network indication allows other nodes in a 
> network to treat 
> > private network traffic to a different set of rules then public 
> > network traffic.  The indication also distinguishes one private 
> > network from another private network.
> >  
> > 
> > 
> > Best Regards,
> > /Hans Erik
> > 
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > sip@ietf.org for new developments of core SIP
> > 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP