Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02

[Mary Barnes <[e-mail]>]

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 <
[e-mail]> wrote:

>
>
> > -----Original Message-----
> > From: Mary Barnes [mailto:[e-mail]]
> > Sent: 02 November 2010 19:25
> > To: Elwell, John
> > Cc: [e-mail]
> > 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
> > <[e-mail]> 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>
>