Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

From: <[email-masked]>
Date: Wed, 7 Jan 2015 11:37:02 +0100

Yes I also think we should keep the current 3GPP scope. And as Christer said we did discuss it in DISPATCH, and that was the outcome.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: dispatch [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Freitag, 19. Dezember 2014 21:11
An: Paul Kyzivat; [email-masked]
Betreff: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

Hi,

....

>>>> To resolve this issue, I suggest removing the text that occurs in 
>>>> several places saying that this is applicable only to 3gpp 
>>>> networks, and add a short sentence reminding the reader that 
>>>> RFC3261 expects new URI parameters to be standardized and defines 
>>>> how unknown URI parameters are handled.
>>>
>>> My problem with this is that IMO the semantics of traffic legs, and 
>>> the particular types of traffic legs, is not defined in a way that 
>>> makes any sense outside of an IMS network.
>>
>> I understand that, but, really, so what? This does no harm to non-IMS 
>> networks.
>> If other relations of hops make sense in some other deployment, they 
>> can use the value extension point to say something sensical for that 
>> deployment.
>> I think what you're looking it is a version of "the things that know 
>> and care about this thing are the things that know and care about this thing."
>
> My concern is that this smells like a do-what-I-mean thing - syntax without semantics.

Just to clarify, as I've also said before, in the 3GPP usage there is absolutely no do-what-I-mean about iotl. The starting entity of a traffic leg typically has no idea, and makes no assumptions, about what/if the ending entity (and/or any mid-traffic leg entity) is going to do with the information - especially if the traffic leg spans multiple operators.

> I especially could not understand when it would make sense to define 
> new traffic leg types. Could the new types coexist in the same call, 
> or the same network, with the existing ones? Or must you define new
> *collections* of traffic leg types that work with one another?
>
>The only reason I can think of is some completely new call model is defined. You need to, for the environment where you use iotl, define each traffic leg for that environment.
>
> ISTM that traffic leg transitions ought to constitute a sort of state machine. But Christer didn't think so.
>
> I can live with this state of affairs while the scope is limited to IMS. 
> But if it is opened up then I think those issues need to be sorted out. 
> But nobody outside the IMS community could see a use for this, so there was no interest in doing to work to define it more generally.

Personally I also think we should keep the current 3GPP scope. We did discuss it in DISPATCH, and that was the outcome.

Regards,

Christer

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Robert Sparks <[email-masked]>
Date: Wed, 07 Jan 2015 08:55:42 -0600

Repeating something I said on a different thread:

I'm not ok with the 3gpp scope as written.
It makes no sense to claim this is a proposed standard for the Internet 
and say "it's not defined for any part of the Internet that's not 3gpp".
I would expect most of the IESG to have the same reaction.

It would be different, and less objectionable, to say "it's not likely 
to be particularly useful anywhere but in a 3GPP network".

I still think you should just remove last paragraph of the introduction, 
and section 2 altogether.

We have lots of extensions that only make sense to the devices that 
implement the extension. Everything else ignores it. That's what the 
extension in this document is doing.

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Jan 2015 15:01:18 +0000

Hi,

I have no problem to do as you suggest, if that's the way to move the draft forward.

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 7. tammikuuta 2015 16:56
To: [email-masked]
Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

I'm not ok with the 3gpp scope as written.
It makes no sense to claim this is a proposed standard for the Internet and say "it's not defined for any part of the Internet that's not 3gpp".
I would expect most of the IESG to have the same reaction.

It would be different, and less objectionable, to say "it's not likely to be particularly useful anywhere but in a 3GPP network".

I still think you should just remove last paragraph of the introduction, and section 2 altogether.

We have lots of extensions that only make sense to the devices that implement the extension. Everything else ignores it. That's what the extension in this document is doing.

RjS

On 1/7/15 4:37 AM, [email-masked] wrote:
>>> I understand that, but, really, so what? This does no harm to 
>>> non-IMS networks.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 07 Jan 2015 09:04:10 -0600

Right.

I think you need some careful guidance from your sponsoring AD here.

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jan 2015 11:41:20 -0500

> to be particularly useful anywhere but in a 3GPP network".

That would work for me. I certainly have no problem with somebody 
finding a use for this outside of 3gpp.

The point is that there has been no effort to define it in a way that is 
likely to be useful more broadly. It *might* be possible to do that. I 
tried to understand the semantics enough to see how to do that, but 
without success. I think it would require creating a framework that 
formalizes the notion of "legs" in sip signaling. But the people who 
want this didn't seem to want to expend the effort on that, and I didn't 
sense any interest in doing so outside the 3gpp community.

	Thanks,
	Paul

>> Yes I also think we should keep the current 3GPP scope. And as
>> Christer said we did discuss it in DISPATCH, and that was the outcome.
>>
>> Best Regards
>>
>> Roland
>>
>> Just to clarify, as I've also said before, in the 3GPP usage there is
>> absolutely no do-what-I-mean about iotl. The starting entity of a
>> traffic leg typically has no idea, and makes no assumptions, about
>> what/if the ending entity (and/or any mid-traffic leg entity) is going
>> to do with the information - especially if the traffic leg spans
>> multiple operators.
>>
>>> The only reason I can think of is some completely new call model is
>>> defined. You need to, for the environment where you use iotl, define
>>> each traffic leg for that environment.
>>>
>>> But nobody outside the IMS community could see a use for this, so
>>> there was no interest in doing to work to define it more generally.
>> Personally I also think we should keep the current 3GPP scope. We did
>> discuss it in DISPATCH, and that was the outcome.
>>
>> Regards,
>>
>> Christer
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Jan 2015 08:40:05 +0000

Hi,

So, I suggest to replace:

	"The SIP URI 'iotl' parameter defined in this document is only applicable to 
	3GPP networks. The usage of the parameter within other types of networks is 
	undefined."

...with:

	"The SIP URI 'iotl' parameter defined in this document it's not likely to be 
	particularly useful anywhere but in a 3GPP network."

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 07 January 2015 18:41
To: [email-masked]
Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

On 1/7/15 9:55 AM, Robert Sparks wrote:
> It makes no sense to claim this is a proposed standard for the 
> Internet and say "it's not defined for any part of the Internet that's not 3gpp".

That would work for me. I certainly have no problem with somebody finding a use for this outside of 3gpp.

The point is that there has been no effort to define it in a way that is likely to be useful more broadly. It *might* be possible to do that. I tried to understand the semantics enough to see how to do that, but without success. I think it would require creating a framework that formalizes the notion of "legs" in sip signaling. But the people who want this didn't seem to want to expend the effort on that, and I didn't sense any interest in doing so outside the 3gpp community.

	Thanks,
	Paul

>>>>> My problem with this is that IMO the semantics of traffic legs, 
>>>>> and the particular types of traffic legs, is not defined in a way 
>>>>> that makes any sense outside of an IMS network.
>>>> If other relations of hops make sense in some other deployment, 
>>>> they can use the value extension point to say something sensical 
>>>> for that deployment.
>>>> I think what you're looking it is a version of "the things that 
>>>> know and care about this thing are the things that know and care 
>>>> about this thing."
>> what/if the ending entity (and/or any mid-traffic leg entity) is 
>> going to do with the information - especially if the traffic leg 
>> spans multiple operators.
>>
>>> ISTM that traffic leg transitions ought to constitute a sort of 
>>> state machine. But Christer didn't think so.
>>>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 8 Jan 2015 14:19:07 +0000

Christer,

It doesn't seem useful to put language in a specification that may be
disproved in time.
Also, positive language would be better.

Why not just say:

	"The SIP URI 'iotl' parameter defined in this document has known
uses in 3GPP networks.
	Usage in other networks is also possible."

If other networks never define a usage, then the statement is still true.
If other networks do define a usage, then the statement is still true.

Mike

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Christer
Holmberg
Sent: Thursday, January 08, 2015 3:40 AM
To: Paul Kyzivat; [email-masked]; Robert Sparks; Richard Barnes
([email-masked])
Subject: Re: [dispatch] Gen-art LC review:
draft-holmerg-dispatch-iotl-03.txt

Hi,

	"The SIP URI 'iotl' parameter defined in this document is only
applicable to 
	3GPP networks. The usage of the parameter within other types of
networks is 
	undefined."

...with:

	"The SIP URI 'iotl' parameter defined in this document it's not
likely to be 
	particularly useful anywhere but in a 3GPP network."

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 07 January 2015 18:41
To: [email-masked]
Subject: Re: [dispatch] Gen-art LC review:
draft-holmerg-dispatch-iotl-03.txt

> to be particularly useful anywhere but in a 3GPP network".

That would work for me. I certainly have no problem with somebody finding a
use for this outside of 3gpp.

The point is that there has been no effort to define it in a way that is
likely to be useful more broadly. It *might* be possible to do that. I tried
to understand the semantics enough to see how to do that, but without
success. I think it would require creating a framework that formalizes the
notion of "legs" in sip signaling. But the people who want this didn't seem
to want to expend the effort on that, and I didn't sense any interest in
doing so outside the 3gpp community.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Jan 2015 14:27:38 +0000

Hi Michael,

Personally I am ok also with the text you suggest :)

Regards,

Christer

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: 8. tammikuuta 2015 16:19
To: Christer Holmberg; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [dispatch] Gen-art LC review:
draft-holmerg-dispatch-iotl-03.txt

Christer,

Why not just say:

Mike

-----Original Message-----

Hi,

...with:

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 07 January 2015 18:41
To: [email-masked]
Subject: Re: [dispatch] Gen-art LC review:

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 8 Jan 2015 17:52:41 +0100

+1

Roland

-----Ursprüngliche Nachricht-----
Von: dispatch [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 8. Januar 2015 15:28
An: Michael Hammer; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

Hi Michael,

Regards,

Christer

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: 8. tammikuuta 2015 16:19
To: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dispatch] Gen-art LC review:

Christer,

It doesn't seem useful to put language in a specification that may be disproved in time.
Also, positive language would be better.

Why not just say:

	"The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks.
	Usage in other networks is also possible."

Mike

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, January 08, 2015 3:40 AM
To: Paul Kyzivat; [email-masked]; Robert Sparks; Richard Barnes
([email-masked])

Hi,

...with:

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 07 January 2015 18:41
To: [email-masked]
Subject: Re: [dispatch] Gen-art LC review:

On 1/7/15 9:55 AM, Robert Sparks wrote:
> Internet and say "it's not defined for any part of the Internet that's 
> not
3gpp".

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Jan 2015 17:51:27 +0000

Robert/Paul, are you ok with Michael's suggested change to the text?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 08 January 2015 18:53
To: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: AW: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

+1

Roland

-----Ursprüngliche Nachricht-----
Von: dispatch [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 8. Januar 2015 15:28
An: Michael Hammer; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

Hi Michael,

Regards,

Christer

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: 8. tammikuuta 2015 16:19
To: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dispatch] Gen-art LC review:

Christer,

Why not just say:

Mike

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, January 08, 2015 3:40 AM
To: Paul Kyzivat; [email-masked]; Robert Sparks; Richard Barnes
([email-masked])

Hi,

...with:

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 07 January 2015 18:41
To: [email-masked]
Subject: Re: [dispatch] Gen-art LC review:

3gpp".

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Jan 2015 13:30:30 -0600

I am

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jan 2015 11:35:54 -0500

> Robert/Paul, are you ok with Michael's suggested change to the text?

yes

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Jan 2015 17:24:41 +0000

Great! Thanks!

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎09/‎01/‎2015 18:51
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt

yes