Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 29 December 2010 18: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 B40C33A6855 for <sipcore@core3.amsl.com>; Wed, 29 Dec 2010 10:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.248
X-Spam-Level:
X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 WxBuUQhLI8H4 for <sipcore@core3.amsl.com>; Wed, 29 Dec 2010 10:50:00 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id BD2A63A67D6 for <sipcore@ietf.org>; Wed, 29 Dec 2010 10:49:59 -0800 (PST)
Received: by yxt33 with SMTP id 33so4776893yxt.31 for <sipcore@ietf.org>; Wed, 29 Dec 2010 10:52:05 -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; bh=3dsOc29YkMwmf5D9KHHH3/BGSHcwrz/BdBhst/E3zJA=; b=W6AQ4I7EpkgsXvafscs7+YWFvcu1+nLqVak2/xT07YoR+sLV9McE1XIGl8JbLU6EGk SIBUDtVkkswJAXm+8vdNj8H16nvBDD1lHz7gvdsb1n1BwJ2RUdnSq3oSz6KeBa1ta8iO z/RLMfhml8alsF/1Kx68Hu1WTxtkwpk7Na/UA=
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; b=WuMYvditfKtQMzIzh/iI8jTbDJO81P1pQyKKGDsTxyQ44FTp+7n22jglxptwNqUlO9 o9MOS/+IjNmM2fGsCQp6G5e3h17T6D7SZDa3jlGlReQ/qUoxV8KtFpkCxllAsIOkR/gD VLAUKBTRnLzFdPFd/TLlxzBnFN40j6T8/8TTM=
MIME-Version: 1.0
Received: by 10.236.109.168 with SMTP id s28mr27283517yhg.74.1293648725030; Wed, 29 Dec 2010 10:52:05 -0800 (PST)
Received: by 10.236.95.35 with HTTP; Wed, 29 Dec 2010 10:52:04 -0800 (PST)
In-Reply-To: <A444A0F8084434499206E78C106220CA0235546979@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA023554628B@MCHP058A.global-ad.net> <AANLkTi=B1qL2D-U85mMp3Dft2kvmuB9Sv5EAQ9vQBtot@mail.gmail.com> <A444A0F8084434499206E78C106220CA0235546979@MCHP058A.global-ad.net>
Date: Wed, 29 Dec 2010 12:52:04 -0600
Message-ID: <AANLkTimsf=bsbJfJPKB_WgZjDGpR0GRbLJv+tvpBimTR@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
Content-Type: multipart/alternative; boundary="0023547c8b43b839960498911011"
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: Wed, 29 Dec 2010 18:50:06 -0000
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] > <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