Fwd: Expert review of draft-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.

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

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]
[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??

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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP