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.
On Mon, Jul 6, 2009 at 8:52 AM, Elwell, John <john.elwell@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Hans Erik,
[JRE] I must have written the original comment 1 before I got down to
> -----Original Message-----
> From: sipping-bounces@xxxxxxxx
> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hans Erik van Elburg
> Sent: 03 July 2009 15:17
> To: Elwell, John; DRAGE, Keith (Keith)
> Cc: IETF Sipping List
> Subject: 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.
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.
[JRE]
>
> 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."
Delete the word "then".
[JRE] That would do.
>
> 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] OK
>
> 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] The point is, it is not HTTP traffic or FTP traffic or SMTP
>
> [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??
traffic or whatever.
[JRE] I was not necessarily seeking a further example. However, given
>
>
> 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?
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?
[JRE] Yes. And in the second paragraph, perhaps we could enhance:
>
>
> 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.
"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
>
>
>
>
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
