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

[Mayumi Ohsugi <[e-mail]>]

Keith,

Thank you for the comments.
Sorry for the late reply.

#9
OK, I will keep the sentence regarding subdomains
as it is.

7.1.1
I will correct "breaking" to "break-in".

I believe that all the comments have been solved
so I will submit the revised draft soon.

Thanks,
Mayumi


(2013/08/30 3:44), DRAGE, Keith (Keith) wrote:
> 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
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Mayumi Ohsugi
>> Sent: 29 August 2013 09:35
>> To: Yu, James
>> Cc: [e-mail]; Cullen Jennings
>> Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-
>> network-ind
>>
>> Hi James,
>>
>> Thank you for the comments to the P-Private-Network-Indication draft.
>> See inline.
>>
>> (2013/08/29 6:59), Yu, James wrote:
>>> 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.
>>
>> [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
>>
>>
>>>
>>>
>>> -----Original Message-----
>>> From: Atle Monrad [mailto:[e-mail]]
>>> Sent: Thursday, August 15, 2013 5:35 AM
>>> To: [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Atle Monrad
>>> Sent: 29. juli 2013 10:40
>>> To: Mayumi Ohsugi; [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Mayumi Ohsugi
>>> Sent: 16. juli 2013 04:50
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> 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
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>