Re: [dispatch] Fwd: [Sipping] Fwd: Expert reviewofdraft-vanelburg-sipping-private-network-indication-03

["Elwell, John" <[e-mail]>]

My review comments have been resolved with the exception of the
following:

- I failed to find an example showing how it would work for private
network traffic between two enterprises (as claimed in 1.3 last bullet).
Which enterprise is identified, or is there an interworking function
that changes the indicator?

- "There may be cases where treating the call as a public network
       call although both participants are from the same enterprise is
       advantageous to the enterprise."
I requested examples, but I didn't find any in the new draft.


- "The business
   trunking application providing routeing capabilities for the
   enterprise traffic, and supports the identification of calls to and
   from public network users, break-in and break out of that traffic."
This does not parse. I think "providing" should be "provides".

- I didn't have time to check the document for correction of the many
nits that I mentioned in general terms during my original review.

John
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Hans Erik van Elburg
> Sent: 06 July 2009 12:10
> To: [e-mail]
> Subject: [dispatch] Fwd: [Sipping] Fwd: Expert 
> reviewofdraft-vanelburg-sipping-private-network-indication-03
> 
> 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-ne
> twork-ind-00
> 
> 
> or plain text:
> http://tools.ietf.org/id/draft-vanelburg-dispatch-private-netw
> ork-ind-00.txt
> 
> 
> Best Regards,
> /Hans Erik van Elburg
> 
> 
> 
> ---------- Forwarded message ----------
> From: Hans Erik van Elburg <[e-mail]>
> 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" <[e-mail]>
> Cc: "DRAGE, Keith (Keith)" <[e-mail]>, IETF 
> Sipping List <[e-mail]>
> 
> 
> 
> Draft has been uploaded as 
> http://tools.ietf.org/html/draft-vanelburg-dispatch-private-ne
> twork-ind-00
> 
> Best Regards,
> /Hans Erik van Elburg 
> 
> 
> On Mon, Jul 6, 2009 at 11:42 AM, Hans Erik van Elburg 
> <[e-mail]> 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 
> <[e-mail]> wrote:
> 	
> 
> 		Hans Erik,
> 		
> 
> 		> -----Original Message-----
> 		> From: [e-mail]
> 		> [mailto:[e-mail]] 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
> 		>
> 		>
> 		>
> 		>
> 		
> 
> 
> 
> 
>