Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind

From: "Yu, James" <[email-masked]>
Date: Wed, 28 Aug 2013 21:59:32 +0000

Mayumi,

I have a few comments below.

Best Regards,

James

-------------------

#1. Page 4, Section 1.1, 2nd sentence:  Remove the parentheses and either leave the sentence at the same place or move it to a footnote.

#2. Page 5, Section 1.5, 1st paragraph: Change the sentence containing "network element (supporting this specification) traversed" to "A private network indication as proposed by this document that is received in an incoming request indicates to the receiving network element (supporting this specification) that this request is related to a private network traffic as opposed to a public network traffic.".  Change "on behalf to" to "on behalf of" in the 2nd to the last line.

#3. Page 6, Section 1.5, the last set of items 1 and 2: Change "As caller" to "Caller" in item 1.  Change "network" to "networks" in the 1st line and "is" to "are" in the 3rd line of item 2.

#4. Page 8, 1st paragraph and Figure 1 (and other places?):  It may be better to use "pre-arranged domain name" instead of "common domain".  Suggest to change the 1st paragraph to "There may be circumstances where traffic between two different enterprises are tagged as private network traffic using a pre-arranged domain name agreed by the two involved enterprises."

#5. Page 8, last paragraph, 6th line: Change "break out" to "break-out".

#6. Page 10, Figure 3:  Between the enterprise phone and the hosted enterprise service for enterprise 1, should it be "public network traffic" because there is no need to include the P-Private-Network-Indication header field in the request in either direction.

#7. Page 10, Section 5, R1: Change "that indicates" to "to indicate".

#8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd line.  Also the 2nd line says "associated with the originating enterprise".  For a common domain, the PNI would be associated with both the originating and terminating enterprises.

#9. Page 12, 1st paragraph:  "subdomains" is mentioned when an enterprise needs more than one identifier.  But the I-D should not rule out that an enterprise can use multiple domain names so long as it owns them.

#10. Page 12, Section 7.1.1: If a common domain name is used, the PNI would correspond to two enterprises in the last sentence.  In case an enterprise has more than one identifiers, the proxy would need to know which identifier is to be used when it needs to convert public network traffic to private network .  I don't know if the proxy has the knowledge to know the appropriate identifier to use based on the incoming request.  If not, there should be a default identifier and the procedure needs to be discussed.

#11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line and insert "a" before "case" in the 2nd to the last line.  The 1st server in the public telecom network that receives the P-Private-Network-Indication header field in an incoming request should check if the originating enterprise can include the indicated domain name in the header field (also see comment #15

#12. Page 12, Section 7.1.3: Change "breakout" to "break-out" in the 2nd line to be consistent.  Is there a need to include "with a value" in the last line?  The text would imply that this header field is not removed if it does not contain a value.  This header field should always be removed.

#13. Page 13, 1st paragraph, last sentence: "for a specific enterprise" probably does not apply to the case with a common domain name used by two enterprises.

#14. Page 13, 2nd paragraph, 2nd line: Change "the following" to "described below".

#15. Page 13, Section 9:  Change "physically" to "physical" in the 5th line.  When an enterprise includes the P-Private-Network-Indication header field in a request, should the public telecom network check if the originating enterprise can use that domain name?  If an enterprise wrongly uses another enterprise's domain name without any verification, the only impact is that rules for another enterprise is applied to the traffic related to this request.  But for the purpose of security, the public telecom network would be provisioned with the domain names that can be used in the this header field for each served enterprise.

#16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd line.  Change "understand the" to "understand this".

-----Original Message-----
From: Atle Monrad [mailto:[email-masked]] 
Sent: Thursday, August 15, 2013 5:35 AM
To: [email-masked]
Subject: FW: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind

Again

Kindly review and/or advocate support for this draft on the dispatch-list.

It seems to be close to completion!!

thanks
/a
________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: 29. juli 2013 10:40
To: Mayumi Ohsugi; [email-masked]
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind

All

Thanks to Mayumi to pick up the remaining topics on this draft.

I have reviewed the new version.

I have no comments and can confirm that 3GPP would like to get the draft completed to finish one of our long time outstanding dependencies.

cheers
/atle
________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mayumi Ohsugi
Sent: 16. juli 2013 04:50
To: [email-masked]
Subject: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind

Hi,

I have submitted the following draft:

http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-02.txt

The draft was discussed in DISPATCH list three years ago. 
While it has been expired for more than two years, the draft has been referred in 3GPP IMS specifications and the P-Private-Network-Indication header field is now implemented by some vendors for enterprise customers.

We have updated the draft to solve the remaining issues from Expert Review (by John Elwell) of three years ago.

Any comments are welcome.

Thanks,
Mayumi

-----
Mayumi Ohsugi, NTT
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3211/6577 - Release Date: 08/14/13

---

From: Mayumi Ohsugi <[email-masked]>
Date: Thu, 29 Aug 2013 17:35:23 +0900

Hi James,

Thank you for the comments to the P-Private-Network-Indication draft.
See inline.

(2013/08/29 6:59), Yu, James wrote:
> #1. Page 4, Section 1.1, 2nd sentence:  Remove the parentheses
> and either leave the sentence at the same place or move it to a footnote.

[MO] I will remove the parentheses.

>
> #2. Page 5, Section 1.5, 1st paragraph: Change the sentence
> containing "network element (supporting this specification)
> traversed" to "A private network indication as proposed by
> this document that is received in an incoming request indicates
> to the receiving network element (supporting this specification)
> that this request is related to a private network traffic as
> opposed to a public network traffic.".

[MO] I prefer a little shorter sentence. I will correct it to
"A private network indication as proposed by this document
  indicates to the receiving network element (supporting this
  specification) that this request is related to a private
  network traffic as opposed to a public network traffic."

> Change "on behalf to" to"on behalf of" in the 2nd to the last line.

[MO] Yes, I will.

>
> #3. Page 6, Section 1.5, the last set of items 1 and 2:
> Change "As caller" to "Caller" in item 1.
> Change "network" to "networks" in the 1st line and "is" to "are"
> in the 3rd line of item 2.

[MO] I will make these editorial corrections.

>
> #4. Page 8, 1st paragraph and Figure 1 (and other places?):
>  It may be better to use "pre-arranged domain name" instead of
> "common domain".  Suggest to change the 1st paragraph to
> "There may be circumstances where traffic between two different
> enterprises are tagged as private network traffic using a
> pre-arranged domain name agreed by the two involved enterprises."

[MO] I agree your suggestion is much better.
I will change the sentence as you proposed.

> #5. Page 8, last paragraph, 6th line: Change "break out" to "break-out".

[MO] I will correct it.

>
> #6. Page 10, Figure 3:  Between the enterprise phone and the
> hosted enterprise service for enterprise 1, should it be
> "public network traffic" because there is no need to include
> the P-Private-Network-Indication header field in the request
> in either direction.

[MO] The traffic can be either public or private.
This figure shows the example where the traffic is tagged as private.
I will correct the explanation of Figure 3 as follows;
"Traffic from the enterprise phones would not normally be
  tagged, but it can be tagged as private network traffic."

> #7. Page 10, Section 5, R1: Change "that indicates" to "to indicate".

[MO] I will.

>
> #8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd line.
> Also the 2nd line says "associated with the originating enterprise".
> For a common domain, the PNI would be associated with both the
> originating and terminating enterprises.

[MO] I will insert "a" before "globally" and
correct "associated with the originating enterprise" to
"associated with the originating and/or terminating enterprise(s)".

>
> #9. Page 12, 1st paragraph:  "subdomains" is mentioned when anenterprise
> needs more than one identifier.  But the I-D should notrule out that
> an enterprise can use multiple domain names so long as it owns them.

[MO] I will delete the sentence regarding subdomain
in order not to mention about subdomain in this draft.

>
> #10. Page 12, Section 7.1.1: If a common domain name is used,
> the PNI would correspond to two enterprises in the last sentence.
> In case an enterprise has more than one identifiers, the proxy would
> need to know which identifier is to be used when it needs to convert
> public network traffic to private network .  I don't know if the proxy
> has the knowledge to know the appropriate identifier to use based on
> the incoming request.  If not, there should be a default identifier
> and the procedure needs to be discussed.

[MO] I will correct "enterprise" to "enterprise(s)".
Regarding the multiple identifiers, which identity should be used will be
implementation matter, so I would like to avoid mention it in this draft.

>
> #11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line
> and insert "a" before "case" in the 2nd to the last line.
> The 1st server in the public telecom network that receives the
> P-Private-Network-Indication header field in an incoming request
> should check if the originating enterprise can include the
> indicateddomain name in the header field (also see comment #15

[MO] I will make these editorial corrections.

>
> #12. Page 12, Section 7.1.3: Change "breakout" to "break-out"
> in the 2nd line to be consistent.  Is there a need to include
> "with a value" in the last line?  The text would imply that this
> header field is not removed if it does not contain a value.
> This header field should always be removed.

[MO] I will correct "breakout" to "break-out".
I agree and will delete "with a value".

>
> #13. Page 13, 1st paragraph, last sentence: "for a specific enterprise"
> probably does not apply to the case with a common domain name used by
> two enterprises.

[MO] I will correct "for a specific enterprise" to
"for a specific enterprise(s)".

> #14. Page 13, 2nd paragraph, 2nd line: Change "the following" to "described below".

[MO] I will correct it as you proposed.

>
> #15. Page 13, Section 9:  Change "physically" to "physical" in the 5th line.
> When an enterprise includes the P-Private-Network-Indication header field
> in a request, should the public telecom network check if the originating
> enterprise can use that domain name?  If an enterprise wrongly uses another
> enterprise's domain name without any verification, the only impact is that
> rules for another enterprise is applied to the traffic related to this request.
> But for the purpose of security, the public telecom network would be
> provisioned with the domain names that can be used in the this header field
> for each served enterprise.

[MO] I will correct "physically" to "physical".
Regarding the verification of domain name by the public telecom network,
I will put a new subsection as follows;

   7.1.4. P-Private-Network-Indication verification
   When proxies supporting this specification receive a P-Private-Network-Indication
   header field in a SIP request from a trusted node, proxies MUST check whether
   the received domain name in the request is the same as the domain name associated
   with the provisioned domain name. If the received domain name does not match,
   proxies MUST remove the P-Private-Network-Indication header field.

>
> #16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd line.
> Change "understand the" to "understand this".

[MO] I will delete "such as the own proxy" and
correct "understands the" to "understands this".

Many Thanks,
Mayumi

---

From: "Yu, James" <[email-masked]>
Date: Thu, 29 Aug 2013 12:12:09 +0000

Mayumi,

I'm fine with your answers.

BR,

James

----- Original Message -----
From: Mayumi Ohsugi [mailto:[email-masked]]
Sent: Thursday, August 29, 2013 04:35 AM
To: Yu, James
Cc: Atle Monrad <[email-masked]>; [email-masked] <[email-masked]>; Mary Barnes <[email-masked]>; Cullen Jennings <[email-masked]>
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind

Hi James,

[MO] Yes, I will.

[MO] I will correct it.

[MO] I will.

Many Thanks,
Mayumi

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Aug 2013 18:44:26 +0000

The proposed changes are OK except:

#9:	I would prefer we mentioned multiple domain names and subdomains, rather than deleting subdomains.

#10:	I agree we should not specify this. Break-in in 3GPP would be an application server type function, and it is up to the enterprise how it wants to instruct the public network to handle such break-in. It could be a single default value. It could be based on the Request-URI in the request. It could be based on all sorts of things.

Additionally in reviewing this I spotted in subclause 7.1.1 a "breaking" that should be "break-in".

Regards

Keith

> Sent: 29 August 2013 09:35
> To: Yu, James
> Cc: [email-masked]; Cullen Jennings
> > I have no comments and can confirm that 3GPP would like to get the draft
> completed to finish one of our long time outstanding dependencies.
> >
> > cheers
> > /atle
> > While it has been expired for more than two years, the draft has been
> referred in 3GPP IMS specifications and the P-Private-Network-Indication
> header field is now implemented by some vendors for enterprise customers.
> >
> > We have updated the draft to solve the remaining issues from Expert
> Review (by John Elwell) of three years ago.
> >