Re: [sipcore] Yet more comments on rfc4244bis-02

Hi Roland;

 I meant to say, mandate the use of domain name "anonymous.invalid" as 
it is mandated in RFC3323 and used as a means to distinguish anonymized 
URI in RFC5079. This would help privacy service to see if other privacy 
service has already obfuscated the URI in H-I. 

 Regards
  Shida

On Nov 8, 2010, at 4:55 PM, <R.Jesske@telekom.de> <R.Jesske@telekom.de> wrote:

> Shida,
> Do I understand you correct that you woulf like to mandate the uri format e.g. anonymus@anonymus,invalid? 
> Why you would like it to be stronger than in RFC3323 mandated?
> 
> Best Regards
> 
> Roland
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Shida Schubert
> Gesendet: Montag, 8. November 2010 07:50
> An: Elwell, John
> Cc: Barnes, Mary; sipcore@ietf.org
> Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02
> 
> 
> Hi John;
> 
> My comments inline.
> 
> On Nov 8, 2010, at 3:31 PM, Elwell, John wrote:
> 
>> Replying to both Shida and Mary: 
>> 
>>> -----Original Message-----
>>> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
>>> Sent: 08 November 2010 05:19
>>> To: Shida Schubert
>>> Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org
>>> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
>>> 
>>> A few additional comments inline below [MB].
>>> 
>>> Mary.
>>> 
>>> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert 
>>> <shida@ntt-at.com> wrote:
>>>> 
>>>> Hi John;
>>>> 
>>>> My responses on some of the comments, I think
>>>> Mary may be responding on the same issues but here are mine.
>>>> 
>>>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote:
>>>> 
>>>>> 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.
>>>> 
>>>> You are right. The intention was to say "remove the 
>>> priv-value and remove the privacy
>>>> header itself if there are no other priv-value left (id may 
>>> exists which needs
>>>> to remain in the request until it reaches the egress point)".
>>>> 
>>>>> 
>>>>> 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 anonymous@anonymous.invalid. Is this how it MUST be done?
>>> 
>>> [MB] It is only the hi-targeted-to-uri that needs to be anonymized -
>>> it is a MUST. The other parameters MUST not be changed. [/MB]
>> [JRE] You didn't express any opinion whether we should mandate the way in which hi-targeted-uri is to be anonymized.
> 
> To avoid redundant anonymization in case there are numerous 
> proxy acting as a privacy services, it would be good to mandate 
> how hi-targeted-uri is anonymized, so I am happy to say MUST 
> here. 
> 
>> 
>> <snip/>
>> 
>>>>> 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?
>>>> 
>>>> How about we remove the "lowest/last" and simply
>>>> say incrementing the digit at the current level by 1 or
>>>> something like that.
>> [JRE] Why can't we specify the field as an integer, and then we can say we increment the integer?
> 
> Sounds good to me. 
> 
>> 
>>>>> 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.
>>>> 
>>>> This would happen, say for example if request was
>>>> parallel forked, each branch would have the hi-entry
>>>> that only the forked request traversed but missing
>>>> the information of the other forks. I don't know if I would
>>>> consider what you describe as a gap. You may be
>>>> missing the other branches but you should be able to
>>>> identify the gap in index for the branch that request
>>>> traversed. (You may be missing the actual hop in the
>>>> logical tree of History-Info that does not support
>>>> 4244/4244bis but as they won't add the hi-entry
>>>> there won't be a gap in index itself).
>> [JRE] Yes, I understand that, and that is why I just asked the question - I don't have a strong opinion as to whether this is good enough or not.
> 
> I think we can definitely add a text saying the hi-entries 
> an entity receives may not represent the whole picture 
> of where request was sent (other branches etc.). 
> 
> Regards
>  Shida
> 
>> 
>> <snip/>
>> 
>> John
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore