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.
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."
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:
/OLD
[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]
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.
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
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]
> [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]
[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??
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?
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.
/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
