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:[email protected]] > Sent: Thursday, May 07, 2009 1:35 PM > To: Brian E Carpenter > Cc: [email protected]; General Area Review Team; > [email protected]; 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:[email protected]" > 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
