Re: Nits in draft-ietf-sip-ua-privacy-04

John,

Thank you for the reminder.
I am so sorry that I totally missed those
nits comments.

I will correct the draft to incorporate
your comments and submit 05 version soon.

Mayumi


> Mayumi,
> 
> I note that my previous comments of substance have all been taken into
> account.
> 
> However, nits that I sent to you privately (see attached email) have not
> been into account.
> 
> In addition I have detected a further nit:
> 
> In section 5.1.1 it says:
> "...and refer to Section 4.2 for details on how to obtain
>    an IP address through TURN."
> Since IP addresses are not mentioned in the rest of 5.1.1, this seems
> irrelevant. The words should be deleted.
> 
> When these nits have been fixed, in my opinion the document will be
> ready to go.
> 
> John
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Nits in draft-ietf-sip-ua-privacy-03
> From:
> "Elwell, John" <[email protected]>
> Date:
> Tue, 11 Nov 2008 14:35:25 -0000
> To:
> "Mayumi Munakata" <[email protected]>, "Shida Schubert" 
> <[email protected]>
> 
> To:
> "Mayumi Munakata" <[email protected]>, "Shida Schubert" 
> <[email protected]>
> 
> 
> Mayumi, Shida,
> 
> I am sending you nits separately. My main comments have been posted to
> the SIP list.
> 
> 1. "by allowing user agent to
>    take control of its privacy, rather than being completely dependent
>    on external privacy service."
> Change to
> "by allowing a user agent to
>              ^^
>    take control of its privacy, rather than being completely dependent
>    on an external privacy service."
>       ^^^
> 
> 2. "If revealing the domain name in Contact
>    header field "
> Change to:
> "If revealing the domain name in the Contact
>                                  ^^^^
>    header field "
> 
> 3. "A user agent that is not provided with a functional anonymous IP
>    address through some administrative means, MUST obtain a relayed
>    address if anonymity is desired (IP address of the media relay) for
>    use in SDP and in Via header.  Such IP address is to be derived from
>    a STUN relay server through TURN mechanism, which allows a STUN
>    server to act as a media relay."
> Change to:
> "A user agent that is not provided with a functional anonymous IP
> address through some administrative means MUST obtain a relayed address
> (IP address of a relay) if anonymity is desired for use in SDP and in
> the Via header field. Such an IP address is to be derived from a STUN
> relay server through the TURN mechanism, which allows a STUN server to
> act as a relay."
> (Various changes, including deletion of "media", since the relay is also
> used for Via (signalling)).
> 
> 4. "A user agent SHOULD go with option 1 to conceal its domain name in
>    From header field."
> Insert "the" in front of "From".
> 
> 5. "If user wants both anonymity and strong identity, use a third party
>    anonymization service which issues AoR for the use in From address
>    which also provides SIP-Identity."
> Various changes:
> "If the user wants both anonymity and strong identity, a solution would
> be to use a third party anonymization service that issues an Address of
> Record (AoR) for use in the From header field of a request and that also
> provides a SIP-Identity Authentication Service."
> 
> 6. "Without privacy considerations, the bottommost Via header field
> added
>    by a user agent"
> Add "to a request".
> 
> 7. "Via header SHOULD NOT include a host name."
> Change to:
> "The Via header field SHOULD NOT include a host name."
> 
> 8. "Furthermore, if the provider of the caller intending to obscure its
>    identity consists of a small number of people (e.g. small enterprise,
>    SOHO), the domain name alone can reveal the identity of the caller
>    when this specification is used."
> Delete "when this specification is used". It is irrelevant whether this
> specification is used - the domain name can in any case reveal
> information.
> 
> 9. "Same can be true when the provider is large, but the receiver of the
>    call only knows few people from the source of call."
> Change to:
> "The same can be true when the provider is large but the receiver of the
>  ^^^^^                                          ^ (delete commma)
>    call only knows a few people from the source of call."
>                    ^^
> 
> 10. "The domain name in From header can be obscured as described in
>    section 5.1.2, on contrary the Contact header needs to contain a
>    valid domain name at all time to function properly."
> Change to:
> "The domain name in the From header field can be obscured as described
> in
>    section 5.1.2, whereas the Contact header field needs to contain a
>    valid domain name at all times in order to function properly."
> 
> 11. "If one wants to assure anonymization, it is recommended for the
> user
>    to seek and rely on third party anonymization service."
> Change "third" to "a third".
> 
> 12. "A third party anonymization service provides registrar and TURN
>    service which has no affiliation with the caller's provider, allowing
>    caller to completely withhold its identity."
> Change to:
> "A third party anonymization service provides registrar and TURN
>    services that have no affiliation with the caller's provider,
> allowing
>    the caller to completely withhold its identity."
> 
> There are still several places where "header" is used instead of "header
> field". A SIP message, like an HTTP message, has only one header yet
> many header fields.
> 
> Regards,
> 
> 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