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, 3 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>
> 
>