Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

[Brett Tate <[e-mail]>]

Hi,

I'm glad to hear others within the working group agree that the draft (with
or without Paul Giralt's proposed changes) provides no way to avoid
intermediaries from sending inaccurate Session-ID values when generating
related requests and responses.  Similarly, the draft provides no way to
avoid endpoints from sending inaccurate remote uuid values when generating
requests and responses (although Paul Giralt's proposed change provides some
consistency concerning responses).

The inability of intermediaries to avoid sending inaccurate Session-ID
values when generating related requests and responses has been why I
occasionally ask for the limitation to be explicitly mentioned within the
draft and why I occasionally raise issues with the draft's MUST statements.

The draft currently allows intermediaries (excluding maybe any which might
be required to track the uuids) to not add Session-ID when generating
(instead of relaying) requests and responses.  This is because the draft
prefers no Session-ID instead of one which might cause a non-desired uuid
change.  I'm not sure if Paul Giralt intends to change this aspect of the
draft.

I'm not sure if the current limitations of the draft (or proposed change)
will meet the expectations of the working group or 3GPP.  However, I guess
that the draft will continue to evolve until it is abandoned or deemed good
enough.

Thanks,
Brett

> -----Original Message-----
> From: insipid [mailto:[e-mail]] On Behalf Of Paul Giralt
> (pgiralt)
> Sent: Tuesday, January 05, 2016 5:22 PM
> To: Paul Kyzivat
> Cc: [e-mail]
> Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and
> questions
>
> I don’t think it’s all doom and gloom. I think in the majority of cases
> the
> Session-ID will be consistent end-to-end. It is these corner case error
> conditions that lead to ambiguity as to the right thing to do which is why
> I’d prefer expected behavior be documented as clearly as possible, even if
> it
> may knowingly result in a situation where all devices don’t necessarily
> agree
> on the Session-ID for some period of time in the call. I think there will
> still be enough information in the message exchange that any
> post-processing
> tools being used to diagnose a problem will have enough information to
> correlate calls even in such scenarios.
>
> -Paul
>
>
> > On Jan 5, 2016, at 2:51 PM, Paul Kyzivat <[e-mail]> wrote:
> >
> > This discussion is reinforcing my belief that this mechanism is a mess -
> that the chance is slim to none of getting consistent results in all the
> connected devices.
> >