Re: [sipcore] Updated 4244bis and new call flow document

If we are going to talk about trust domains in the document, then you will have to say what they are.

For the RFC 3325 stuff there is most of a document that talks about that. Moreover, you need to say what to "trust" the next entity to do if you do not do it.

To give some idea of what I mean. Statements like "I will give you the identity if you do not reveal it to anyone outside our area of trust" are slightly different to "I trust you to implement the privacy that I otherwise would have done so if I did not trust you".

regards

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Friday, July 23, 2010 2:12 PM
> To: R.Jesske@telekom.de
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Updated 4244bis and new call flow document
> 
> 
> 
> R.Jesske@telekom.de wrote:
> > Hi Mary,
> > With regard to your question for comments/review, I went 
> thought the draft.
> > 
> > For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt
> > 
> > I have the following comments: 
> > 
> > 
> > 6.3.2.  Privacy in the History-Info Header
> > 
> > ...
> > If the requestor has indicated a priv-
> >    value of "session" or "header" in the request, all History-Info
> >    entries MUST be anonymized when the request leaves a 
> domain for which
> >    the intermediary is responsible.
> > ...
> > 
> > In this section it is mentioned that the entries must be 
> anonymized when leaving the domain. I thought that if a trust 
> relationship between domains are existing and the following 
> domain secures the "privacy" then the information could be 
> forwarded and will then deleted by the succeeding domain 
> before reaching the terminating user. 
> > Some regulators are requesting to pass identities until the 
> last domain where it is possible to execute the privacy 
> regarding RFC3323. So I think this is a MAY based on domain 
> policy. And it is a MUST when the succeeding network cannot 
> guarantee the privacy.
> > 
> > Or do I misunderstand the meaning of "domain for which the 
> intermediary is responsible"
> 
> I'm not an expert on this, but ISTM that in the case you 
> describe the request is not leaving the *trust* domain.
> 
> But that does point out ambiguity in the text you quote. That 
> kind of wording "domain for which the intermediary is 
> responsible" is usually talking about *DNS* domains, not 
> *trust* domains. So maybe that should say:
> 
>   ...
>   If the requestor has indicated a priv-value of "session" or "header"
>   in the request, all History-Info entries MUST be anonymized when the
>   request leaves a *trust* domain for which the intermediary is
>   responsible.
>   ...
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 