Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Aug 2010 15:35:18 -0400

Hadriel,

After thinking further about this...

I think we could *start* with one very common use case - a linear chain 
of dialogs connected by B2BUAs. There are multiple uses for an 
identifier linking all of those. Certainly we can call out the use in 
troubleshooting *specific* problems with such a case.

I think it would be useful to have that in the charter. But the charter 
should be more open ended than that. Specifically, I think it should 
call for the WG to identify other use cases that the resulting mechanism 
will address. Two categories of use cases:
- other applications besides "troubleshooting" with the same id
   is useful. (E.g. recording)

- other dialog relationships that should also get a common id,
   such as the transfer cases.

One constraint would be that the mechanism uniquely define the mechanism 
for deciding when two dialogs get the same id and when they do not. 
Another is that the basic case identified in the charter be included.

So the things that would happen in the WG would be:

- gather use cases
- for each use case, identify the dialog correlation algorithm
   required
- identify any incompatible use cases
- exclude incompatible use cases from consideration until
   those that remain have compatible dialog correlation requirements
- specify a mechanism that meets all the remaining use cases

	Thanks,
	Paul

Hadriel Kaplan wrote:
> Howdy,
> One of the objections to the currently proposed SIPSCOTCH charter is on how one knows whether to use the same session-id or not - i.e., what defines the same higher layer session.  
> 
> In particular, the following paragraph of the charter:
> "The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice.  For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under any conditions where correlation might aid troubleshooting, by identifying them as belonging to the same higher-level session.  Any solution documents from this working group may expand or constrain the scope of their mechanism's correlation, if the working group so decides."
> 
> This objection was also raised on the DISPATCH mailing list thread starting here:
> http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html
> 
> 
> I believe the available options to handle this issue are:
> 
> 1) Defer it to the new WG's solution doc to specify.
> 
> 2) Try to articulate rules in the charter for when two messages/dialogs are part of the same "session".  This was actually attempted in a previous incarnation of the charter, in an email thread starting here:
> http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html
> 
> 3) Instead of defining "rules", try to enumerate examples/use-cases which are and are-not in scope to be the same session.
> 
> Any comments/preferences?
> 
> -hadriel
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>