Re: [Sipping] Expert review of draft-vanelburg-sipping-private-network-indication-03

[Hans Erik van Elburg <[e-mail]>]

Hi John,

Finally found some time to address this.

See my answers inline.

Thanks a lot for reviewing!
/Hans Erik van Elburg


On Wed, May 13, 2009 at 3:31 PM, Elwell, John <
[e-mail]> wrote:

> I have been asked to carry out an Expert Review on this document.
>
> The documents specifies a new P-header field for SIP and gives
> background justification and requirements for this. The new P-header
> field is for use in Next Generation Networks (NGN), as specified by ETSI
> TISPAN.
>
> In my opinion the document addresses a real need and proposes a
> reasonable solution. The proposal seems to meet the (old) requirements
> for P-headers as documented in RFC 3427, with one exception (see point 1
> below).
>
> However, more work is needed to address the following points.
>
> 1. The final requirement that P-headers must meet from RFC 3427 is:
> "7.  An applicability statement in the Informational RFC MUST clearly
>       document the useful scope of the proposal, and explain its
>       limitations and why it is not suitable for the general use of SIP
>       in the Internet."
> There is no explicit statement, although limitations are apparent from
> some places (e.g., in Security Considerations). It would be preferable
> to have a clear statement up front, as for example in RFC 3325.
>

[HE]
Section 10 addresses this. Further the context is very well described in 1.1
and 1.2.

I think you like to see something in the abstract, right?

OLD Abstract:
This document describes why a private network indication is needed. A
private network indication allows other nodes in a network to treat private
network traffic to a different set of rules then public network traffic. The
indication also distinguishes one private network from another private
network.

NEW Abstract:
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 domain to treat private network traffic to a
different set of rules then public network traffic. The indication also
distinguishes one private network from another private network. [/HE]


> 2. The Abstract suggests that the document only discusses the need for a
> private network indication, but the document also specifies a solution,
> including the definition of a new P-header field for SIP.
>

[HE] See proposed text under 1. above. [/HE]


>
> 3. It is unclear whether NGN means Next Generation Network (as implied
> by first sentence of 1.1) or public Next Generation Network (as implied
> by first sentence of 1.2).
>

[HE] It means Next Generation Network, I removed the second occurence of
"(NGN)". [/HE]


>
> 4. The concepts of private network, public network and NGN and their
> interrelationships are not clearly described. I believe the concept is
> that a single NGN infrastructure hosts both private network
> communications and public network communications, together with break-in
> and break-out functions for interworking between the two types. Examples
> that seem to contradict this include:
> - "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"
> This seems circular, i.e., the NGN hosts .... break-in capabilities from
> NGN to NGCN. Shouldn't it be break-in capabilities from public network
> to private network?


[HE] This is not a circular definition. The current definition is an exact
copy of the TISPAN definition.  [/HE]


>
> - "public network traffic: traffic sent to the NGN for processing
>      according to normal rules of the NGN."
> If the NGN hosts both public and private communications, what is
> "normal"? Does it mean according to the rules for a public network?


[HE] Yes, but that would be a circular definition. An NGN is a public
network The current definition is an exact copy of the TISPAN definition, it
says " Traffic sent to or received from a public telecommunication network
for processing according to the normal rules."

I added "public" before NGN to emphasize that it is a public network:
"The traffic generated or received by a public NGN on behalf of a private
network can be either:
o public network traffic: traffic sent to the NGN for processing according
to normal rules of the NGN. This type of traffic is known as public network
traffic;
o private network traffic: traffic sent to the NGN for processing according
to an agreed set of rules specific to an enterprise. This type of traffic is
known as private network traffic. Private network traffic is normally within
a single enterprise, but private network traffic can also exist between two
different enterprises if not precluded for regulatory reasons."
[/HE]


>
> - "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]


> - "Traditionally, this has
>   only been applied where the call does not enter the public network at
>   all, but we regard that limitation as a technical limitation rather
>   than as one precluded by the desires of the service (i.e.
>   traditionally there has been no special indication of this from the
>   public network)."
> My understanding is that the intention is to use the private network
> indicator where the call passes through an NGN but logically remains
> part of the private network, i.e., NOT where it passes through the
> (logical) public network.


[HE] Yes, the "this" is somewhat ambiguous. I changed to:
OLD:
A private network indication as proposed by this document should not
be confused with an indication to the local user that the remote user
is in the same private network. This has traditionally resulted in
PBXs providing distinctive ringing on incoming calls, but has also
been used as input to services provided to the end user,
e.g. different forwarding conditions and so on.

NEW:
A private network indication as proposed by this document should not
be confused with an indication to the local user that the remote user
is in the same private network. The latter has traditionally been used by
PBXs providing distinctive ringing on incoming calls, but has also
been used as input to services provided to the end user,
e.g. different forwarding conditions and so on.
 [/HE]


>
> - "Traffic
>   in the public network relating to the interconnection of the two
>   sites of enterprise 2 are tagged as private network traffic relating
>   to enterprise 2."
> Such traffic is in the NGN but not in the public network, surely?
>

[HE] It is in the public network as the NGN is a public network.  [/HE]


>
> 5. The definitions and descriptions of the two types of traffic (private
> network traffic and public network traffic) do not make it clear to what
> they refer. Presumably it is not IP traffic, but SIP traffic.
>

 [HE] Well its not car traffic either. But seriously is this really an
issue? The current definitions are exact copies of the TISPAN definitions,
which is a good thing. ANd the context of a draft defining a SIP header
should rule all other kinds of traffic out.

If you provide a definition of traffic, I am happy to add it.
[/HE]



> 6. "but
>      private network traffic can also exist between two different
>      enterprises if not precluded for regulatory reasons."
> It is not clear how the proposed solution supports this.
> 0

[HE]  Two private network can have a dedicated named private network traffic
arrangement that they can use for traffic between them. [/HE]



>
> 7. The terms "private network" and "enterprise network" seem to be used
> more or less randomly to refer to the same thing.


[HE] I changed to use of "private network" consistently." [/HE]



>
>
> 8. In 1.3, another reason calling line identification is an unreliable
> distinction between private network traffic and public network traffic
> is that a call from a user in the same private network can sometimes
> pass through a public network (e.g., under overflow conditions). It
> might be worth mentioning this.
>

[HE]
Not sure there are two variants of this:
1. The overflow traffic is treated as public network traffic.
2. The overflow traffic is treated as private network traffic.

It might even be that you would want both to be recognised as coming from
your own network, as how you'd like to treat them in the public network does
not say anything about how you'd like to render them to the user. These are
entirely orthogonal things.
 [/HE]


>
> 9. "The indication is not regarded as appropriate as an indication from
>   the end UA attached to an NGCN or hosted enterprise service equipment
>   in the NGN."
> I find this back-to-front. The document should state where the
> indication IS used (e.g., proxy-to-proxy) before stating where it is not
> used.
>

[HE]
I suggest we remove the paragraph as it does not add any value here.
 [/HE]



>
> 10. "3.  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."
> It might be worth giving some examples.


[HE] I woul be good if Keith can suggest something here. [/HE]


>
>
> 11. "Figure 2 shows the interconnection of sites belonging to an
>   enterprise networks using the public network, and supported in the
>   public network by a server providing a business trunking application.
>   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."
> The "routeing capabilities for the enterprise traffic" must also be
> present in the scenario shown in figure 1, where there is no "business
> trunking application". So the distinguishing feature seems to be
> break-in / break-out. Perhaps this could be made clearer, e.g., by
> showing just break-in / break-out functions in the inner box, rather
> than "business trunking application".


>
> 12. Similarly in figure 3 and its description, the essential inner
> component seems to be break-in and break-out functions, and traffic that
> does not break-in or break-out goes directly between hosted UAs and/or
> other enterprise sites.


>
> 13. There are several uses of the word "phone" or "phones", which seems
> to imply that this extension is applicable only to telephone
> communications, which presumably is not the case.


[HE] 11, 12, 13 It is mentioned in the text. [/HE]


>
> 14. In section 7, there appear to be no procedures for public network
> traffic (e.g., I could imagine the need for statements such as "a proxy
> MUST NOT insert this header field for public network traffic", and "in
> the absence of this header field in a received request, a proxy MUST
> treat the request as public network traffic").


[HE] I think it is more important to say what you MUST do. So why do you
want this reversed form in?

It should be clear from the semantics description in 8 "The presence of the
P-Private-Network-Indication header field signifies to proxies that
understand this header field that the request is to be treated as private
network traffic."
[/HE]


>
>
> 15. "Traffic protection between network elements
>   is sometimes achieved by using IPsec and sometimes by physically
>   protecting the network."
> The usual way of protecting SIP traffic is using TLS. Although this
> might be less usual within and between NGNs, I believe TLS is allowed.


[HE] Yes TLS is of course allowed, IPsec is only an example. [/HE]


>
>
> 16. "When forwarding the request to a trusted node,
>   proxies MUST NOT insert the header unless they have sufficient
>   knowledge that the route set includes another proxy in the trust
>   domain that understands the header, such as the own proxy."
> This seems to be too flexible. Even if there is a proxy in the route set
> from within the same trust domain, there could be intermediate proxies
> not in that trust domain. Should the requirement not be that the NEXT
> proxy (or UA) must be within the same trust domain (and also must be
> authenticated)?


[HE] I think this text is fine, as if you know that there is a proxy
downstream that supports this extension. And you trust that it will comply,
then that proxy has to follow the same procedure and will ensure that the
header field will not be forwarded outside the trustdomain. Actually this
text has been used in other RFC and has passed security review.   [/HE]


>
>
> 17. There are numerous nits, which I will not go into at this stage,
> since some rework is required anyway. Examples nits include:
> - use of passive voice in normative statements;
> - singular instead of plural form of verbs or nouns or vice versa;
> - missing commas,
> - spelling mistakes;
> - use of "header" rather than "header field";

[HE]  Done. [/HE]
>
> - sentences that do not parse;
> - an extremely long and difficult sentence in 7.2.1.

[HE] It is hard to break this one up, the sentence is correct though. [/HE]




>
>
> John
>
>