Re: [sipcore] privacy handling

[Mary Barnes <[e-mail]>]

If the UAC adds an hi-entry and wants privacy, then yes it would need
to use a privacy service.  However, if the privacy header is set for
that request, any HI entries added as the request is forward to the
destination would also be anonymized by a privacy service independent
of whether an element downstream might want to apply privacy to
specific HI entires.  But, none of this is any different than using
the privacy service for any other requests.  The response issue is no
different yet again than other headers that are subject to
privacy/anonymized.  I'm not sure what you mean by anonymizing of
responses unless you're talking about whether or not the privacy
service has been stateful enough to restore the values.

Thanks,
Mary.

On Tue, Aug 31, 2010 at 4:24 PM, Paul Kyzivat <[e-mail]> wrote:
> Mary,
>
> The implication of what you say is that if the UAC wants privacy for the
> H-I, then it must do something to ensure that the request goes through a
> privacy service, AND, that only those entries added prior to reaching the
> privacy service will be anonymized. If some element downstream from the UAC
> wants privacy for the information it adds, then it must ensure that the
> request will subsequently transit a privacy service. Anonymizing of
> responses is even more problematic.
>
> Are those realistic assumptions for practical use of H-I? (I don't know.)
>
>        Thanks,
>        Paul
>
> Mary Barnes wrote:
>>
>> Paul,
>>
>> The intent of 4244/4244bis was to follow the same model as RFC 3323
>> and use the concept of network-provided privacy.  So, this should not
>> be anything different than the case where Header privacy is requested.
>> There is no assumption that the proxy is a privacy service.  The
>> current text was written as if that was obvious (i.e., assumes you are
>> using a privacy service, etc. per RFC 3323 without saying such), but
>> clearly it's not.  I think the best approach is to rewrite the privacy
>> section entirely using context and terminology consistent with RFC
>> 3323   I think that can also help with the domain issue since the
>> context of domain is exactly that used in RFC 3323 (with regards to
>> privacy).
>>
>> Mary.
>>
>>
>> On Tue, Aug 31, 2010 at 12:19 PM, Paul Kyzivat <[e-mail]> wrote:
>>>
>>> What Dale says would help.
>>>
>>> But I'm still concerned with which entities this requirement applies to.
>>> RFC 3323 is being cited for Privacy header processing. But it assigns
>>> responsibility for that to a privacy service, and makes the UAC/UAS
>>> responsible for ensuring that the request passes through such a service.
>>> IIUC 42444bis is assuming that every server that supports 4244bis is
>>> potentially a privacy service.
>>>
>>> I'll be happy to learn that I'm entirely wrong in that assumption. I'd
>>> like
>>> to understand how privacy of H-I is intended to work in real use cases,
>>> and
>>> where the privacy service(s) are located to make that happen.
>>>
>>>       Thanks,
>>>       Paul
>>>
>>> Worley, Dale R (Dale) wrote:
>>>>
>>>> Mary Barnes writes (in the middle of a long exchange quoted below):
>>>>>
>>>>> That sentence is written within the context of core RFC 3261.  We
>>>>> really didn't get into the RFC 3325 trust domain concept in RFC 4244 -
>>>>> in particular because RFC 3325 is informational.  However, there is an
>>>>> UNLESS later in that section:
>>>>>
>>>>>   "...,unless the processing entity knows a priori that it can rely on
>>>>> a
>>>>>   downstream processing entity within its domain to apply the requested
>>>>>   privacy or local policy allows the forwarding."
>>>>
>>>> I think the problem can be fixed by deleting the phrase "within its
>>>> domain" (and also
>>>> "a priori", which doesn't add anything):
>>>>
>>>> "..., unless the processing entity knows that it can rely on a
>>>> downstream
>>>> processing
>>>> entity to apply the requested privacy ..."
>>>>
>>>> The crucial fact is "entity A knows that entity B will do it", not
>>>> whether
>>>> or how the
>>>> two entities are related to each other.  And in practice, whether or not
>>>> "entity A knows ..."
>>>> is clearer than whether or not "entity A is in the same trust domain as
>>>> entity B",
>>>> and possibly clearer than "entity A is in the same SIP domain as entity
>>>> B"
>>>> --
>>>> the latter two questions are fraught with definitional problems, whereas
>>>> the first
>>>> question is purely functional.
>>>>
>>>> Dale
>>>> ________________________________________
>>>> From: [e-mail] [[e-mail]] On Behalf Of
>>>> Mary Barnes [[e-mail]]
>>>> Sent: Wednesday, August 25, 2010 2:18 PM
>>>> To: Paul Kyzivat
>>>> Cc: SIPCORE (Session Initiation Protocol Core) WG
>>>> Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis
>>>>
>>>> Paul,
>>>>
>>>> In the context of 4244/-bis, the term domain is a DNS domain (per RFC
>>>> 3261) and not a SPEC-T Trust Domain per RFC 3325.  However, the specific
>>>> terminology we are referring to is also in RFC 3261 in that a SIP entity
>>>> can
>>>> be responsible for multiple domains, which is not a Trust domain, but is
>>>> something that can be configured.  That's the context meant in RFC
>>>> 4244/-bis.  It is outside the scope of RFC 3261 (and thus RFC 4244/-bis)
>>>> as
>>>> to how those relationships are configured. It could certainly be done
>>>> using
>>>> the Trust domain model, but again, that's out of scope.
>>>>
>>>> If it helps, I can add in the terminology section that domain (and the
>>>> terminology around the domains for which an entity is responsible, etc.
>>>> ) is
>>>> used in the same context as RFC 3261, but I personally don't think that
>>>> should be necessary.
>>>>
>>>> Mary.
>>>> On Wed, Aug 25, 2010 at 1:01 PM, Paul Kyzivat
>>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>> Mary Barnes wrote:
>>>> Actually, I did respond to that message, per the following:
>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg03088.html
>>>>
>>>> (threading in the email archives is no better than my archiving method
>>>> for
>>>> emails).
>>>>
>>>> Hmm. I cannot find that one anywhere in my own archives, and I don't
>>>> recall seeing it. Don't know why. :-(
>>>>
>>>> That sentence is written within the context of core RFC 3261.  We really
>>>> didn't get into the RFC 3325 trust domain concept in RFC 4244 - in
>>>> particular because RFC 3325 is informational.  However, there is an
>>>> UNLESS
>>>> later in that section:
>>>>
>>>> "...,unless the processing entity knows a priori that it can rely on a
>>>> downstream processing entity within its domain to apply the requested
>>>> privacy or local policy allows the forwarding."
>>>>
>>>> So, I will include that same clause in the sentence you are concerned
>>>> about.
>>>>
>>>> That doesn't do it for me. I think one way or another you need to
>>>> address
>>>> whether "domain" means "DNS domain" or "trust domain". And if it means
>>>> "trust domain" then of course we need a ref to 3325.
>>>>
>>>> You seem to mean DNS domain, but the kinds of actions you are discussing
>>>> seem more related to 3323 and 3325. ISTM that if you mean DNS domain
>>>> then
>>>> you mean it based on an assumption that "DNS domain" = "trust domain".
>>>>
>>>>      Thanks,
>>>>      Paul
>>>>
>>>> Thanks,
>>>> Mary.
>>>> On Wed, Aug 25, 2010 at 11:51 AM, Mary Barnes
>>>> <[e-mail]<mailto:[e-mail]>
>>>> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>> wrote:
>>>>
>>>>  Sorry, I should have replied to that thread, but I didn't think
>>>>  there was a change necessary.  I'll reply now.
>>>>
>>>>  Mary.
>>>>
>>>>  On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat
>>>> <[e-mail]<mailto:[e-mail]>
>>>>  <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>
>>>>      [as individual]
>>>>
>>>>      There was some discussion on the -00 version back in July that
>>>>      was not, AFAICT, addressed in the -01 version. There is a thread
>>>>      emanating from mary's announcement of the -00 version. The
>>>>      following is a hook into that thread:
>>>>
>>>>      http://www.ietf.org/mail-archive/web/sipcore/current/msg03056.html
>>>>
>>>>      It has to do with when privacy should be applied.
>>>>
>>>>             Thanks,
>>>>             Paul
>>>>
>>>>
>>>>      Adam Roach wrote:
>>>>
>>>>
>>>>           [as chair]
>>>>
>>>>          As a reminder, we're just over halfway through this WGLC,
>>>>          and have not yet seen any comments. Please take some time to
>>>>          review this draft.
>>>>
>>>>          /a
>>>>
>>>>          On 8/16/10 4:29 PM, Adam Roach - SIPCORE Chair wrote:
>>>>
>>>>
>>>>              [as chair]
>>>>
>>>>              A major author of draft-ietf-sipcore-rfc4244bis-01
>>>>              believes that the document has no remaining open issues,
>>>>              and is ready for evaluation. Today, we are starting a
>>>>              two-week working group last call period. This last call
>>>>              period ends on Tuesday, August 31st.
>>>>
>>>>              The latest version of the document can be retrieved here:
>>>>
>>>>              http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis
>>>>
>>>>              Any comments on the document should be sent to the
>>>>              SIPCORE mailing list.
>>>>
>>>>              /a
>>>>
>>>>              _______________________________________________
>>>>              sipcore mailing list
>>>>              [e-mail]<mailto:[e-mail]>
>>>> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>
>>>>              https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>>
>>>>          _______________________________________________
>>>>          sipcore mailing list
>>>>          [e-mail]<mailto:[e-mail]>
>>>> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>
>>>>          https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>>      _______________________________________________
>>>>      sipcore mailing list
>>>>      [e-mail]<mailto:[e-mail]>
>>>> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>
>>>>      https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>