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
_______________________________________________
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
