[dispatch] Fwd: [Sipping] Fwd: Expert review ofdraft-vanelburg-sipping-private-network-indication-03
Hans Erik van Elburg <ietf.hanserik@gmail.com> Mon, 06 July 2009 11:12 UTC
Return-Path: <ietf.hanserik@gmail.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 9CF3F3A6CBA for <dispatch@core3.amsl.com>; Mon, 6 Jul 2009 04:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level:
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 keTz5PuCPjR4 for <dispatch@core3.amsl.com>; Mon, 6 Jul 2009 04:12:39 -0700 (PDT)
Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 3052B3A6C96 for <dispatch@ietf.org>; Mon, 6 Jul 2009 04:12:38 -0700 (PDT)
Received: by ewy7 with SMTP id 7so1731419ewy.37 for <dispatch@ietf.org>; Mon, 06 Jul 2009 04:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=k08m/5D/E4zY6VDoNKyAaDQf3o6Ja9CdRE7pRc9MegE=; b=f/wC3LMxYX+wULO6ssv3oxz8BN3fpwJTqYOTOsnzfYWRejhGXI9jKSYDxlkmh78QV/ tDYs2okEPHKj9vzgBT1NVVj6YImrG81wVmQbaeZXdFkL5FYTtopYq+rSLI4/h719Lsfs Wjzc6z3GkKnE5eN3sfC72MRFAWzF49SFamuxU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Tp8qfoYJNqxBEuXd5sEkCeC0mdToaexBP0Tzc6clBIMR4sffoNMZ9qPA+gs1hgBmP3 pewdfVkBDkGe78ELfFJ+XCgj+Qs0UGkVwTJUFosqDjvWeAbOvj+HzeV/4+TDefX8X3mj zQhgfzVLMlwE1fsSsvNnokHSCBjuf0KrZxnK8=
MIME-Version: 1.0
Received: by 10.210.144.3 with SMTP id r3mr1042754ebd.44.1246878600216; Mon, 06 Jul 2009 04:10:00 -0700 (PDT)
In-Reply-To: <9ae56b1e0907060406p3d42b0fdled2bb34f55d6b896@mail.gmail.com>
References: <AcnTzw5dx+joO13zQeugGcDGqqjeNg==@siemenscomms.co.uk> <0D5F89FAC29E2C41B98A6A762007F5D001E1A290@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907021519h5093aec3g5023cc7c6a38ba32@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00218C5B3@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907030710i5e51de42icfbcc0d0064b5ddd@mail.gmail.com> <9ae56b1e0907030716w738f1167n889e26694f71087c@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00218C81B@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907060242r7c408393u5333749a88b958a8@mail.gmail.com> <9ae56b1e0907060406p3d42b0fdled2bb34f55d6b896@mail.gmail.com>
Date: Mon, 06 Jul 2009 13:10:00 +0200
Message-ID: <9ae56b1e0907060410jd5389f5q81f28279984c8615@mail.gmail.com>
From: Hans Erik van Elburg <ietf.hanserik@gmail.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="0015174be6d20b4185046e078c0c"
Subject: [dispatch] Fwd: [Sipping] Fwd: Expert review ofdraft-vanelburg-sipping-private-network-indication-03
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: Mon, 06 Jul 2009 11:12:41 -0000
The updates after expert review of the draft-vanelburg-sipping-private-network-indication-03 has been submitted to dispatch as: http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-00 or plain text: http://tools.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-00.txt Best Regards, /Hans Erik van Elburg ---------- Forwarded message ---------- From: Hans Erik van Elburg <ietf.hanserik@gmail.com> Date: Mon, Jul 6, 2009 at 1:06 PM Subject: Re: [Sipping] Fwd: Expert review ofdraft-vanelburg-sipping-private-network-indication-03 To: "Elwell, John" <john.elwell@siemens-enterprise.com> Cc: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, IETF Sipping List < sipping@ietf.org> Draft has been uploaded as http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-00 Best Regards, /Hans Erik van Elburg On Mon, Jul 6, 2009 at 11:42 AM, Hans Erik van Elburg < ietf.hanserik@gmail.com> wrote: > Hi John, > > 1. Done, moved 10 up and inserted as 1.2. Added the following sentence to > 1.1: > "3GPP and ETSI TISPAN have identified a set of requirements that can be met > by defining a new SIP P-header, according to the procedures in RFC 3427 > [RFC3427]." > 2. Done > 4a. Done > 4b. Done > 4c. Done > 5. I added the following terminology description: > > "3.1. Traffic > > In the context of this document the term traffic is understood as all > communication pertaining to and/or controlled by a SIP transaction or > dialog." > > 8. Done > > Will upload this as cutoff day for 00 drafts is today. > > /Hans Erik van Elburg > > > > On Mon, Jul 6, 2009 at 8:52 AM, Elwell, John < > john.elwell@siemens-enterprise.com> wrote: > >> Hans Erik, >> >> > -----Original Message----- >> > From: sipping-bounces@ietf.org >> > [mailto:sipping-bounces@ietf.org] On Behalf Of Hans Erik van Elburg >> > Sent: 03 July 2009 15:17 >> > To: Elwell, John; DRAGE, Keith (Keith) >> > Cc: IETF Sipping List >> > Subject: [Sipping] Fwd: Expert review >> > ofdraft-vanelburg-sipping-private-network-indication-03 >> > >> > Resent and history removed as otherwise rejected by mailing list. >> > >> > Hi John, >> > >> > 1. Again the required applicability statement is in section >> > 10 of the main body. (Same pattern has been followed in >> > RFC5502, 5002 and 4457) which I took as examples. Together >> > with the additional text in the abstract that should be >> > sufficient. If the text in section 10 needs to be improved >> > then please indicate so. >> [JRE] I must have written the original comment 1 before I got down to >> section 10. Basically section 10 is far too late in the document, and I >> would have expected the statement, perhaps as section 1, or perhaps as a >> section 1.2 before the existing 1.2. >> >> >> > >> > 2. Took in your nits, the abstract now reads: >> > "This document specifies the SIP P-Private-Network-Indication >> > P-header. The use of this private network indication extension >> > is only applicable inside an administrative domain with >> > previously agreed-upon policies for generation, transport and >> > usage of such information. A private network indication >> > allows nodes in such a domain to treat private network traffic >> > according to a different set of rules then than the set >> > applicable to public network traffic. The indication also >> > distinguishes traffic from one private network from another >> > private network." >> [JRE] >> Delete the word "then". >> >> > >> > 4a. Regarding 1.2 item b). Would the following rewrite help?: >> > OLD: >> > " b) business trunking application, where the NGN hosts >> > transit capabilities between NGCN's, break-in capabilities >> > from NGN to NGCN and break-out capabilities from NGCN to NGN; and" >> > /OLD >> > >> > >> > NEW: >> > " b) business trunking application, where the NGN hosts >> > transit capabilities between NGCN's, break-in capabilities >> > where the NGN converts public network traffic to private >> > network traffic for delivery at a served NGCN and break-out >> > capabilities where the NGN converts private network traffic >> > from a served NGCN to public network traffic; and" >> > >> > /NEW >> > >> > If not please suggest an improved sentence that covers your >> > concern. Please note that in the example that you gave it is >> > not the business trunking application that does the >> > conversion, but the hosted enterprise application. >> [JRE] That would do. >> >> >> > >> > 4b. "normal rules" >> > Looking at the definition, would the following rewrite help: >> > OLD >> > " Traffic sent to or received from a public telecommunication >> > network for processing according to the normal rules." >> > /OLD >> > >> > NEW >> > " Traffic sent to or received from a public telecommunication >> > network for processing according to the rules for ordinary >> > subscribers of a public telecommunication network." >> > /NEW >> [JRE] That would do. >> >> > >> > 4c. NGN is a public telecommunication network >> > > - "To summarize a few example reasons for a public >> > telecommunication network to make the distinction between the >> > two types of traffic" Isn't it an NGN that needs to make the >> > distinction? >> > > [HE] NGN is a public telecommunication network. But we can >> > rephrase to: "To summarize a few example reasons for a public >> > NGN to make the distinction between the two types of traffic" [/HE] >> [JRE] OK >> >> > >> > [JRE] I think that is the problem I am having. I believe an >> > NGN is a network infrastructure that supports both public >> > network traffic and private network traffic, or in other >> > words it supports both a public network and a number of >> > private networks.[/JRE] >> > [HE2]Yes, but its main purpose is to serve as a public >> > network with all the regulations that apply to such networks >> > etc. This does not prohibit an NGN to be used as a private >> > network of course, but still it has been designed from the >> > perspective of having to serve the needs of public network >> > operators. That is why the "normal"/default procedures are >> > for public network traffic. As we want to introduce the >> > capability for such a public network (NGN) to also support >> > private network traffic that has to be processed to a >> > different set of rules, the Private-Network-Indication is >> > needed.[/HE2] >> > >> > >> > 5. Traffic --> SIP traffic >> > Calling traffic SIP traffic suggest that the media is not >> > part of the traffic, is that what we want?? >> [JRE] The point is, it is not HTTP traffic or FTP traffic or SMTP >> traffic or whatever. >> >> > >> > >> > 6. Example private network traffic can also exist between two >> > different enterprises >> > Where would you like to see this? Obviously section 1.2 is >> > not the right place for such an example. >> > Isn't this too obvious, if you imagine that two companies >> > have agreed to form a cooperation and communicate under this >> > agreement? >> > Would you like to see this as an additional example in section 4? >> [JRE] I was not necessarily seeking a further example. However, given >> that the private network indication identifies the particular private >> network, what form does this indication take when traffic is between two >> enterprises? Is there some interworking function where the identifier >> changes from that of the first private network to that of the second >> private network? >> >> > >> > >> > 8. calling line identification >> > Yes we agree fully on that "calling line identification is >> > not an adequate distinction". I think that is what the >> > current text tries to explain. Actually what I dont like >> > about this text is that it starts explaining what the >> > indication is not about. I propose that we completely remove >> > the 1st paragraph in section 1.3 and the 1st word "Rather" >> > from the 2nd paragraph. >> [JRE] Yes. And in the second paragraph, perhaps we could enhance: >> "This >> indication is not for the end user on the private network." >> to say: >> "This indication does not identify an end user on a private network and >> is not for delivery to an end user on the private network." >> >> >> John >> >> >> > >> > /Hans Erik van Elburg >> > >> > >> > >> > >> > >
- [dispatch] Fwd: [Sipping] Fwd: Expert review ofdr… Hans Erik van Elburg
- Re: [dispatch] Fwd: [Sipping] Fwd: Expert reviewo… Elwell, John