> -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@xxxxxxxxx] > Sent: 02 July 2009 23:19 > To: Elwell, John > Cc: IETF Sipping List; DRAGE, Keith (Keith) > Subject: Re: Expert review of > draft-vanelburg-sipping-private-network-indication-03 > > 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 > <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. [JRE] Section 1.1 is not an applicability statement - it is merely a statement about what ETSI TISPAN does. Section 1.2 is also about what ETSI TISPAN has done and the requirements TISPAN has generated. This too does not constitute an applicability statement. I expected to see something similar to the Applicability Statement (section 1) in RFC 3325. I would expect to see text along the lines of "This document specifies private extensions to sIP...." and "The use of these extensions is only applicable ...." > > > I think you like to see something in the abstract, right? [JRE] No - in the main body, preferably as section 1 (taking RFC 3325 as a precedent). > > > 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] [JRE] Something along the lines of the above for the abstract would do (but fix the nits, e.g., change "such domain" to "such a domain", change "to a different set" to "according to a differenet set", change "then public network traffic", to "than the set applicable to public network traffic". But as I said above, this does not constitute an Applicability Statement. > > > > 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] [JRE] Whether or not it is circular, I still believe the break-in capabilities are from public network to private network. For example, if a call from the public network goes to a hosted enterprise user, it breaks into the private network. There is no NGCN involved. It is no good blindly copying TISPAN definitions if they are not meaningful to an IETF audience. > > > > - "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." [JRE] Maybe my fix is not the right fix, but I still think it is unclear what is meant by "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." [JRE] Let us see whether other people are comfortable with this. > > [/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] [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. > > > - "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. [JRE] So why don't we just say "SIP traffic"? > > > 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] [JRE] I assume you will add text to explain this. > > > 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] [JRE] This strengthens my point - calling line identification is not an adequate distinction because of 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. > > > > [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] [JRE] I agree it is important to say what you MUST do, but shouldn't you also say what you MUST NOT do? I will go with the majority opinion on this. > > 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] [JRE] But if there is a downstream proxy that does support this extension but an intermediate proxy (e.g., the next proxy) that does not, surely we have to take care? John > > 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
