Subject: Re: [RAI] session-id (WAS: Minutes of 3GPP - IETF telco on the 19th of October)

From: <[email-masked]>
Date: Mon, 1 Nov 2010 12:04:39 +0100

Hi,

Hadriel said: "It's not the be-all-end-all final solution for world hunger.  It's just one header.  It's one tool in a bag of tools."

Most of the arguments seem to be in the area of what the draft does NOT to do. If the restricted scope is known and acceptable for the originators, where's the problem?

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hadriel Kaplan
Sent: 28 October, 2010 08:22
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

If you don't want to implement support for passing through a session-id header, then don't.  No one's making you.  We're talking about an RFC, not a Biblical commandment.  There are a boat-load of RFC's no one's ever implemented.

It's not the be-all-end-all final solution for world hunger.  It's just one header.  It's one tool in a bag of tools.

If some vendors support passing a session-id header and other's don't, it won't be as useful as it could have been.  My customers tell me such a header would help them.  Maybe I'm naive, but I would think when customers tell their vendors to do something, the vendors generally try to do it.  Especially if it's trivial to implement and helps the vendors *themselves* with supporting the customers in TAC.  So my belief is the market will decide if session-id succeeds - customers will either want it, or not.  Meanwhile, all it takes to find out is to publish a fairly simple RFC.  If it fails, we've wasted some IETF people's time and an RFC number.  If it succeeds, we've made SIP a little bit easier to manage, for all of us.

SIPCLF is orthogonal to session-id, really. In fact, one would hope the session-id would be recorded in SIPCLF as well.  Had we published session-id when it was initially proposed, it would have been available in time for SIPCLF to make a mandatory field.

As for SIPREC, that's exactly the problem: I already *know* of cases where we'll need to remove whatever correlation id siprec ends up using.  Overloading this header for such things is just bound to reduce its troubleshooting value, because we'll need to remove or change it.  But that's *OK* - we have no shortage of header names available in SIP ABNF.  They can go define whatever new header-name they'd like, with another value.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2010 09:41:03 -0400

For me its a matter of whether a spec so narrowly defined is worth the 
trouble of implementing, and wasting message size on. Its particularly 
significant in this case because its not very useful unless it is nearly 
ubiquitous. In that sense it differs from other extensions that only 
cost when used. A broader set of uses increases the justification for 
implementing it.

	Thanks,
	Paul

On 11/1/2010 7:04 AM, [email-masked] wrote:
> Hi,
> Hadriel said: "It's not the be-all-end-all final solution for world
> hunger. It's just one header. It's one tool in a bag of tools."
> Most of the arguments seem to be in the area of what the draft does NOT
> to do. If the restricted scope is known and acceptable for the
> originators, where's the problem?
>
> BR,
> Hannu Hietalahti
> 3GPP TSG CT Chairman
> tel: +358 40 5021724
>
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *ext Hadriel Kaplan
>     *Sent:* 28 October, 2010 08:22
>     *To:* Parthasarathi R (partr)
>     *Cc:* [email-masked]
>     *Subject:* Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October
>
>
>     If you don't want to implement support for passing through a
>     session-id header, then don't. No one's making you. We're talking
>     about an RFC, not a Biblical commandment. There are a boat-load of
>     RFC's no one's ever implemented.
>
>     It's not the be-all-end-all final solution for world hunger. It's
>     just one header. It's one tool in a bag of tools.
>
>     If some vendors support passing a session-id header and other's
>     don't, it won't be as useful as it could have been. My customers
>     tell me such a header would help them. Maybe I'm naive, but I would
>     think when customers tell their vendors to do something, the vendors
>     generally try to do it. Especially if it's trivial to implement and
>     helps the vendors *themselves* with supporting the customers in TAC.
>     So my belief is the market will decide if session-id succeeds -
>     customers will either want it, or not. Meanwhile, all it takes to
>     find out is to publish a fairly simple RFC. If it fails, we've
>     wasted some IETF people's time and an RFC number. If it succeeds,
>     we've made SIP a little bit easier to manage, for all of us.
>
>     SIPCLF is orthogonal to session-id, really. In fact, one would hope
>     the session-id would be recorded in SIPCLF as well. Had we published
>     session-id when it was initially proposed, it would have been
>     available in time for SIPCLF to make a mandatory field.
>
>     As for SIPREC, that's exactly the problem: I already *know* of cases
>     where we'll need to remove whatever correlation id siprec ends up
>     using. Overloading this header for such things is just bound to
>     reduce its troubleshooting value, because we'll need to remove or
>     change it. But that's *OK* - we have no shortage of header names
>     available in SIP ABNF. They can go define whatever new header-name
>     they'd like, with another value.
>
>     -hadriel
>
>
>
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai