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

From: Richard Barnes <[email-masked]>
Date: Mon, 2 Feb 2015 10:07:34 -0500

Hey all,

Thanks for a productive discussion.  I appreciate Robert's concerns, and I
think the text in -04 (as agreed below) strikes the right balance between
defining something that is in principle usable on the Internet, while at
the same time letting the reader know that it is unlikely in practice to be
used outside of 3GPP networks.

I have added this document to this week's telechat, with the following note
in the ballot:
"""
In response to IETF LC feedback from Robert Sparks, the scoping language
was adjusted to clarify that the only current usage of this parameter is in
3GPP
networks, but it is also possible to use it in other deployments where its
semantics
make sense.  The text change was discussed and agreed on the DISPATCH
mailing list.
"""

Thanks,
--Richard

On Fri, Jan 9, 2015 at 12:24 PM, Christer Holmberg <
[email-masked]> wrote:

>   Great! Thanks!
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
>  ------------------------------
> From: Paul Kyzivat <[email-masked]>
> Sent: ‎09/‎01/‎2015 18:51
> To: Christer Holmberg <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>
> Subject: Re: [dispatch] Gen-art LC review:
> draft-holmerg-dispatch-iotl-03.txt
>
>   On 1/8/15 12:51 PM, Christer Holmberg wrote:
> > Robert/Paul, are you ok with Michael's suggested change to the text?
>
> yes
>
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]
> <[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]
> <[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,
> >
> > Personally I am ok also with the text you suggest :)
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: Michael Hammer [mailto:[email-masked]
> <[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,
> >
> > 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]
> <[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,
> >
> > 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]
> <[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:
> >> 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".
> >
> > 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
> >
> >> 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:
> >>> 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]
> <[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
> >>>
> >>> _______________________________________________
> >>> dispatch mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/dispatch
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >>
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>
>