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

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 3 Jul 2009 00:19:20 +0200

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 <
[email-masked]> 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Jul 2009 12:14:01 +0100

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]] 
> 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,
> 
> 
> On Wed, May 13, 2009 at 3:31 PM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 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]
> 
> 
> 
[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.
> [HE] It means Next Generation Network, I removed the second 
> occurence of "(NGN)". [/HE]
>    
> 
> 
> [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.

> [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".

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

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

>  [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"?

> [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.

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

> [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.

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

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 3 Jul 2009 16:16:49 +0200

Resent and history removed as otherwise rejected by mailing list.

Hi John,

1. Again the required applicability statement is in section 10 of the main
body. (Same pattern has been followed in RFC5502, 5002 and 4457) which I
took as examples. Together with the additional text in the abstract that
should be sufficient. If the text in section 10 needs to be improved then
please indicate so.

2. Took in your nits, the abstract now reads:
      "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 a domain to treat private network traffic
 according to a different set of rules then than the set
applicable to public network traffic. The indication also
 distinguishes traffic from one private network from another
private network."

4a. Regarding 1.2 item b). Would the following rewrite help?:
OLD:
" b) 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; and" /OLD

NEW:
" b) business trunking application, where the NGN hosts transit capabilities
between NGCN's, break-in capabilities  where the NGN converts public network
traffic to private network traffic for delivery at a served NGCN and
break-out capabilities where the NGN converts private network traffic from a
served NGCN to public network traffic; and"
/NEW

If not please suggest an improved sentence that covers your concern. Please
note that in the example that you gave it is not the business trunking
application that does the conversion, but the hosted enterprise application.

4b. "normal rules"
Looking at the definition, would the following rewrite help:
OLD
" Traffic sent to or received from a public telecommunication network for
processing according to the normal rules."
/OLD

NEW
" Traffic sent to or received from a public telecommunication network for
processing according to the rules for ordinary subscribers of a public
telecommunication network."
/NEW

4c. NGN is a public telecommunication 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?
> [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.[/JRE]
[HE2]Yes, but its main purpose is to serve as a public network with all the
regulations that apply to such networks etc. This does not prohibit an NGN
to be used as a private network of course, but still it has been designed
from the perspective of having to serve the needs of public network
operators. That is why the "normal"/default  procedures are  for public
network traffic. As we want to introduce the capability for such a public
network (NGN) to also support private network traffic that has to be
processed to a different set of rules, the Private-Network-Indication is
needed.[/HE2]

5. Traffic --> SIP traffic
Calling traffic SIP traffic suggest that the media is not part of the
traffic, is that what we want??

6. Example private network traffic can also exist between
two different enterprises
Where would you like to see this? Obviously section 1.2 is not the right
place for such an example.
Isn't this too obvious, if you imagine that two companies have agreed to
form a cooperation and communicate under this agreement?
Would you like to see this as an additional example in section 4?

8. calling line identification
Yes we agree fully on that "calling line identification is not an adequate
distinction". I think that is what the current text tries to explain.
Actually what I dont like about this text is that it starts explaining what
the indication is not about. I propose that we completely remove the 1st
paragraph in section 1.3 and the 1st word "Rather" from the 2nd paragraph.

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 06 Jul 2009 07:52:01 +0100

Hans Erik, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 03 July 2009 15:17
> To: Elwell, John; DRAGE, Keith (Keith)
> Cc: IETF Sipping List
> Subject: [Sipping] Fwd: Expert review 
> ofdraft-vanelburg-sipping-private-network-indication-03
> 
> 1. Again the required applicability statement is in section 
> 10 of the main body. (Same pattern has been followed in 
> RFC5502, 5002 and 4457) which I took as examples. Together 
> with the additional text in the abstract that should be 
> sufficient. If the text in section 10 needs to be improved 
> then please indicate so.
[JRE] I must have written the original comment 1 before I got down to
section 10. Basically section 10 is far too late in the document, and I
would have expected the statement, perhaps as section 1, or perhaps as a
section 1.2 before the existing 1.2.

> distinguishes traffic from one private network from another
[JRE]
Delete the word "then".

> " b) 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; and" 
> /OLD
> 
> 
> NEW:
> " b) business trunking application, where the NGN hosts 
> transit capabilities between NGCN's, break-in capabilities  
> where the NGN converts public network traffic to private 
> network traffic for delivery at a served NGCN and break-out 
> capabilities where the NGN converts private network traffic 
> from a served NGCN to public network traffic; and"
> 
> /NEW
> 
> If not please suggest an improved sentence that covers your 
> concern. Please note that in the example that you gave it is 
> not the business trunking application that does the 
> conversion, but the hosted enterprise application.
[JRE] That would do.

> " Traffic sent to or received from a public telecommunication 
> network for processing according to the normal rules."
> /OLD
> 
> NEW
> " Traffic sent to or received from a public telecommunication 
> network for processing according to the rules for ordinary 
> subscribers of a public telecommunication network."
> /NEW
[JRE] That would do.

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

> 
> [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.[/JRE]
> [HE2]Yes, but its main purpose is to serve as a public 
> network with all the regulations that apply to such networks 
> etc. This does not prohibit an NGN to be used as a private 
> network of course, but still it has been designed from the 
> perspective of having to serve the needs of public network 
> operators. That is why the "normal"/default  procedures are  
> for public network traffic. As we want to introduce the 
> capability for such a public network (NGN) to also support 
> private network traffic that has to be processed to a 
> different set of rules, the Private-Network-Indication is 
> needed.[/HE2]
> 
> 
> Calling traffic SIP traffic suggest that the media is not 
> part of the traffic, is that what we want??
[JRE] The point is, it is not HTTP traffic or FTP traffic or SMTP
traffic or whatever.

> 
> 
> 6. Example private network traffic can also exist between two 
> different enterprises
> Where would you like to see this? Obviously section 1.2 is 
> not the right place for such an example.
> Isn't this too obvious, if you imagine that two companies 
> have agreed to form a cooperation and communicate under this 
> agreement? 
[JRE] I was not necessarily seeking a further example. However, given
that the private network indication identifies the particular private
network, what form does this indication take when traffic is between two
enterprises? Is there some interworking function where the identifier
changes from that of the first private network to that of the second
private network?

> Yes we agree fully on that "calling line identification is 
> not an adequate distinction". I think that is what the 
> current text tries to explain. Actually what I dont like 
> about this text is that it starts explaining what the 
> indication is not about. I propose that we completely remove 
> the 1st paragraph in section 1.3 and the 1st word "Rather" 
> from the 2nd paragraph.
[JRE] Yes. And in the second paragraph, perhaps we could enhance:
"This
   indication is not for the end user on the private network."
to say:
"This indication does not identify an end user on a private network and
is not for delivery to an end user on the private network."

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 6 Jul 2009 11:42:52 +0200

Hi John,

1. Done, moved 10 up and inserted as 1.2. Added the following sentence to
1.1:
"3GPP and ETSI TISPAN have identified a set of requirements that can be met
by defining a new SIP P-header, according to the procedures in RFC 3427
[RFC3427]."
2. Done
4a. Done
4b. Done
4c. Done
5. I added the following terminology description:

"3.1. Traffic

In the context of this document the term traffic is understood as all
communication pertaining to and/or controlled by a SIP transaction or
dialog."

8. Done

Will upload this as cutoff day for 00 drafts is today.

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 6 Jul 2009 13:06:24 +0200

Draft has been uploaded as
http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-00

Best Regards,
/Hans Erik van Elburg