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

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

Thanks John for performing the review. Think you found some valid issues 
with the text. Will have to come back on that later.
BR,
/Hans Erik

Elwell, John 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.
>
> 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.
>
> 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).
>
> 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?
> - "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?
> - "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?
> - "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.
> - "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?
>
> 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.
>
> 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
> 7. The terms "private network" and "enterprise network" seem to be used
> more or less randomly to refer to the same thing.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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").
>
> 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.
>
> 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)?
>
> 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";
> - sentences that do not parse;
> - an extremely long and difficult sentence in 7.2.1.
>
> John
>
>