Re: [Gen-art] Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt
We did have a debate before WGLC on Info versus BCP with the AD and a few other experts, but I forgot to include reference to that in the PROTO writeup. If I am ever in the position of doing other PROTO writeups, and the issue comes up again, I'll try to remember to include it. regards Keith -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Tuesday, May 12, 2009 12:44 AM To: DRAGE, Keith (Keith) Cc: Shida Schubert; draft-ietf-sip-ua-priv...@tools.ietf.org; General Area Review Team; sip-cha...@tools.ietf.org; Cullen Jennings Subject: Re: Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt Thanks. I have no problem with this explanation. Maybe it will become a candidate for BCP status in a year or two. Brian On 2009-05-12 09:37, DRAGE, Keith (Keith) wrote: So to summarise, my understanding is that this document provides a way of using the protocol tools that are normatively specified elsewhere, rather than creating the protocol itself. As such informational would appear to be appropriate. regards Keith From: Shida Schubert [mailto:sh...@ntt-at.com] Sent: Thursday, May 07, 2009 1:35 PM To: Brian E Carpenter Cc: draft-ietf-sip-ua-priv...@tools.ietf.org; General Area Review Team; sip-cha...@tools.ietf.org; Cullen Jennings Subject: Re: Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt I have sent the copy of this e-mail from my personal e-mail address, so sending it again from the address listed in the draft. I apologize if people are receiving a duplicate copy. Brian; Many thanks for your review. I have pasted relevant text from your comments and replied to them inline.. [Brian] Comments: - Apart from the small point mentioned below, I didn't find any technical issues with this draft, but it left me feeling a little uncomfortable. It isn't a standard, it isn't an experiment, it isn't a description of current practice, so what is it? [Brian] We had a draft which clarified the use of RFC3323 (Currently in the AUTH48 state) along with the recommendation to use tools that were not available at the time of RFC3323. WG decided to take on the portion which described the toolset that were recently defined to obtain user's privacy as a BCP, and we progressed the portion that clarified the use of RFC3323 as a separate draft and submitted as an independent submission. As the toolset recommended in this draft aren't widely deployed and not even an RFCs, the WG agreed to change the status to informational. (We really believed the referenced specifications namely GRUU and TURN were to be an RFCs by the time this draft was to be published.) There are more and more implementations of GRUU observed at interop test events and some in deployments and TURN are seeing tractions as well, so putting this out there will ensure the use of proper toolsets to obtain privacy in SIP without relying on what is defined in RFC3323. [Brian] Minor issues: - Referring to section 5.1.2, note that in RFC5364, sip:anonym...@anonymous.invalid is a MUST rather than a SHOULD. I don't know whether that interacts with the current draft in any way. [Brian] Sniplet from the introduction of RFC5364 -- Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs. -- So the anonymization is for not the sender itself but for the recipients of the copied messages (receivers). The UA-privacy is about obtaining the privacy of the sender thus there is no interaction that we have to worry about between this draft and RFC5364. But thanks for bringing this up anyhow. As for the reference I will update the reference and resubmit the version 08 of the draft. Many Thanks Regards Shida On 5-May-09, at 11:45 AM, Brian E Carpenter wrote: draft-ietf-sip-ua-privacy-07-carpenter.txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt
So to summarise, my understanding is that this document provides a way of using the protocol tools that are normatively specified elsewhere, rather than creating the protocol itself. As such informational would appear to be appropriate. regards Keith From: Shida Schubert [mailto:sh...@ntt-at.com] Sent: Thursday, May 07, 2009 1:35 PM To: Brian E Carpenter Cc: draft-ietf-sip-ua-priv...@tools.ietf.org; General Area Review Team; sip-cha...@tools.ietf.org; Cullen Jennings Subject: Re: Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt I have sent the copy of this e-mail from my personal e-mail address, so sending it again from the address listed in the draft. I apologize if people are receiving a duplicate copy. Brian; Many thanks for your review. I have pasted relevant text from your comments and replied to them inline.. [Brian] Comments: - Apart from the small point mentioned below, I didn't find any technical issues with this draft, but it left me feeling a little uncomfortable. It isn't a standard, it isn't an experiment, it isn't a description of current practice, so what is it? [Brian] We had a draft which clarified the use of RFC3323 (Currently in the AUTH48 state) along with the recommendation to use tools that were not available at the time of RFC3323. WG decided to take on the portion which described the toolset that were recently defined to obtain user's privacy as a BCP, and we progressed the portion that clarified the use of RFC3323 as a separate draft and submitted as an independent submission. As the toolset recommended in this draft aren't widely deployed and not even an RFCs, the WG agreed to change the status to informational. (We really believed the referenced specifications namely GRUU and TURN were to be an RFCs by the time this draft was to be published.) There are more and more implementations of GRUU observed at interop test events and some in deployments and TURN are seeing tractions as well, so putting this out there will ensure the use of proper toolsets to obtain privacy in SIP without relying on what is defined in RFC3323. [Brian] Minor issues: - Referring to section 5.1.2, note that in RFC5364, sip:anonym...@anonymous.invalid is a MUST rather than a SHOULD. I don't know whether that interacts with the current draft in any way. [Brian] Sniplet from the introduction of RFC5364 -- Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs. -- So the anonymization is for not the sender itself but for the recipients of the copied messages (receivers). The UA-privacy is about obtaining the privacy of the sender thus there is no interaction that we have to worry about between this draft and RFC5364. But thanks for bringing this up anyhow. As for the reference I will update the reference and resubmit the version 08 of the draft. Many Thanks Regards Shida On 5-May-09, at 11:45 AM, Brian E Carpenter wrote: draft-ietf-sip-ua-privacy-07-carpenter.txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt
Thanks. I have no problem with this explanation. Maybe it will become a candidate for BCP status in a year or two. Brian On 2009-05-12 09:37, DRAGE, Keith (Keith) wrote: So to summarise, my understanding is that this document provides a way of using the protocol tools that are normatively specified elsewhere, rather than creating the protocol itself. As such informational would appear to be appropriate. regards Keith From: Shida Schubert [mailto:sh...@ntt-at.com] Sent: Thursday, May 07, 2009 1:35 PM To: Brian E Carpenter Cc: draft-ietf-sip-ua-priv...@tools.ietf.org; General Area Review Team; sip-cha...@tools.ietf.org; Cullen Jennings Subject: Re: Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt I have sent the copy of this e-mail from my personal e-mail address, so sending it again from the address listed in the draft. I apologize if people are receiving a duplicate copy. Brian; Many thanks for your review. I have pasted relevant text from your comments and replied to them inline.. [Brian] Comments: - Apart from the small point mentioned below, I didn't find any technical issues with this draft, but it left me feeling a little uncomfortable. It isn't a standard, it isn't an experiment, it isn't a description of current practice, so what is it? [Brian] We had a draft which clarified the use of RFC3323 (Currently in the AUTH48 state) along with the recommendation to use tools that were not available at the time of RFC3323. WG decided to take on the portion which described the toolset that were recently defined to obtain user's privacy as a BCP, and we progressed the portion that clarified the use of RFC3323 as a separate draft and submitted as an independent submission. As the toolset recommended in this draft aren't widely deployed and not even an RFCs, the WG agreed to change the status to informational. (We really believed the referenced specifications namely GRUU and TURN were to be an RFCs by the time this draft was to be published.) There are more and more implementations of GRUU observed at interop test events and some in deployments and TURN are seeing tractions as well, so putting this out there will ensure the use of proper toolsets to obtain privacy in SIP without relying on what is defined in RFC3323. [Brian] Minor issues: - Referring to section 5.1.2, note that in RFC5364, sip:anonym...@anonymous.invalid is a MUST rather than a SHOULD. I don't know whether that interacts with the current draft in any way. [Brian] Sniplet from the introduction of RFC5364 -- Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs. -- So the anonymization is for not the sender itself but for the recipients of the copied messages (receivers). The UA-privacy is about obtaining the privacy of the sender thus there is no interaction that we have to worry about between this draft and RFC5364. But thanks for bringing this up anyhow. As for the reference I will update the reference and resubmit the version 08 of the draft. Many Thanks Regards Shida On 5-May-09, at 11:45 AM, Brian E Carpenter wrote: draft-ietf-sip-ua-privacy-07-carpenter.txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt
I have sent the copy of this e-mail from my personal e-mail address, so sending it again from the address listed in the draft. I apologize if people are receiving a duplicate copy. Brian; Many thanks for your review. I have pasted relevant text from your comments and replied to them inline.. [Brian] Comments: - Apart from the small point mentioned below, I didn't find any technical issues with this draft, but it left me feeling a little uncomfortable. It isn't a standard, it isn't an experiment, it isn't a description of current practice, so what is it? [Brian] We had a draft which clarified the use of RFC3323 (Currently in the AUTH48 state) along with the recommendation to use tools that were not available at the time of RFC3323. WG decided to take on the portion which described the toolset that were recently defined to obtain user's privacy as a BCP, and we progressed the portion that clarified the use of RFC3323 as a separate draft and submitted as an independent submission. As the toolset recommended in this draft aren't widely deployed and not even an RFCs, the WG agreed to change the status to informational. (We really believed the referenced specifications namely GRUU and TURN were to be an RFCs by the time this draft was to be published.) There are more and more implementations of GRUU observed at interop test events and some in deployments and TURN are seeing tractions as well, so putting this out there will ensure the use of proper toolsets to obtain privacy in SIP without relying on what is defined in RFC3323. [Brian] Minor issues: - Referring to section 5.1.2, note that in RFC5364, sip:anonym...@anonymous.invalid is a MUST rather than a SHOULD. I don't know whether that interacts with the current draft in any way. [Brian] Sniplet from the introduction of RFC5364 -- Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs. -- So the anonymization is for not the sender itself but for the recipients of the copied messages (receivers). The UA-privacy is about obtaining the privacy of the sender thus there is no interaction that we have to worry about between this draft and RFC5364. But thanks for bringing this up anyhow. As for the reference I will update the reference and resubmit the version 08 of the draft. Many Thanks Regards Shida On 5-May-09, at 11:45 AM, Brian E Carpenter wrote: draft-ietf-sip-ua-privacy-07-carpenter.txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sip-ua-privacy-07.txt Reviewer: Brian Carpenter Review Date: 2009-05-05 IETF LC End Date: 2009-05-11 IESG Telechat date: (if known) Summary: Ready Comments: - Apart from the small point mentioned below, I didn't find any technical issues with this draft, but it left me feeling a little uncomfortable. It isn't a standard, it isn't an experiment, it isn't a description of current practice, so what is it? Minor issues: - Referring to section 5.1.2, note that in RFC5364, sip:anonym...@anonymous.invalid is a MUST rather than a SHOULD. I don't know whether that interacts with the current draft in any way. Editorial issues: - == Outdated reference: A later version (-14) exists of draft-ietf-behave-turn-13___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
