AW: AW: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt

["Jesske, R" <[e-mail]>]

It is good to know that this was never intended, but the RFC3323 and RFC3325 does not specify this. So there is a GAP, that must be closed. But meanwhile there are implementations in the world that interprets 'id' as an subset of 'header'. So the clarification needed in RFC3325 need to take this into consideration.

Nevertheless I would like to go with Keiths proposal for the ACR response-code:
2)	Section 3. 

   o  The request contained a Privacy header field whose value was 'id'
      [3] or 'user'.  This explicitly excludes the 'header' and
      'session' privacy services, since those do not directly convey the
      identity of the requestor.

I have noted the ongoing discussion on this, and certainly my
interpretation was that the "header" value in the Privacy header could
cover the P-Asserted-Identity header. However I think we should avoid
that this draft attempts to fix unclear specification in RFC 3323 and
(and possibly RFC 3325). I would therefore suggest that we strike the
offending words.

Best Regards

Roland 

> -----Ursprüngliche Nachricht-----
> Von: Peterson, Jon [mailto:[e-mail]] 
> Gesendet: Donnerstag, 21. September 2006 20:22
> An: Jonathan Rosenberg; Paul Kyzivat
> Cc: Jesske, Roland; [e-mail]; [e-mail]; 
> [e-mail]; Dean Willis
> Betreff: RE: AW: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt
> 
> 
> 
> The 'header' privacy value was never intended to encompass 
> the functionality of 'id'. 'id' assumes the existence of 
> trust domains, and thus of entities among whom private 
> information could be legitimately shared. RFC3323 more or 
> less assumes that the anonymizing function is performed by 
> intermediary close to the UAC, and that makes the behavior of 
> the 'header' privacy value difficult to apply to P- headers 
> which can be shared among a set of trust hosts but not 
> outside the trust domain. 
> 
> Clearly, various intermediaries within a trust domain could 
> perform both the 'header' and 'id' functions, but if that's 
> desired, both the 'header' and 'id' priv-values should be 
> specified in the Privacy header by the user agent.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[e-mail]]
> > Sent: Friday, September 15, 2006 10:41 AM
> > To: Paul Kyzivat
> > Cc: Jesske, R; [e-mail]; [e-mail]; Dean Willis;
> > [e-mail]
> > Subject: Re: AW: [Sip] SIP WGLC Draft draft-ietf-sip-acr-code-02.txt
> > 
> > 
> > Right.
> > 
> > So what this means for acr-code is that we are really at a 
> stalemate 
> > here until its clear what RFC 3323 is supposed to mean. Its 
> important to 
> > note that it is certainly not the job of acr-code to clarify 
> > this behavior.
> > 
> > -Jonathan R.
> > 
> > Paul Kyzivat wrote:
> > 
> > > 
> > > 
> > > Jonathan Rosenberg wrote:
> > > 
> > >> This is a good point.
> > >>
> > >> I did not think that the 'header' value applied to P-Asserted-ID.
> > >> Rather, the 'id' value does, which is defined 
> specifically for this
> > >> purpose in RFC 3325. However I agree with you that *if* 
> > 'header' implied
> > >> removal of P-Asserted-ID, it becomes a superset of 'id' 
> and then it
> > >> should be added to the list of things that define an 
> > anonymous call.
> > > 
> > > 
> > > I agree that the intent is not entirely clear. But like 
> > Jonathan I had 
> > > interpreted the specs so that 'header' privacy did not remove 
> > > P-Asserted-Identity. I just reviewed 3323 and 3325, and I 
> > think that is 
> > > still the correct interpretation based on more or less the 
> > same logic 
> > > Jonathan mentioned earlier:
> > > 
> > > - it is suggested that 'header' privacy be applied early 
> on the call
> > >   path. (Section 4.3: "It is RECOMMENDED that service 
> > providers couple
> > >   the privacy service function with a local outbound proxy.")
> > > 
> > > - 'id' privacy must be applied late in the call path or else the
> > >   P-Asserted-ID header isn't available to servers that need it.
> > > 
> > > - when the 'header' function is carried out, the 'header' token
> > >   is to be removed. That is specified in section 5:
> > > 
> > >   "When a privacy service performs one of the functions 
> > corresponding to
> > >    a privacy level listed in the Privacy header, it SHOULD 
> > remove the
> > >    corresponding priv-value from the Privacy header - 
> otherwise, any
> > >    other privacy service involved with routing this message might
> > >    unnecessarily apply the same function, which in many 
> > cases would be
> > >    undesirable."
> > > 
> > > I guess the following strategy *could* be used to make 
> the 'header' 
> > > privacy level to be a superset of 'id' privacy:
> > > 
> > > - The outbound proxy it would hide most headers ,
> > >   but would note that it isn't forwarding across a trust domain
> > >   boundary and so not remove P-Asserted-ID.
> > > 
> > > - It would remove the 'header' token from the Privacy header,
> > >   but because it hasn't completed the job by removing 
> P-Asserted-ID,
> > >   it must insert an 'id' token to ensure that is done later.
> > > 
> > > While that is a possibility, it seems like quite a stretch 
> > to me. I see 
> > > no hints in either document that this kind of behavior is 
> > expected. It 
> > > seems way more straightforward to treat them as 
> independent options.
> > > 
> > >     Paul
> > > 
> > >> Perhaps Jon P. can comment on whether the intent was for 'header'
> > >> privacy to apply to P-Asserted-ID?
> > >>
> > >> -Jonathan R.
> > >>
> > >> Shida Schubert wrote:
> > >>
> > >>> I personally think RFC3323 is underspecified with what 
> headers to
> > >>> be obscured per privacy value. Interestingly though I 
> > found the text in
> > >>> IANA consideration that is concise about what each 
> privacy value's
> > >>> intent.
> > >>>
> > >>> "Text from the IANA consideration of RFC3323
> > >>>
> > >>>    o  user: Request that privacy services provide a 
> > user-level privacy
> > >>>       function
> > >>>
> > >>>    o  header: Request that privacy services modify 
> > headers that cannot
> > >>>       be set arbitrarily by the user (Contact/Via)."
> > >>>
> > >>> Considering the text above, if "header" was set any 
> > headers that can not
> > >>> be set
> > >>> arbitrarily by the user needs to be obscured/modified by 
> > the privacy
> > >>> services, which
> > >>> I believe would include P-A-ID as well.
> > >>>
> > >>> If that's the case, requesting "header" would naturally 
> > mean requesting
> > >>> anonymity, as the
> > >>> domain supporting P-A-ID would alter the value of the 
> P-A-ID to be
> > >>> anonymous as the
> > >>> text in IANA suggests.
> > >>>
> > >>> My original interpretation of "header" privacy value was 
> > actually quite
> > >>> different. I saw
> > >>> the "header privacy" as a way for UA to request some sort 
> > of topology
> > >>> hiding
> > >>> (obscuring Contact, via, headers revealing a path to 
> the UA etc.).
> > >>> With that interpretation, I could see a scenario where 
> > "header" privacy
> > >>> option does NOT
> > >>> imply that the originating user desires anonymity(e.g. I 
> > call my client,
> > >>> I want to show them
> > >>> who I am but not wanting them to find out I am calling 
> > from home.). But
> > >>> this can not hold true if the domain provides P-A-ID as 
> > "header' privacy
> > >>> value will
> > >>> modify the header to obscure the identity of the user, 
> > thus making it an
> > >>> anonymous call.
> > >>>
> > >>> Regards
> > >>> Shida
> > >>>
> > >>> Dean Willis wrote:
> > >>>
> > >>>> Jesske, R wrote:
> > >>>>
> > >>>>> At least with the 'header' privacy the origin user 
> > expresses that he
> > >>>>> want to be anonymous. So it is an intension of the 
> > user. Of course
> > >>>>> the privacy server can strip of the privacy value but 
> > that is due to
> > >>>>> the Provider of the server. Within RFC3323 I didn't 
> > found something
> > >>>>> that says that if you have privacy performed that you 
> > have to delete
> > >>>>> the privacy header itself.
> > >>>>
> > >>>> Does it? Do we have real scenarios where the "header" 
> > privacy option
> > >>>> does NOT imply that the originating user desires anonymity?
> > >>>>
> > >>>> Or is the case where a call goes out with a "header" 
> > privacy value,
> > >>>> but includes an authenticated identity body or other non-header
> > >>>> identity mechanism simply an error?
> > >>>>
> > >>>> If it is an error, what needs to be corrected, in terms of
> > >>>>
> > >>>> 1) Changing any specifications?
> > >>>>
> > >>>> 2) Run-time detection of and response to the error condition?
> > >>>>
> > >>>> -- 
> > >>>> dean
> > >>>>
> > >>>> _______________________________________________
> > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > >>>> This list is for NEW development of the core SIP Protocol
> > >>>> Use [e-mail] for questions on 
> current sip
> > >>>> Use [e-mail] for new developments on the 
> > application of sip
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >>> This list is for NEW development of the core SIP Protocol
> > >>> Use [e-mail] for questions on 
> current sip
> > >>> Use [e-mail] for new developments on the 
> > application of sip
> > >>>
> > >>
> > > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ 
> > 07054-2711
> > Cisco Systems
> > [e-mail]                              FAX:   [phone]
> > http://www.jdrosen.net                         PHONE: [phone]
> > http://www.cisco.com
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments on the application of sip
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip