Hi John,
Finally found some time to address this.
See my answers inline.
Thanks a lot for reviewing!
/Hans Erik van ElburgOn Wed, May 13, 2009 at 3:31 PM, Elwell, John <john.elwell@xxxxxxxxxxxxxxxxxxxxxx> 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."
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
_______________________________________________ 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
