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

[Mary Barnes <[e-mail]>]

Backwards compatibility is a potential downside.  However, I think we can
debate whether it would cause problems since RFC 4244 didn't really cover
the case where there were already hi-entries, but just not one for the
Request URI in the incoming request.   The resetting to "1" is broken in the
current version of 4244bis, since it really should state that the index at
the current level is reset to 1. - i.e., if you have hi-entries 1.1.1 and
1.1.2, but there is no hi-entry for the incoming request, that entry should
be added with an index of 1.1.1. However, I'm suggesting that instead we
skip the index value of 1.1.3, so that it's obvious that one or more
intermediaries didn't support History-Info, thus avoiding duplicate entries,
which could introduce problems.

Thanks,
Mary.

On Mon, Jan 3, 2011 at 11:03 AM, Elwell, John <
[e-mail]> wrote:

>
>
> > -----Original Message-----
> > From: Mary Barnes [mailto:[e-mail]]
> > Sent: 29 December 2010 18:52
> > To: Elwell, John
> > Cc: [e-mail]
> > 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
> > <[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]
> [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>
> >
> >
>