I have reviewed this draft. In my opinion it is almost ready to go,
apart from fixing a few minor points listed below and a few nits sent
separately to the authors.
1. "The UA-driven privacy mechanism defined in this document will not
eliminate the need for RFC 3323 usage defined in [RFC3325] which
instructs privacy service to delete P-Asserted-Identity header. In
order to delete a P-Asserted-Identity header, a user agent needs to
set Privacy:id even when the user agent is utilizing this
specification."
I don't think this quite captures everything. I would suggest the
following rewording:
"The UA-driven privacy mechanism defined in this document will not
eliminate the need for the RFC 3323 usage defined in [RFC3325], which
instructs a privacy service not to forward a P-Asserted-Identity header
field outside the Trust Domain. In order to prevent forwarding a
P-Asserted-Identity header field outside the Trust Domain, a user agent
needs to include the Privacy header field with value 'id' (Privacy:id)
in the request, even when the user agent is utilizing this
specification."
2. "privacy-sensitive information:
The information that identifies a user who sends the SIP
message, as well as the supplementary information that
can be used to guess the user's identity."
I would suggest we change "the supplementary information" to "other
information".
3. "The concept of privacy in this document is the act of concealing
identity of a user and supplementary information."
I would suggest we change to:
"The concept of privacy in this document is the act of concealing
privacy-sensitive information."
(since we already have a definition of privacy-sensitive information)
4. "Some fields of SIP messages that potentially contain privacy-
sensitive information do not interfere with establishing dialog and
can be omitted without any side effects. Other fields are essential
for establishing dialog and need to have its value replaced to
anonymized values in order to obscure privacy-sensitive information."
Establishing dialogs is not the sole purpose of SIP messages. Some SIP
messages are mid-dialog, and others are not dialog-related at all. I
would propose:
"Some fields of a SIP message potentially contain privacy-sensitive
information but are not essential for achieving the intended purpose of
the message and can be omitted without any side effects. Other fields
are essential for achieving the intended purpose of the message and need
to contain anonymized values in order to avoid disclosing
privacy-sensitive information."
5. "If the Registrar supports the GRUU and returns a REGISTER response,
the user agent SHOULD search within the REGISTER response for a
"temp-gruu" URI parameter, which provides the desired privacy
property. If the "temp-gruu" URI parameter and value is present
within the REGISTER response, the user agent SHOULD use the value of
the "temp-gruu" as an anonymous URI representing the user agent.
This URI SHOULD be used for the Contact header in subsequent requests
and responses."
It is not clear why each of these "SHOULD"s are not "MUST"s. The first
paragraph of 4.1 already allows an exception to use of GRUU where the UA
is able to obtain a functional anonymous URI by other means. I think the
present paragraph is only concerned with the case where GRUU is to be
used, so "MUST" would be appropriate for each normative statement.
However, I also think the paragraph should begin with a qualification
and a requirement to request GRUU. Also I think the present first
sentence is redundant. Finally, there are some cases where the temp-gruu
URI is unsuitable for placing in a Contact header field (e.g., in a 302
response). So I would propose:
"In order to use the GRUU mechanism to obtain a functional anonymous
URI, the UA MUST request GRUU in the REGISTER request. If a "temp-gruu"
URI parameter and value are present in the REGISTER response, the user
agent MUST use the value of the "temp-gruu" as an anonymous URI
representing the user agent. This means that the user agent MUST use
this URI as its local target and MUST place this URI in the Contact
header field of subsequent requests and responses that require the local
target to be sent."
6. "IP address of the media relay"
Since we are also considering using a relay for the IP address to be
used in Via, it is then not a media relay. Suggest change to:
"IP address of a relay".
7. "Furthermore, when a user agent uses relay server to conceal its
identity, the user agent MUST send requests to the relay server to
ensure request and response bypass the same signaling path."
I think the intention here is to say:
"Furthermore, when a user agent uses a relay server to conceal its
identity, the user agent MUST send requests to the relay server to
ensure request and response follow the same signaling path."
8. "Without privacy considerations, this field contains a URI used to
reach the user agent for mid-dialog requests and possibly out-of-
dialog requests, such as REFER [RFC3515]. The Contact header field
can also contain a display-name. Since the Contact header field is
used for routing further requests to the user agent, it must include
a functional URI even when it is anonymized."
This is not quite true. It does not apply to the Contact header field in
REGISTER requests or in 3xx responses. Perhaps it should begin "When
using this header field in a dialog-forming request or response or in a
mid-dialog request or response, this field contains the local target,
i.e., a URI used to reach the user agent for mid-dialog requests and
possibly out-of-dialog requests, such as REFER [RFC3515]...."
9. "A user agent generating an anonymous SIP message supporting this
specification MUST anonymize a Contact header using an anonymous URI
("temp-gruu")..."
Again this is not quite accurate. Suggest:
"When using this header field in a dialog-forming request or response or
in a mid-dialog request or response, the user agent MUST anonymize the
Contact header field using an anonymous URI ("temp-gruu")..."
9. In the same paragraph: "or an anonymous URI
containing an IP address obtained through the TURN mechanism"
The discussion of TURN in section 4 mentioned its use only for Via and
SDP, not for Contact. I think we should delete these words (and also the
words relating to TURN in the next paragraph).
10. "However, the SIP-Identity will fail with the From
header of option 1 because the SIP-Identity mechanism uses
authentication based on the domain name."
I would not say that it will fail. I would prefer to say that it cannot
be used:
"However, SIP-Identity cannot be used with a From header field in
accordance with option 1, because the SIP-Identity mechanism uses
authentication based on the domain name."
11. "If a user agent is aware that SIP-Identity mechanism will be
applied
to the request"
I would prefer to say:
"If a user agent expects the SIP-Identity mechanism to be applied to the
request"
12. "5.1.2. From Header Field"
This entire sub-section applies only to From in requests, not in
responses. This should be made clear throughout. Or simply change the
title to "5.1.2. From Header Field in requests". Similar considerations
apply to Via (5.1.3).
John
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
