[sipcore] Yet more comments on rfc4244bis-02

["Elwell, John" <[e-mail]>]

1. Section 7.3.1.
"If there is a Privacy header in the request with a priv-
   value of "header" or "history", then the initial hi-entry MUST be
   anonymized and the header removed when the request leaves a domain
   for which the SIP entity is responsible."
I think it should say "...and the Privacy header removed" - there is no point in removing the H-I header field if we have anonymized it.

2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show just the URI anonymized and with the value [e-mail]. Is this how it MUST be done?

3. In the same sentence, is it sufficient to anonymize only the first hi-entry? There could be further hi-entries for the same domain, and just revealing internal routing within the domain might be considered a breach of privacy. Perhaps in that case you would need to rely on those additional hi-entries being separately marked for privacy. If that is so, it would seem to be OK.

4. "In addition, the History-Info header can reveal general routing and
   diverting information within an intermediary, "
Is it only routing information within an intermediary, or also routing information within a domain that you might want to make private? I think text later in the paragraph concurs with the latter view.

5. "Finally, the terminator of the request may not want to reveal the
   final reached target to the originator.  In this case, the terminator
   uses the a value of "history" in the Privacy header in the last hi-
   entry in the response.  The SIP entity that forwards the response
   MUST anonymize that hi-entry and remove the Privacy header."
Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been marked by proxies in the final domain as private? These will get passed back in the response without anonymization since they are not the final hi-entry and are not covered by this statement. Should the final sentence apply to any hi-entry?

6. Section 7.3.3:
"To
       accomplish this, the processing entity MUST read the value from
       the History-Info header in the received request and MUST add
       another level of indexing "
Should make it clear it is the last hi-entry of the received request (after adding entries on behalf of previous hops).

7. "followed
       by an initial index for the new level of 1"
I think this would be clearer if it said:
"followed by an initial index of 1 for the new level"

8. "MUST be calculated by incrementing the last/lowest digit
       at the current level"
and 
"That is, the lowest/last digit of the index MUST be
       incremented "
What if an index is a double-digit integer?

9. Section 8:
"an
   application might need to provide special handling in some cases
   where there are gaps."
Should there be a note discussing the fact that some gaps are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, say, is missing.

10. Should we say anything in section 8 about anonymized entries? Note that what we might say depends to some extent on whether what exactly gets anomymised. For example if an application searches for an rc or mp entry, if those parameters have been anonymized it will not find them (but might find others that have not been anonymized!), but if those parameters have not been anonymized it will find them but the URI will be useless.

11. Section 9:
"With the level of security provided by TLS (SEC-req-3), the
   information in the History-Info header can thus be evaluated to
   determine if information has been removed by evaluating the indices
   for gaps (SEC-req-1, SEC-req-2).  "
This is subject to the limitation pointed out in a comment above, about not all gaps being detectable.

12. I would expect to see something in section 9 concerning privacy. We should mention the privacy mechanism and discuss its limits (i.e., depends on trust of downstream entities to anonymize privacy-marked entries). Also there should probably be some discussion on strength of anonymization algorithms (unless we are indeed prescribing [e-mail])

13. Section 10.2:
"This document defines a priv-value for the SIP Privacy header:
   history The following changes have been made to
   http://www.iana.org/assignments/sip-priv-values The following has
   been added to the registration for the SIP Privacy header:"
I am not sure how to parse this.

14. Section 12.1:
"This specification adds an
   optional SIP header field parameter to the History-Info and Contact
   headers.  "
In fact it adds two parameters to each.

15. "Entities that have not implemented this specification MUST
   ignore these parameters, "
We cannot place a normative requirement on entities that don't implement this. Change "MUST" to "will".

John