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

Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 08 November 2010 06:56 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85373A69BA for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 22:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level:
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaGymPzRLNRm for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 22:55:47 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0FD943A6996 for <sipcore@ietf.org>; Sun, 7 Nov 2010 22:55:29 -0800 (PST)
Received: by ywp6 with SMTP id 6so3453586ywp.31 for <sipcore@ietf.org>; Sun, 07 Nov 2010 22:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ir1vIxOYUXzh7MeU9oXgBtyB7hSdprjPVQnm6pzEoic=; b=C3Y+WuQ5OHWRu47lQM3S7A/iRzGFd3V9t+NwTLNdIzTG2K3jUsZ2jqmwpHxcC+tSp+ b++3RD4RYK46HY+Z0bPG1SMeR2/pQIW1MJZOus/czxsDZ7h4omAnRxk6GHLw1sIN/JES hI6wKG4l+PHMPwEV7Pd+8IXlCGXb/qCGpbFQM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hkzvhxkc0HcHyemaB9SZCxMfbo/RO3NZ9IyhUj3HQTepA117j1VmJpCKYELHqx+cfn rNHZPZ4tCZKYO2knz9x8vebxC6txnxvJy4wy9dUdJ4QEKl+yFiCploZ8aQ6pOimBQFQU 61rndogTFrFTlEhAQNbzs3EXgFqlM+28rhono=
MIME-Version: 1.0
Received: by 10.150.144.16 with SMTP id r16mr7981781ybd.204.1289199348647; Sun, 07 Nov 2010 22:55:48 -0800 (PST)
Received: by 10.236.95.35 with HTTP; Sun, 7 Nov 2010 22:55:48 -0800 (PST)
In-Reply-To: <A444A0F8084434499206E78C106220CA02357AD547@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA0235546D2F@MCHP058A.global-ad.net> <A5DC4410-2B76-4EC6-B39A-1FFF5F04B853@ntt-at.com> <AANLkTikXeBRvTaDg8ZX+TsqG_ZL24FUiQFf2se5UAgcm@mail.gmail.com> <A444A0F8084434499206E78C106220CA02357AD547@MCHP058A.global-ad.net>
Date: Mon, 8 Nov 2010 00:55:48 -0600
Message-ID: <AANLkTimdU=yBVRUUSK9qFgfuBV7J3g1PDZMwqQrQP_=A@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "Barnes, Mary" <Mary.Barnes@polycom.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 06:56:02 -0000

A few more comments below [MB2].

Thanks,
Mary.

On Mon, Nov 8, 2010 at 12:31 AM, Elwell, John
<john.elwell@siemens-enterprise.com> 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.

[MB2] My opinion is that we should mandate the anonymization in the
same form as in RFC 3323.   I can't think of a reason why it shouldn't
be mandated.  [MB2]
>
> <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?
[MB] It can't be an integer since it can't have negative values.  But,
you are correct, we do need to allow multi-digit indices, so the ABNF
needs to be fixed. [/MB]
>
>> >> 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.
>
> <snip/>
>
> John