Hi Roland,

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.


Thanks,

Mary.



On Fri, Jul 23, 2010 at 4:15 AM, <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"
>
>
>  The Rest of the document looks good for me.
>
> Best Regards
>
> Roland
>
>
> Deutsche Telekom Netzproduktion GmbH
> Fixed Mobile Engineering Deutschland
> Roland Jesske
> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
> +49 6151 628-2766 (Tel.)
> +49 521 9210-3753  (Fax)
> +49 171 8618-445  (Mobil)
> E-Mail: r.jesske@telekom.de
> www.telekom.com
>
> Erleben, was verbindet.
>
> Deutsche Telekom Netzproduktion GmbH
> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis,
> Klaus Peren
> Handelsregister: Amtsgericht Bonn HRB 14190
> Sitz der Gesellschaft: Bonn
> USt-IdNr. DE 814645262
>
> Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede
> E-Mail drucken.
>
>
> -----Ursprüngliche Nachricht-----
> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag
> von Mary Barnes
> Gesendet: Donnerstag, 1. Juli 2010 21:31
> An: SIPCORE
> Betreff: Re: [sipcore] Updated 4244bis and new call flow document
>
> Hi folks,
>
> I have not seen any responses to this email. So, either folks don't
> see any issues with the documents and 4244bis is ready for WGLC or
> folks have not reviewed the documents.  I'm happy to assume the
> former, however, it would be good for folks that have read the docs to
> post a note on the mailing list as to whether they think  4244bis is
> ready for WGLC.  And, if not, please detail your concerns, so that we
> can determine whether they warrant discussion in Maastricht.
>
> Also, opinions on how/where to progress the call flow document would
> be welcome.  I personally do not think it's worthwhile to pursue this
> in DISPATCH, but it's not clear to me whether informational docs like
> this are under the purview of the SIPCORE charter.  Since BLISS is
> trying to close down, it is also not appropriate to pursue the work
> there.
>
> Thanks,
> Mary.
>
> On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes <mary.ietf.barnes@gmail.com>
> wrote:
> > Hi folks,
> >
> > The 4244bis draft has been updated and a separate call flow document
> > created per the earlier summary of proposed changes:
> > http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html
> >
> > http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt
> > http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.txt
> >
> > There are  two voicemail examples in the new call flow document.  The
> > 4244bis has 3 call flows - the basic sequential forking and two
> > privacy examples. All the rest are now in the call flow document.
> >
> > The other changes we made were updates to the UAC, UAS and application
> > considerations section - adding additional text as to how the UAC and
> > UAS process hi-entries (including related to responses).  The
> > application considerations section now describes how the tags can be
> > used to derive specific information and the past guidelines were
> > removed since 4244bis has much definitive guidance on the normative
> > aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via
> > anonymization rather than removing entries, etc.) as summarized in
> > Section 11.
> >
> > Please review and provide any additional comments. We believe that
> > 4244bis is pretty much ready to go. We can fine tune the details in
> > the call flows and should be able to get that ready very soon, as
> > well.  Let us know if you see additional use cases you would like to
> > add.
> >
> > Thanks,
> > Mary et al
> >
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>