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

"Elwell, John" <john.elwell@siemens-enterprise.com> Tue, 02 November 2010 09:06 UTC

Return-Path: <john.elwell@siemens-enterprise.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 423603A6872 for <sipcore@core3.amsl.com>; Tue, 2 Nov 2010 02:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.27
X-Spam-Level:
X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 PHjSG0rExqZE for <sipcore@core3.amsl.com>; Tue, 2 Nov 2010 02:06:14 -0700 (PDT)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A5B0D3A68B6 for <sipcore@ietf.org>; Tue, 2 Nov 2010 02:06:13 -0700 (PDT)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2138315; Tue, 2 Nov 2010 10:06:15 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 012BB23F0278; Tue, 2 Nov 2010 10:06:15 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 2 Nov 2010 10:06:14 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tue, 2 Nov 2010 10:06:13 +0100
Thread-Topic: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis
Thread-Index: Act5+pNorfCuzKISSn61y7INZ5j3DQAbCzvg
Message-ID: <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>
In-Reply-To: <AANLkTi=Sz5ddsWVmta5N_T8JHhrSytzALQDw=kzLcQAV@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 09:06:15 -0000

Mary,

I have responded below, stripping out the stuff where I have nothing further to add. 

> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
> Sent: 01 November 2010 19:25
> To: Elwell, John
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] REMINDER: Re: WGLC: 
> draft-ietf-sipcore-rfc4244bis
> 
> John,
> 
> I apologize for missing these in the round of -02 changes. Per the
> other email thread, some of these are no longer relevant due to the
> extent of changes and some were redundant with issues raised
> (individually) in the tracker.   So, I'll just responsd to  those that
> are still relevant [MB].  I will note that one thing that would help
> me  to avoid losing document reviews in my mailbox is that if folks
> could change the "Reminder" to (or prepend) the term "Review" (or
> "Comments") so that the email is a bit easier to find when one's
> mailbox is overflowing with issues from the issue tracker.
[JRE] Yes, good idea.

> 
> Thanks,
> Mary.
> 
> On Tue, Aug 31, 2010 at 11:32 AM, Elwell, John
> <john.elwell@siemens-enterprise.com> wrote:
> > I have reviewed the document as far as section 8, before 
> running out of time. Although the technical content of the 
> document is reasonably stable, there are far too many minor 
> problems that need fixing before it is ready to go. Specific comments:
> >
> > 1. In general, there are too many normative statements 
> (MUST/SHOULD) written in the passive voice, or in the active 
> voice with an inappropriate subject. I have pointed out a few 
> of these in later comments, but all should be checked.
> >
> > 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.

<snip/>

> >
> > 7. Section 4.1:
> > "and if the Request-URI was modified by a previous hop"
> > What is a hop? I tend to think of a hop as being the "wire" 
> between two SIP entities, but here it seems to be used to 
> mean a SIP entity such as a proxy. If we really want to use 
> this term, we should define it. Check for other instances too.
> [MB] I will change this to "previous SIP hop". Note that the term
> "hop" is used throught RFC 3263. If you would like, I could add a note
> in the terminology that the term is consistent with that. [/MB]
[JRE] I am not even sure it is consistent in RFC 3263. Anyway, given existing mixed usage of the term, I withdraw the comment.

<snip/>

> >
> > 15. Section 4.2.1:
> > "the
> >   UAS MUST insert an hi-entry ."
> > How is this testable, other than by the fact that H-I will 
> get reflected in the response? But that should be covered in 
> 4.2.2, shouldn't it?
> [MB] It's not testable on the wire. However, to applications at the
> UAS expecting that entry to be in a request that they might receive,
> it would seem appropriate that the field be added to the Request that
> is presented to any application. Doing that also ensures it will be in
> the response which is what the text currently states. I do not think
> that applications should be screening the information it receives to
> look for this situation. [/MB]
[JRE] OK, I can live with it as it is.

<snip/>

> >
> > 17. Section 4.2.2:
> > "The information can also be useful for
> >   implementations with B2BUAs that include the 
> History-Info, received
> >   in the incoming request, in the subsequent outgoing request."
> > The words "implementations with B2BUAs" seem strange - why 
> not just "B2BUAs"?
> [MB] I don't see this text in section 4.2.2. of -01 nor 5.2.2 of -02.
>  I think you are referring to section 4.2.1.  I'll change that it was
> trying to qualify a B2BUA as something that was very implementation
> specific and not standard SIP per se. [/MB]
[JRE] Yes, sorry, it was 4.2.1.

> >
> > 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.

<snip/>
> >
> > 25. Sections 5.1.2 and 5.1.3. These are different, in that 
> 5.1.2 allows for multiple branches failing, but 5.1.3 allows 
> for only a single request encountering 3xx. Firstly, it is 
> possible >1 request can return 3xx (the proxy is not forced 
> to recurse immediately the first 3xx arrives). Secondly it is 
> possible that some failure responses might arrive before the 
> 3xx on which the proxy recurses. I think the new request 
> should reflect H-I from all previous branches, not just the 
> one leading to recursion. Also the tagging of the recursed 
> request should take account of all previous branches.
> [MB] Yes - the redirection case should be consistent.  And, really I
> don't know that we need a separate case for redirection as I agree it
> should send the aggregate information, as well.  [/MB]
[JRE] I think I made a similar comment on -02 already. Anyway, we seem to be in agreement.

> >
> > 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.

<snip/>


John