Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis

Mary Barnes <mary.ietf.barnes@gmail.com> Tue, 02 November 2010 19:50 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 4D19B28C0F0 for <sipcore@core3.amsl.com>; Tue, 2 Nov 2010 12:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qFZItHs4pajf for <sipcore@core3.amsl.com>; Tue, 2 Nov 2010 12:50:42 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 40C943A6A03 for <sipcore@ietf.org>; Tue, 2 Nov 2010 12:50:42 -0700 (PDT)
Received: by vws3 with SMTP id 3so77789vws.31 for <sipcore@ietf.org>; Tue, 02 Nov 2010 12:50:46 -0700 (PDT)
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=EgopPEhLUSNtDwSoIn12HHNccC5FVsixkSCI+ZFdmYU=; b=ikKr9uEGABJNE15kVJXErmsi8Qzw/9t2gqT0yfFC0dE7EfOimavQRKqA3PyC4nvTiW yIbD2OyDKRboUfiKPBwCsXjqtLdcHNToncgXR0R/Fgnlt25x0Gm9d+F5Q8HysmK2H+Fd Pd5LRM9n+TwwVdvX0R0BTWX70ANVX6gI9t71Y=
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=GPAJ9ItAXFySoFeNSUIx7kPbiDFR3fpSYI29Qp4u3wPyIIP2PcA7LpiwUNj4B2oA0u P7bXLot2GambZGTjqDlYLgDgVUeIo+yuGknJPKyGmEcM6r5vbSN41PrngK1maEc/DOl9 JyXJWOhwnsj+gFHCkKqZcgbAEMVPdg4aCwtJ0=
MIME-Version: 1.0
Received: by 10.224.205.200 with SMTP id fr8mr7250733qab.198.1288727446845; Tue, 02 Nov 2010 12:50:46 -0700 (PDT)
Received: by 10.236.28.41 with HTTP; Tue, 2 Nov 2010 12:50:46 -0700 (PDT)
In-Reply-To: <A444A0F8084434499206E78C106220CA023554638D@MCHP058A.global-ad.net>
References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> <A444A0F8084434499206E78C106220CA01C4874C5F@MCHP058A.global-ad.net> <AANLkTi=Sz5ddsWVmta5N_T8JHhrSytzALQDw=kzLcQAV@mail.gmail.com> <A444A0F8084434499206E78C106220CA023554638D@MCHP058A.global-ad.net>
Date: Tue, 2 Nov 2010 14:50:46 -0500
Message-ID: <AANLkTikxiK2S0oQ6Q7=JkwxYNjxK3O7BBrx+sWUQ5vOB@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: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis
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: Tue, 02 Nov 2010 19:50:43 -0000

John,

I've done the same. A couple responses inline below [MB2].

Thanks,
Mary.

On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John
<john.elwell@siemens-enterprise.com> wrote:
> Mary,
>
> I have responded below, stripping out the stuff where I have nothing further to add.
>
<snip>
>> > 2. It nearly always uses the term "header" rather than
>> "header field", although never, as far as I know, meaning the
>> entire SIP header.
>> [MB] I'm not sure that I fully understand the concern. Can you point
>> out a specific sentence or section of concern?  The term "header" is
>> used when it is referring to the History-Info header field, but that
>> is done in other documents as well.  In general, I think it's
>> understood that it's referring to the header field when it's
>> qualified. Perhaps you're referring to places where it is not
>> qualified?   The term hi-entry is used, as well.
>> [/MB]
> [JRE] I have explained in more detail in my comments on -02.
[MB2] I've responded to that in my subsequent response to your comments. [/MB2]
>
> <snip/>

>> >
>> > 18. Section 4.2.2:
>> > "the UAS MUST
>> >   include any History-Info received in the request  in the
>> subsequent
>> >   response"
>> > Does this include 100 responses?
>> [MB] I would think so. Can you think of a reason why it shouldn't?  I>> would think it could be useful for debug. [/MB]
> [JRE] The 100 response typically only travels back a single hop, so the benefit of H-I in a 100 is marginal. Also some implementations might send back a 100 response quite early during processing, perhaps even before they decide whether to act as a proxy, a UAS or a redirect, so knowing how to populate H-I in a 100 might be difficult.
[MB2] If it has no additional hi-entries, then there is nothing
additional to send back, so I don't think it hurts anything - I would
agree that in most cases it's of marginal value. We can include it as
an exception in that sentence if you would prefer, although per the
next comment, it seems that you are okay with leaving it as is.
[/MB2]
>
> <snip/>
>> >

>> >
>> > 26. Section 5.2:
>> > "A proxy that receives a request with the "histinfo" option
>> tag in the
>> >   Supported header, SHOULD forward captured History-Info in
>> subsequent,
>> >   provisional , and final responses "
>> > Does this include 100 responses?
>> [MB] That's the implication of "provisional" per RFC 3261. [/MB]
> [JRE] I am doubtful about the usefulness of 100. However, it is probably fairly academic, since 100 will probably have been sent earlier. A proxy is unlikely to send a 100 after receiving a provisional response from a downstream entity.
>
>> >
>> > 27. Section 5.2:
>> > "A proxy MAY anonymize any hi-entry whose domain corresponds to a
>> >   domain for which it is responsible (as per [RFC3323 ])."
>> > I don't think RFC 3323 tells me how to anonymize an hi-entry.
>> [MB]  RFC 3323 discusses anonymization and the role of an anonymizer,
>> etc. So, I'm not clear on your concern. [/MB]
> [JRE] I guess if we talked about anonymizing the URI in the hi-target-to-uri it would be clearer.
[MB2] That's fine...I'll make it explicit that it's the
hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2]
>
> <snip/>
>
>
> John