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

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