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