Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
"Elwell, John" <john.elwell@siemens-enterprise.com> Mon, 03 January 2011 17:03 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 44F773A685A for <sipcore@core3.amsl.com>; Mon, 3 Jan 2011 09:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level:
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 j5VNQRBYyuV7 for <sipcore@core3.amsl.com>; Mon, 3 Jan 2011 09:03:38 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C90073A67C0 for <sipcore@ietf.org>; Mon, 3 Jan 2011 09:03:34 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2869734; Mon, 3 Jan 2011 18:03:30 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 7E8B21EB82B6; Mon, 3 Jan 2011 18:03:30 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 3 Jan 2011 18:03:30 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Mon, 03 Jan 2011 18:03:28 +0100
Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
Thread-Index: AcuniX3IOT792rFUSCygFfLxIhIeSwD3mMhQ
Message-ID: <A444A0F8084434499206E78C106220CA03C5AF1EA8@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA023554628B@MCHP058A.global-ad.net> <AANLkTi=B1qL2D-U85mMp3Dft2kvmuB9Sv5EAQ9vQBtot@mail.gmail.com> <A444A0F8084434499206E78C106220CA0235546979@MCHP058A.global-ad.net> <AANLkTimsf=bsbJfJPKB_WgZjDGpR0GRbLJv+tvpBimTR@mail.gmail.com>
In-Reply-To: <AANLkTimsf=bsbJfJPKB_WgZjDGpR0GRbLJv+tvpBimTR@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-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, 03 Jan 2011 17:03:39 -0000
> -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: 29 December 2010 18:52 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 > > Hi folks, > > I am in the process of completing the changes to 4244bis > based on the oodles of comments. In re-reviewing the > comments, I have a few additional responses below [MB2], one > of which I would like feedback on - it's related to the case > where the proxy is adding missing entries when there already > hi-entires in the request. > > Thanks, > Mary. > > > On Wed, Nov 3, 2010 at 4:15 AM, Elwell, John > <john.elwell@siemens-enterprise.com> wrote: > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 02 November 2010 19:25 > > To: Elwell, John > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > draft-ietf-sipcore-rfc4244bis-02 > > > > Hi John, > > > > Responses inline below [MB]. I will skip the ones > that I replied to > > in the other response [MB]. > > > > Thanks, > > Mary. > > > > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John > > <john.elwell@siemens-enterprise.com> wrote: > > > Despite the effort that has gone into addressing comments > > raised by people on -01, I still find -02 hard to understand > > in places. I have not had time to review the whole document, > > but here are some comments up to section 7. Just as I > > finished writing this I saw Mary's response to my comments on > > -01, which I will respond to tomorrow. Apologies for any > > overlap between the two. > > > > > > > > > > > 27. Section 6.1.1: > > > "The proxy MUST include an hi-index attribute > > > with a value of "1"" > > > It says we are inserting an entry, not replacing any > > existing entries. Value "1" will not apply if there is an > > existing entry. > > [MB] Correct. If the prior hop did not include an > hi-entry, then one > > is added. Even if there are already other hi-entries, > there is no way > > to know how many hops might have been missed and > thus, the indexing > > needs to be reset to 1 to reflect such. [/MB] > > [JRE] So this means a downstream entity can receive two > entries with index "1" (possibly with intervening entries 1.1 > etc.), not because of any incorrect behaviour of any of the > nodes concerned, but merely because some intervening nodes > don't support H-I. This was the first time I was aware of > this. We should add some explanation. Personally I would > prefer to continue the indexing rather than reset to "1". > > > > [MB2] After reconsidering this, I agree with you that it > would be better to not reset the index to "1" in cases where > there are already hi-entries, but just not one for the > previous hop However, I think it's important that it is > obvious that there may be a gap. The only way I can think to > do this would be to actually skip a value for the index - > i.e., increment the value at the current level by 2 in the > case where entries are added on behalf of prior hops in this > case. This would flag that one or more intermediaries that > forwarded the request did not support History-Info. This > would also ensure that there are not duplicate values, which > I agree could end up being extremely confusing (and the > original intent was for the indices to be unique, although I > am vaguely recalling this as a 4244 issue that we resolved by > just setting the index to "1" - another broken aspect of 4244). [/MB2] [JRE] I agree that artificially generating a gap would make sense - but I don't have a vested interest in backward compatibility with 4244. John > > <snip/> > > > > 36. "MUST forward captured History-Info in subsequent, > > > provisional, and final responses to the request sent by > > the ultimate > > > UAS (see Section 5.2)" > > > If a response does not contain any captured H-I (because > > the UAS doesn't support it), is there any requirement on the > > proxy to generate it from its own information? > > [MB] A proxy would have added an hi-entry for the UAS > if it follows > > the normative procedures in this document. But, there > is no way for > > the proxy to generate any additional hi-entries (in > cases where the > > UAS internally retargets or B2BUA case). [/MB] > > [JRE] Understood. However, let me give you an example. > A proxy receives a request with entries 1 and 1.1, and > forwards it thereby adding 1.1.1. Suppose the next entity is > the UAS and the UAS supports H-I. The UAS will capture 1, 1.1 > and 1.1.1 in the returned response, so therefore the proxy > forwards 1, 1.1 and 1.1.1 when it forwards the response. > That's fine. However, if the UAS does not support H-I, the > response will contain no entries. In this case, the proxy > will be aware of entries 1, 1.1 and 1.2 and could add them > when forwarding the response. This assumes a certain amount > of state be held at the proxy, but no more than is required > for forking, for example. > Perhaps I have misinterpreted the word "captured" in > the cited text - I had assumed you meant captured in the > received response, but of course it might mean captured by > the proxy from the time it forwarded the request. It > certainly needs some clarification. > > > [MB2] Agreed - the intent was that the proxy does keep track > of the hi-entries and does include those in the subsequent > response even in the case of a UAS that does not support > History-Info. [/MB2] > > > <snip/> > > > > > > > 41. Section 7.1.3, item 6: > > > "For example, if > > > a procesing entity received failure responses for > > forks 1.1.1 and > > > 1.1.2, it would return both the 1.1.1 and > 1.1.2 entries to the > > > entity that generated the hi-entry with index of 1." > > > I can't figure this out - shouldn't "index of 1" be > "index of 1.1"? > > [MB] No. The processing entity in that sentence has > the index of 1.1. > > The processing entity is the subject of that sentence > and "it" returns > > the response to the entity that would have added the > hi-entry with > > index of 1.[/MB] > > [JRE] I still can't figure this out. A proxy receives a > request with entries 1 and 1.1. It creates two branches, > 1.1.1 and 1.1.2. Both fail, so when the proxy sends a > response back, it will include entries 1.1.1 and 1.1.2. That > response is sent to the entity that generated 1.1. > > > [MB2] Yep. I was thinking in terms of the entity that is > associated with the hi-entry with index of 1.1. [/MB2] > > > > <snip/> > > <snip> > >
- [sipcore] Comments on draft-ietf-sipcore-rfc4244b… Elwell, John
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Mary Barnes
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Elwell, John
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… DRAGE, Keith (Keith)
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Paul Kyzivat
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Mary Barnes
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Hadriel Kaplan
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Paul Kyzivat
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Paul Kyzivat
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Mary Barnes
- Re: [sipcore] Reason as a parameter rather than a… Elwell, John
- Re: [sipcore] Reason as a parameter rather than a… Shida Schubert
- Re: [sipcore] Reason as a parameter rather than a… R.Jesske
- Re: [sipcore] Reason as a parameter rather than a… Hadriel Kaplan
- Re: [sipcore] Reason as a parameter rather than a… R.Jesske
- Re: [sipcore] Reason as a parameter rather than a… marianne.mohali
- Re: [sipcore] Reason as a parameter rather than a… R.Jesske
- Re: [sipcore] Reason as a parameter rather than a… Shida Schubert
- Re: [sipcore] Reason as a parameter rather than a… Worley, Dale R (Dale)
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Mary Barnes
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Elwell, John
- Re: [sipcore] Comments on draft-ietf-sipcore-rfc4… Mary Barnes