From nobody Tue Jan 6 00:14:46 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6A31A911F for ; Tue, 6 Jan 2015 00:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2mZH5aKZxo2 for ; Tue, 6 Jan 2015 00:14:39 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2146B1A9115 for ; Tue, 6 Jan 2015 00:14:38 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail31.telekom.de with ESMTP; 06 Jan 2015 09:14:36 +0100 X-IronPort-AV: E=Sophos;i="5.07,706,1413237600"; d="scan'208";a="192815519" Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 06 Jan 2015 09:14:36 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 6 Jan 2015 09:14:36 +0100 From: To: , Date: Tue, 6 Jan 2015 09:14:33 +0100 Thread-Topic: Draft minutes from IETF 91- Issue "forking correlation" Thread-Index: AQHQG86lxK89e8eTdEO2geXh8hYjQpyxU/0A Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E5F8001249@HE113667.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/uhQp9A58ult3DUlylL76aLXsdQE Subject: Re: [dispatch] Draft minutes from IETF 91- Issue "forking correlation" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:14:43 -0000 Hi, thank you for the minutes. I would like to start the discussion on the issues and would like to dig al= little bit more for the reasoning. Due to discussions since the last meeting I had with a couple of peoples an= d also new use cases appearing it showed that the shown use cases does not = only solve miss-behavior of UA's (or Gateways) not understanding forking, i= .e. multiples responses received due to forking. We have also service behavior where a B2BUA has to correlate multiples resp= onses received due to forked INVITES and other scenarios like call forwardi= ng. So I would like to discuss the problem statement and what is needed to sati= sfy the people to accept the work on this issue within IETF. So below I have rewritten the problem statement. I would like to know if pe= ople would be willing to work on this issue based on this statement. Or is = there still something missing? So I start with the evaluation part where I look in all the RFCs discussing= forking, multiples early dialogs/session and the related use cases. Here is a new proposal for the problem statement: 1. Problem Statement Within RFC3261 the handling of multiples early responses received from diff= erent UAS for one sent INVITE is described as basis feature. Such behavior = results usually in case of forking or also when an INVITE is forwarded to a= nother target. =20 The forking feature described in RFC3261 [RFC3261] allows to spread the INV= ITE request towards multiples registered UA's for one identity but is prese= nt at different locations.=20 A forwarding as described in RFC 5359 [RFC 5359 ] of a SIP Dialog may res= ult in multiples early dialogs(181 and 180 with different to tags). A 181 r= esponse may also initiate an early dialog. =20 There are scenarios within the scope of this document where multiple respon= ses received should be multiplexed to a single dialog to avoid complexity o= r miss behavior for the originating network/UAC: 1. When a SIP entity (B2BUA) provides a service within the SIP path where m= ultiples early responses received must be multiplexed into a single dialog.= =20 2. Providing interconnecting between different networks with different beha= vior where a the originating network implementations do not wish, have rest= rictions or may not able handle multiples responses while the destination s= till deliver multiples responses or early dialogs. 3. Providing interconnection where the terminating service provider will ha= ve or must have control what kind of early dialog information should be pro= vided to the originating network based on bilateral agreement, service prov= ider policy or regulatory policy.=20 4. Service provider providing the forking feature or interconnecting to net= works providing multiples early dialogs to INVITES would like to increase t= he reliability of the network in increasing successful calls even if UAC do= not really support the correct handling of multiples early dialogs. Please= Note that this scenario is assuming that old or faulty implementations are= existing. This is real life and service provider are already using healing= functions within B2BUA but it is clear that the correct way is to replace = or correct faulty implementations of SIP. =20 Scenario 1: A service example may be a directory service providing a early dialog/sessi= on with a Interactive Voice Response (IVR) system for requesting a destinat= ion number where the user will be automatically forwarded to a identity whe= re a couple of UAS are registered within the SIP network. Thus the INVITE w= ill be forked and result in multiples responses to the INVITE sent by the S= IP entity providing the service.=20 It could be also a normal call forwarding scenario providing a short announ= cement to the UAC indicating the forwarding. Due to the fact that a early session was already provided by the service it= needs an mapping of the multiples responses towards the UAC to provide the= ringing state, tone or provide further announcements. =20 Scenario 2: Due to the fact that the world of SIP networks is steadily growing and SIP = networks based on IETF RFC 3261 are existing with different flavors like b= ased on pure SIP, 3GPP IMS or ETSI TISPAN NGN and many others. Now connecti= ng these networks which may be operated by different service provides may r= esult in complexity due to signaling, charging or even worse in faulty case= s.=20 Providing voice services via SIP over restricted access capabilities may ne= ed restrictions with regard to numbers of early sessions provided in backwa= rd direction or signaling load. Other service providers do only allow single dialog over interconnection to= avoid charging complexity with too many early sessions or early dialogs. Also equipment and UAC not understanding or misbehaving when receiving mult= iples responses may be in focus when restricting the interconnection use ca= se to a single early dialog. Scenario 3: Within this scenario the terminating service provider apply specific policy= . This may be either in guaranteeing his customers to provide forking to fo= r all entities registered for a specific identity, or allow only specific a= nnouncements (e.g in a specific language) passed through or to ensure the b= ilateral agreements with other operators where only single dialog is mandat= ed. Also in forwarding scenarios some originating networks do not wish to h= ave a forwarding indication (i.e. 181) or early session in backward directi= on. Scenario 4: As already stated this is a real life scenario but seen from implementation= point of view the wrong approach. The real solution is to replace or corre= ct faulty implementations of SIP.=20 But nevertheless the problem existing is that feature forking is not really= supported by all UAC in that way that a connection between UAC and one of = the UAS will succeed in a successful communication even one of the UAS send= s a 200 OK for the INVITE. This apply also to networks having B2BUA's (e.g= . PSTN interworking Gateways or Session Border Controller) in the path whi= ch should understand multiples responses and handle it correctly. Providing solutions for scenarios 1-3 will also provide a possibility for s= ervice provider to support scenario 4. This document evaluates the existing forking mechanism described in RFC 326= 1 [RFC3261] and further RFC's extending SIP for early dialog handling, reso= urce handling and reliability of provisional responses. Also directives and SIP extensions will be investigated where forking or fr= aud based on forking may be avoided. It will result in different use cases and solutions for the above mentioned= scenarios where multiples responses are received by B2BUA and may be multi= plexed to a single dialog. This document describes how a correlation/multiplexing for multiples early = dialogs and other received Responses can done within a B2BUA. The possible= roles of a B2BUA is described in the taxonomy document RFC7029 [RFC7029] T= he role of the B2BUA is a Signaling/Media Plane B2BUA Role. Thus many poss= ible use cases which will be possible looking on the used features are cons= idered in this document.=20 It is NOT within the scope of this document to deploy new SIP procedures bu= t it is within the scope to use existing SIP procedures to describe the pro= per multiplexing. Thank you and Best regards Roland -----Urspr=FCngliche Nachricht----- Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Cullen Jenn= ings (fluffy) Gesendet: Freitag, 19. Dezember 2014 21:59 An: IETF Dispatch Betreff: [dispatch] Draft minutes from IETF 91 Can be found at=20 http://www.ietf.org/proceedings/91/minutes/minutes-91-dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jan 7 02:37:13 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328A91A1BC3 for ; Wed, 7 Jan 2015 02:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9XuefbNAcUX for ; Wed, 7 Jan 2015 02:37:08 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47521A8990 for ; Wed, 7 Jan 2015 02:37:07 -0800 (PST) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP; 07 Jan 2015 11:37:04 +0100 X-IronPort-AV: E=Sophos;i="5.07,713,1413237600"; d="scan'208";a="736433584" Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jan 2015 11:37:03 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 7 Jan 2015 11:37:03 +0100 From: To: , , Date: Wed, 7 Jan 2015 11:37:02 +0100 Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdA= Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/7RPjwRcna-hEIMNuAyani42oC3I Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 10:37:11 -0000 Yes I also think we should keep the current 3GPP scope. And as Christer sai= d we did discuss it in DISPATCH, and that was the outcome. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Ho= lmberg Gesendet: Freitag, 19. Dezember 2014 21:11 An: Paul Kyzivat; dispatch@ietf.org Betreff: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt Hi, .... >>>> To resolve this issue, I suggest removing the text that occurs in=20 >>>> several places saying that this is applicable only to 3gpp=20 >>>> networks, and add a short sentence reminding the reader that=20 >>>> RFC3261 expects new URI parameters to be standardized and defines=20 >>>> how unknown URI parameters are handled. >>> >>> My problem with this is that IMO the semantics of traffic legs, and=20 >>> the particular types of traffic legs, is not defined in a way that=20 >>> makes any sense outside of an IMS network. >> >> I understand that, but, really, so what? This does no harm to non-IMS=20 >> networks. >> If other relations of hops make sense in some other deployment, they=20 >> can use the value extension point to say something sensical for that=20 >> deployment. >> I think what you're looking it is a version of "the things that know=20 >> and care about this thing are the things that know and care about this t= hing." > > My concern is that this smells like a do-what-I-mean thing - syntax witho= ut semantics. Just to clarify, as I've also said before, in the 3GPP usage there is absol= utely no do-what-I-mean about iotl. The starting entity of a traffic leg ty= pically has no idea, and makes no assumptions, about what/if the ending ent= ity (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=20 > new traffic leg types. Could the new types coexist in the same call,=20 > 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 define= d. 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 mac= hine. But Christer didn't think so. > > I can live with this state of affairs while the scope is limited to IMS.= =20 > But if it is opened up then I think those issues need to be sorted out.=20 > But nobody outside the IMS community could see a use for this, so there w= as no interest in doing to work to define it more generally. Personally I also think we should keep the current 3GPP scope. We did discu= ss it in DISPATCH, and that was the outcome. Regards, Christer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jan 7 06:55:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C461A90C3 for ; Wed, 7 Jan 2015 06:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjtxoQY46OAe for ; Wed, 7 Jan 2015 06:55:48 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098481A90A6 for ; Wed, 7 Jan 2015 06:55:48 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t07Etlbw018079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Jan 2015 08:55:47 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54AD48EE.9040207@nostrum.com> Date: Wed, 07 Jan 2015 08:55:42 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/C6m8ZoGOWAeQRbX7hIm5d3F8gjo Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:55:51 -0000 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 On 1/7/15 4:37 AM, R.Jesske@telekom.de 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:dispatch-bounces@ietf.org] Im Auftrag von Christer Holmberg > Gesendet: Freitag, 19. Dezember 2014 21:11 > An: Paul Kyzivat; dispatch@ietf.org > 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 > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jan 7 07:01:33 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299611A7006 for ; Wed, 7 Jan 2015 07:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB-Q7Ni89u9g for ; Wed, 7 Jan 2015 07:01:23 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550751A8828 for ; Wed, 7 Jan 2015 07:01:22 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-39-54ad4a40bf20 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.79.04076.04A4DA45; Wed, 7 Jan 2015 16:01:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 16:01:19 +0100 From: Christer Holmberg To: Robert Sparks , "dispatch@ietf.org" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdCAADfDAIAAEefg Date: Wed, 7 Jan 2015 15:01:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6241EB@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> In-Reply-To: <54AD48EE.9040207@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja6D19oQg4MnBSyWTlrAanFtTiOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXR+HIla8EH5YpFLzeyNjB2y3YxcnJICJhI TH+0ih3CFpO4cG89WxcjF4eQwBFGiavN+6CcxYwSj9pns3QxcnCwCVhIdP/TBmkQEQiWuNSw iQXEFhbwlZh8fidYiYhAgMT11/UQJVESky/9BithEVCRaNx6nBnE5gUqf913H2r8fiaJ/i2H mEASnALaEp27D4E1MAId9P3UGrA4s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbSeLHhkss EPV6EjemTmGDsLUlli18DbVYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlycm25k pJdalJlcXJyfp5eXWrKJERgnB7f8ttrBePC54yFGAQ5GJR5eg4VrQoRYE8uKK3MPMUpzsCiJ 8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PIjLl7E99lP9j+af//dwxPnM4umN3A 3OnjVPjY/wHfHCWtWKHOiY+5X5gERZcaqjPek6qRmP//8YJtj1YtOdg12VPiZ0PYFU/ryOAY k91bpjG+2lx/pmzf96QP8Wt9Dn28+vlLdPfpO9Nf7k+x2TjzRGnju6p/nkef8+wXMZVulY99 +pBFsCVaiaU4I9FQi7moOBEAs7UVeHQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/LZNpZynW-tPTVSJRc3j0rQlGs-Y Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:01:29 -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:dispatch-bounces@ietf.org] On Behalf Of Robert Spark= s Sent: 7. tammikuuta 2015 16:56 To: dispatch@ietf.org Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt 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 b= e particularly useful anywhere but in a 3GPP network". I still think you should just remove last paragraph of the introduction, an= d section 2 altogether. We have lots of extensions that only make sense to the devices that impleme= nt the extension. Everything else ignores it. That's what the extension in = this document is doing. RjS On 1/7/15 4:37 AM, R.Jesske@telekom.de wrote: > Yes I also think we should keep the current 3GPP scope. And as Christer s= aid we did discuss it in DISPATCH, and that was the outcome. > > Best Regards > > Roland > > -----Urspr=FCngliche Nachricht----- > Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von=20 > Christer Holmberg > Gesendet: Freitag, 19. Dezember 2014 21:11 > An: Paul Kyzivat; dispatch@ietf.org > Betreff: Re: [dispatch] Gen-art LC review:=20 > draft-holmerg-dispatch-iotl-03.txt > > Hi, > > .... > >>>>> To resolve this issue, I suggest removing the text that occurs in=20 >>>>> several places saying that this is applicable only to 3gpp=20 >>>>> networks, and add a short sentence reminding the reader that >>>>> RFC3261 expects new URI parameters to be standardized and defines=20 >>>>> how unknown URI parameters are handled. >>>> My problem with this is that IMO the semantics of traffic legs, and=20 >>>> the particular types of traffic legs, is not defined in a way that=20 >>>> makes any sense outside of an IMS network. >>> I understand that, but, really, so what? This does no harm to=20 >>> non-IMS networks. >>> If other relations of hops make sense in some other deployment, they=20 >>> can use the value extension point to say something sensical for that=20 >>> deployment. >>> I think what you're looking it is a version of "the things that know=20 >>> 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 with= out semantics. > Just to clarify, as I've also said before, in the 3GPP usage there is abs= olutely 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 e= ntity (and/or any mid-traffic leg entity) is going to do with the informati= on - especially if the traffic leg spans multiple operators. > >> I especially could not understand when it would make sense to define=20 >> new traffic leg types. Could the new types coexist in the same call,=20 >> 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 defi= ned. You need to, for the environment where you use iotl, define each traff= ic leg for that environment. >> >> ISTM that traffic leg transitions ought to constitute a sort of state ma= chine. 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 dis= cuss it in DISPATCH, and that was the outcome. > > Regards, > > Christer > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jan 7 07:04:23 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A41A90F0 for ; Wed, 7 Jan 2015 07:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjYElcL6doeS for ; Wed, 7 Jan 2015 07:04:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C081A90E5 for ; Wed, 7 Jan 2015 07:04:19 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t07F4F4g018788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2015 09:04:15 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54AD4AEA.3020706@nostrum.com> Date: Wed, 07 Jan 2015 09:04:10 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6241EB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6241EB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/C-wMHiMuIpz-8aJAt3ilhOftvBQ Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:04:21 -0000 Right. I think you need some careful guidance from your sponsoring AD here. RjS On 1/7/15 9:01 AM, Christer Holmberg wrote: > 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:dispatch-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: 7. tammikuuta 2015 16:56 > To: dispatch@ietf.org > Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt > > 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 > > On 1/7/15 4:37 AM, R.Jesske@telekom.de 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:dispatch-bounces@ietf.org] Im Auftrag von >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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 >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jan 7 08:41:28 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4181A0069 for ; Wed, 7 Jan 2015 08:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_RrQu1-lqNT for ; Wed, 7 Jan 2015 08:41:24 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35061A0075 for ; Wed, 7 Jan 2015 08:41:21 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with comcast id d4gt1p00726dK1R014hLiH; Wed, 07 Jan 2015 16:41:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id d4hL1p00B3Ge9ey014hLzE; Wed, 07 Jan 2015 16:41:20 +0000 Message-ID: <54AD61B0.6090405@alum.mit.edu> Date: Wed, 07 Jan 2015 11:41:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> In-Reply-To: <54AD48EE.9040207@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420648880; bh=uYQ4uc0X6ZhmrJb9ZaXjHuO1M4CoDj1Iyd51FyiPSbg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r1LdwE9m9lsOQQrcABYhLK2Igc9AHKLjmEgPPM5/f19AGB7KYQG1qhn0dCowlX8yA 9Il25ppEOhVkIVtdGtiSNmfbiCQ/gYEYuU5X+dTiNgkncmYR5KlTnvqjHStUF46vHo 2PtgvZlrs0P+AHc2of1TnCPfE1DMsrqWNMtG6kuQDDGZ0ugL1Nh/kJqOfLsdhQcR/w GotnBKXM1n2snBhL8jIiUs9VeYEab4XeQd5QAdwr0irce7I7hdnl9qsaUeV5Ov8doz FHkFUcIEoZMbpigJHHcgKYP7mYuKr1sytQQUrX3TjwpLxSQS5qe903JQNgn+LkW5dp VjHE7LJD7pouA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/NC0SYF5PjFKAbzRV_Vkr4Y30408 Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:41:27 -0000 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, R.Jesske@telekom.de 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:dispatch-bounces@ietf.org] Im Auftrag von >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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 >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Jan 8 00:40:14 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCC71A6FF2 for ; Thu, 8 Jan 2015 00:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMPzd2Bklfm2 for ; Thu, 8 Jan 2015 00:40:09 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716B31A8971 for ; Thu, 8 Jan 2015 00:40:08 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-e0-54ae4266272c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.2D.29772.6624EA45; Thu, 8 Jan 2015 09:40:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 09:40:05 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" , Robert Sparks , "Richard Barnes (rlb@ipv.sx)" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdCAADfDAIAAHYMAgAEbvzA= Date: Thu, 8 Jan 2015 08:40:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> In-Reply-To: <54AD61B0.6090405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW6a07oQg0c9fBZLJy1gtVix4QCr xbU5jWwWU/tsHVg8/r7/wOSxZMlPJo/JG2exeMza+YQlgCWKyyYlNSezLLVI3y6BK2Nl71P2 gvu6Fa9uT2drYOxV7WLk5JAQMJE4erKLDcIWk7hwbz2QzcUhJHCEUeLg9J8sEM5iRon9R5Yz djFycLAJWEh0/9MGiYsILGeUuH5jChNIt7CAr8Tk8ztZQGpEBAIkrr+uBwmLCCRJtN7ZyQpi swioSHQv/Qq2jBeo/NTi+1DL7jNJ9B55ygyS4BTQkdj//gMjiM0IdNH3U2vA5jMLiEvcejKf CeJSAYkle84zQ9iiEi8f/2OFsJUk1h7ezgJRrydxY+oUNghbW2LZwtfMEIsFJU7OfMIygVF0 FpKxs5C0zELSMgtJywJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgfF0cMtvgx2ML587 HmIU4GBU4uHd8GltiBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYIyeKmQ3YeG+4ED5VxzeykFlM7bs2ce/W0vhftPtmwqt1U9rtBzv/j/c9G7riay6pwY7 mr6Lf2PUqi+0m7sh+BVTS9Mx5cdfT+pPm/d/hdFvxrbVj5xXB987dOffhPw7fNVsB320LtZP te23OL555hTvR4/TIwp2zzBvzN75pPQY98UWBp+HC+KVWIozEg21mIuKEwF8vUejiAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IiuGA5MgK75mG_rgcpI5uuth7wE Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 08:40:12 -0000 Hi, So, I suggest to replace: "The SIP URI 'iotl' parameter defined in this document is only applicable = to=20 3GPP networks. The usage of the parameter within other types of networks i= s=20 undefined." ...with: "The SIP URI 'iotl' parameter defined in this document it's not likely to = be=20 particularly useful anywhere but in a 3GPP network." Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 07 January 2015 18:41 To: dispatch@ietf.org Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt 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=20 > Internet and say "it's not defined for any part of the Internet that's no= t 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=20 > 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 li= kely 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 succe= ss. I think it would require creating a framework that formalizes the notio= n of "legs" in sip signaling. But the people who want this didn't seem to w= ant 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=20 > introduction, and section 2 altogether. > > We have lots of extensions that only make sense to the devices that=20 > implement the extension. Everything else ignores it. That's what the=20 > extension in this document is doing. > > RjS > > On 1/7/15 4:37 AM, R.Jesske@telekom.de wrote: >> Yes I also think we should keep the current 3GPP scope. And as=20 >> Christer said we did discuss it in DISPATCH, and that was the outcome. >> >> Best Regards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von=20 >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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=20 >>>>>> several places saying that this is applicable only to 3gpp=20 >>>>>> networks, and add a short sentence reminding the reader that >>>>>> RFC3261 expects new URI parameters to be standardized and defines=20 >>>>>> how unknown URI parameters are handled. >>>>> My problem with this is that IMO the semantics of traffic legs,=20 >>>>> and the particular types of traffic legs, is not defined in a way=20 >>>>> that makes any sense outside of an IMS network. >>>> I understand that, but, really, so what? This does no harm to=20 >>>> non-IMS networks. >>>> If other relations of hops make sense in some other deployment,=20 >>>> they can use the value extension point to say something sensical=20 >>>> for that deployment. >>>> I think what you're looking it is a version of "the things that=20 >>>> know and care about this thing are the things that know and care=20 >>>> about this thing." >>> My concern is that this smells like a do-what-I-mean thing - syntax=20 >>> without semantics. >> Just to clarify, as I've also said before, in the 3GPP usage there is=20 >> absolutely no do-what-I-mean about iotl. The starting entity of a=20 >> traffic leg typically has no idea, and makes no assumptions, about=20 >> what/if the ending entity (and/or any mid-traffic leg entity) is=20 >> going to do with the information - especially if the traffic leg=20 >> spans multiple operators. >> >>> I especially could not understand when it would make sense to define=20 >>> new traffic leg types. Could the new types coexist in the same call,=20 >>> 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=20 >>> defined. You need to, for the environment where you use iotl, define=20 >>> each traffic leg for that environment. >>> >>> ISTM that traffic leg transitions ought to constitute a sort of=20 >>> 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=20 >>> 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=20 >> discuss it in DISPATCH, and that was the outcome. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 8 06:21:07 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECB51A00C6 for ; Thu, 8 Jan 2015 06:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj4__7TUfdsc for ; Thu, 8 Jan 2015 06:21:01 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B401A00C2 for ; Thu, 8 Jan 2015 06:21:00 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 8 Jan 2015 06:19:07 -0800 From: Michael Hammer To: "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" , "rjsparks@nostrum.com" , "rlb@ipv.sx" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwbZDQfJhc45x0CIDyutgCy9SpyWeQaAgAAHigCAAR+LgIAAP6IAgB08EACAAEhFAIAAHYMAgAEL4ID//9eksA== Date: Thu, 8 Jan 2015 14:19:07 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.84] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01D02B24.27B5FE80" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:21:04 -0000 ------=_NextPart_000_000E_01D02B24.27B5FE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, January 08, 2015 3:40 AM To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes (rlb@ipv.sx) 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=20 3GPP networks. The usage of the parameter within other types of networks is=20 undefined." ...with: "The SIP URI 'iotl' parameter defined in this document it's not likely to be=20 particularly useful anywhere but in a 3GPP network." Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: 07 January 2015 18:41 To: dispatch@ietf.org 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=20 > 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=20 > introduction, and section 2 altogether. > > We have lots of extensions that only make sense to the devices that=20 > implement the extension. Everything else ignores it. That's what the=20 > extension in this document is doing. > > RjS > > On 1/7/15 4:37 AM, R.Jesske@telekom.de wrote: >> Yes I also think we should keep the current 3GPP scope. And as=20 >> Christer said we did discuss it in DISPATCH, and that was the = outcome. >> >> Best Regards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von=20 >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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=20 >>>>>> 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,=20 >>>>> and the particular types of traffic legs, is not defined in a way=20 >>>>> that makes any sense outside of an IMS network. >>>> I understand that, but, really, so what? This does no harm to=20 >>>> non-IMS networks. >>>> If other relations of hops make sense in some other deployment,=20 >>>> they can use the value extension point to say something sensical=20 >>>> for that deployment. >>>> I think what you're looking it is a version of "the things that=20 >>>> know and care about this thing are the things that know and care=20 >>>> about this thing." >>> My concern is that this smells like a do-what-I-mean thing - syntax=20 >>> 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=20 >> traffic leg typically has no idea, and makes no assumptions, about=20 >> what/if the ending entity (and/or any mid-traffic leg entity) is=20 >> going to do with the information - especially if the traffic leg=20 >> 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=20 >>> 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=20 >>> 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=20 >>> 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 >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_000E_01D02B24.27B5FE80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMTA4MTQxOTA3WjAjBgkqhkiG 9w0BCQQxFgQUKKFP7s2f27j0e4C84dcZUumy6HswgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwDQYJKoZIhvcNAQEBBQAEggEA ODfTPN+PjgulzI2d2ZE6j5FZU4rzqpU44e/TeV2ZRaDEbFgSKHYj1Je2pdExL2Co1/funiCRtVOA w/MhW/m7mnEHKZWpjfO4MJZTUD+TIaCE/mNtDfVM029P0Px7l3LNRDy9fEd5/rqZCaVClGgDy3w0 KzqovugrD7RYhx98OEhKAamGpgidSe0qL5iNMwgY8zYSqd/+/NG8/Gzpn6Hzw/8OKlg+B3GHTAY/ c+8L+4nU+yTdQulPH5Ao85Rr757VPUi9NQSBpBoeclipLWaeIvye4/GIZ1smYkFrjqyDDb1qQWTI wsb1I3D9OqEP9Dki6hmShda3Ye5WzPHjP9ObGgAAAAAAAA== ------=_NextPart_000_000E_01D02B24.27B5FE80-- From nobody Thu Jan 8 06:27:50 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5891A00C6 for ; Thu, 8 Jan 2015 06:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxhekASrbORT for ; Thu, 8 Jan 2015 06:27:43 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B54E1A00C2 for ; Thu, 8 Jan 2015 06:27:42 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-f4-54ae93dccc3e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.7E.04076.CD39EA45; Thu, 8 Jan 2015 15:27:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 15:27:39 +0100 From: Christer Holmberg To: Michael Hammer , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" , "rjsparks@nostrum.com" , "rlb@ipv.sx" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdCAADfDAIAAHYMAgAEbvzCAAE7agIAAEuoQ Date: Thu, 8 Jan 2015 14:27:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0004_01D02B5F.FF94E560" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvje6dyetCDHbe1rJYOmkBq8W6ld9Y LFZsOMBqcW1OI5vF1D5bB1aPv+8/MHksWfKTyWPyxlksHrN2PmHxuH6whzGANYrLJiU1J7Ms tUjfLoEr43HjLvaCrXUVG9tmsTYwvinsYuTkkBAwkfi9/w07hC0mceHeerYuRi4OIYEjjBLz Zj1hAUkICSxmlJhy0riLkYODTcBCovufNkiNiMBNRoklc/6xgtQIC/hKTD6/kwWkRkQgQOL6 63qQsIhAnsTb7ZPYQGwWARWJixdfMoPYvEDln9auZYUY/5FZYteKfBCbUyBCovfcaiYQmxHo nu+n1oDZzALiEreezGeCuFNE4uHF02wQtqjEy8cQJ0gIKEn82HCJBeQ2ZoFeRomdczqhlglK nJz5hGUCo8gsJLNmIaubhaQOoshA4v6hDlYIW1ti2cLXzBC2tcSMXwfZIGxFiSndD9khbFOJ 10c/Mi5g5FjFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERirB7f8ttrBePC54yFGAQ5GJR7e DZ/WhgixJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbnLIai TRmV4h913kn4T9Ytv5L28PV170CnOdOtnnmF94kvt3qqb1NzVjAtrq7TyW9J/07rcBFObpu0 4LBFh3237L55LdShRmzPGYaz2V/zU5Lr/d8FLogMO/g4qb1e59rMFsNvNw48+1z+ozZOvvBJ z4OtCiWR5T0zf1hcXHkyxZnzxv1nmkosxRmJhlrMRcWJAI6PCQm2AgAA Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:27:47 -0000 ------=_NextPart_000_0004_01D02B5F.FF94E560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, Personally I am ok also with the text you suggest :) Regards, Christer -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: 8. tammikuuta 2015 16:19 To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx 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:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, January 08, 2015 3:40 AM To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes (rlb@ipv.sx) 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=20 3GPP networks. The usage of the parameter within other types of networks is=20 undefined." ...with: "The SIP URI 'iotl' parameter defined in this document it's not likely to be=20 particularly useful anywhere but in a 3GPP network." Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: 07 January 2015 18:41 To: dispatch@ietf.org 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=20 > 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=20 > introduction, and section 2 altogether. > > We have lots of extensions that only make sense to the devices that=20 > implement the extension. Everything else ignores it. That's what the=20 > extension in this document is doing. > > RjS > > On 1/7/15 4:37 AM, R.Jesske@telekom.de wrote: >> Yes I also think we should keep the current 3GPP scope. And as=20 >> Christer said we did discuss it in DISPATCH, and that was the = outcome. >> >> Best Regards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von=20 >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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=20 >>>>>> 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,=20 >>>>> and the particular types of traffic legs, is not defined in a way=20 >>>>> that makes any sense outside of an IMS network. >>>> I understand that, but, really, so what? This does no harm to=20 >>>> non-IMS networks. >>>> If other relations of hops make sense in some other deployment,=20 >>>> they can use the value extension point to say something sensical=20 >>>> for that deployment. >>>> I think what you're looking it is a version of "the things that=20 >>>> know and care about this thing are the things that know and care=20 >>>> about this thing." >>> My concern is that this smells like a do-what-I-mean thing - syntax=20 >>> 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=20 >> traffic leg typically has no idea, and makes no assumptions, about=20 >> what/if the ending entity (and/or any mid-traffic leg entity) is=20 >> going to do with the information - especially if the traffic leg=20 >> 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=20 >>> 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=20 >>> 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=20 >>> 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 >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_0004_01D02B5F.FF94E560 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVXDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcx MDE4MTI1MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBBQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4o PxOL9ZVGnhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMK ziBdedr0HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6p AKqZcnJfrI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqo k3yH1wZhC+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF+TCCA+GgAwIBAgIQ MQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzEx MDQxMjI4MThaMG8xETAPBgNVBAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVy ZzEtMCsGCSqGSIb3DQEJARYeY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQF EwZMTUZDSEgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/ 6ibdVV0I+ZqVLE21zQB7otFv6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7f Mm6BME33Bkdgg4EfJrq4FUG28Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5ke qwow9ria0/WazHiK3wxzjbanoQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08 gxR5IE9NRi47Eqh6LtBjiWpaB42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdi XZY244D5J1gWssRFAgMBAAGjggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRy dXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2 MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKG PGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYy LmNlcjApBgNVHREEIjAggR5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBRUo03/DrRAW2xpMmhN2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIP Aw0JlKltVQ/TlsF7ig0J1iyzao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+q krQMDOdix9Was0cvIjDWjAQnEZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bD unc+NCj1FkSKkSRb9fP2Z2li65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtO iJQ2loA+62vQreUQr328XK4IHFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAi VmNTiv4EGGv5heX5vb8yaj7pr4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59 sq9bOCefghktc5fwDu8ved98cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaR G+mPFbY2pTyR0V84PG7HLekupNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCAN g8fVWrxqqOoEzvcUcPMy6XXJs0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmO eBSA4y7YZ47y+CxvbknSQ5dyghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC8zCCAu8C AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDAJBgUrDgMCGgUAoIIBejAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAxMDgxNDI3MzBaMCMGCSqGSIb3DQEJBDEWBBQB 3kJa5Cc49RzfNZN7NTIF3EYJgDBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjBd BgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMF8GCyqGSIb3DQEJEAILMVCgTjA6 MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQEFAASCAQCJv3oAVPVtC3HVoTpCVaDn42ga mlU4+yGxywdc962MCwa0MRG1UO3mr4/JZq2b1XWL3tVHg/8NYY4oeWuDwXM5LF8ONsHSO7YxIPBp SJLb9qvJdAc7h9O9FW6+mPW8VGg/noyv9Vfm0x3FEGFvyiMIp2AmPUu5H9Z4rqqUuLAanguTOceF Q7FD8QFH5GiJpr1G02t34wsjnLjcNO+vZk1XchxWry/nnaTInB2OnKL0Sy2dxIn0OYgD7t0m9Zky DKYuoRknXB23YCIhQzQMiAFAK072aPjtA2ytOXoT3472GopupE58JpFVfOSP+wtfDHsIcEZ31phS AknRj+IQ0/6IAAAAAAAA ------=_NextPart_000_0004_01D02B5F.FF94E560-- From nobody Thu Jan 8 08:52:56 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3203A1A87EF for ; Thu, 8 Jan 2015 08:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F966i6fJQu90 for ; Thu, 8 Jan 2015 08:52:47 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FAB1A87ED for ; Thu, 8 Jan 2015 08:52:45 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP; 08 Jan 2015 17:52:43 +0100 X-IronPort-AV: E=Sophos;i="5.07,723,1413237600"; d="scan'208";a="194324752" Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 08 Jan 2015 17:52:43 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 8 Jan 2015 17:52:43 +0100 From: To: , , , , , Date: Thu, 8 Jan 2015 17:52:41 +0100 Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdCAADfDAIAAHYMAgAEbvzCAAE7agIAAEuoQgAAoswA= Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80F3804@HE113667.emea1.cds.t-internal.com> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:52:54 -0000 +1 Roland -----Urspr=FCngliche Nachricht----- Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Ho= lmberg Gesendet: Donnerstag, 8. Januar 2015 15:28 An: Michael Hammer; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nost= rum.com; rlb@ipv.sx Betreff: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt Hi Michael, Personally I am ok also with the text you suggest :) Regards, Christer -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: 8. tammikuuta 2015 16:19 To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@n= ostrum.com; rlb@ipv.sx 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 dispr= oved 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 3= GPP 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:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: Thursday, January 08, 2015 3:40 AM To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes (rlb@ipv.sx) 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=20 3GPP networks. The usage of the parameter within other types of networks i= s=20 undefined." ...with: "The SIP URI 'iotl' parameter defined in this document it's not likely to = be=20 particularly useful anywhere but in a 3GPP network." Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 07 January 2015 18:41 To: dispatch@ietf.org 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=20 > Internet and say "it's not defined for any part of the Internet that's=20 > 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=20 > 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 li= kely 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 succe= ss. I think it would require creating a framework that formalizes the notio= n of "legs" in sip signaling. But the people who want this didn't seem to w= ant 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=20 > introduction, and section 2 altogether. > > We have lots of extensions that only make sense to the devices that=20 > implement the extension. Everything else ignores it. That's what the=20 > extension in this document is doing. > > RjS > > On 1/7/15 4:37 AM, R.Jesske@telekom.de wrote: >> Yes I also think we should keep the current 3GPP scope. And as=20 >> Christer said we did discuss it in DISPATCH, and that was the outcome. >> >> Best Regards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von=20 >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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=20 >>>>>> several places saying that this is applicable only to 3gpp=20 >>>>>> networks, and add a short sentence reminding the reader that >>>>>> RFC3261 expects new URI parameters to be standardized and defines=20 >>>>>> how unknown URI parameters are handled. >>>>> My problem with this is that IMO the semantics of traffic legs,=20 >>>>> and the particular types of traffic legs, is not defined in a way=20 >>>>> that makes any sense outside of an IMS network. >>>> I understand that, but, really, so what? This does no harm to=20 >>>> non-IMS networks. >>>> If other relations of hops make sense in some other deployment,=20 >>>> they can use the value extension point to say something sensical=20 >>>> for that deployment. >>>> I think what you're looking it is a version of "the things that=20 >>>> know and care about this thing are the things that know and care=20 >>>> about this thing." >>> My concern is that this smells like a do-what-I-mean thing - syntax=20 >>> without semantics. >> Just to clarify, as I've also said before, in the 3GPP usage there is=20 >> absolutely no do-what-I-mean about iotl. The starting entity of a=20 >> traffic leg typically has no idea, and makes no assumptions, about=20 >> what/if the ending entity (and/or any mid-traffic leg entity) is=20 >> going to do with the information - especially if the traffic leg=20 >> spans multiple operators. >> >>> I especially could not understand when it would make sense to define=20 >>> new traffic leg types. Could the new types coexist in the same call,=20 >>> 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=20 >>> defined. You need to, for the environment where you use iotl, define=20 >>> each traffic leg for that environment. >>> >>> ISTM that traffic leg transitions ought to constitute a sort of=20 >>> 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=20 >>> 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=20 >> discuss it in DISPATCH, and that was the outcome. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 8 09:51:36 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA51A8F35 for ; Thu, 8 Jan 2015 09:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H29gRJLpGz2j for ; Thu, 8 Jan 2015 09:51:32 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879011A7D83 for ; Thu, 8 Jan 2015 09:51:31 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-6d-54aec3a1a4af Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.8A.04076.1A3CEA45; Thu, 8 Jan 2015 18:51:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 18:51:28 +0100 From: Christer Holmberg To: "R.Jesske@telekom.de" , "michael.hammer@yaanatech.com" , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" , "rjsparks@nostrum.com" , "rlb@ipv.sx" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdCAADfDAIAAHYMAgAEbvzCAAE7agIAAEuoQgAAoswCAABBuYA== Date: Thu, 8 Jan 2015 17:51:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6281CC@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80F3804@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80F3804@HE113667.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3Rnfh4XUhBh17pC2WTlrAarFu5TcW ixUbDrBaNN3pYrO4NqeRzWJqn60Dm8ff9x+YPJYs+cnkMXnjLBaPWTufsHi0vVTwuH6whzGA LYrLJiU1J7MstUjfLoEr48bjXuaCVXYVfWcuMDcw9hl3MXJwSAiYSBz6GdrFyAlkiklcuLee rYuRi0NI4AijxKQX35ggnMWMEtu/zGIEaWATsJDo/qcNEhcRmMUksWjnSjaQbmEBX4nJ53ey gNSICARIXH9dDxIWEaiTaP50kQXEZhFQkdi+Yi8riM0LVL74zV2oZR2sEo2vHoHN4RSIlZg2 s50JxGYEuuj7qTVgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW0lixfZLjBD1ehI3pk5h g7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSkl1qUmVxc nJ+nl5dasokRGHMHt/y22sF48LnjIUYBDkYlHt4Nn9aGCLEmlhVX5h5ilOZgURLnXXhuXrCQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxvnXPwkqcx1YwfRWLujz3qMcjcz28+1nXll7ekZs At+dSMPVFoXvGjvin2W0J1b+N0wSNZ1fpKVbo/OmU2dF8+vS1Y83zVYznBh0j6/N81/T82Nc +6T2/XCqylQwO/3p93mXBouG/BfBdokCUkkWPB9/8Xzuz035/XhG4qrj53dc6Nx6QChkoxJL cUaioRZzUXEiAPugaOaaAgAA Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:51:35 -0000 Robert/Paul, are you ok with Michael's suggested change to the text? Regards, Christer -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: 08 January 2015 18:53 To: Christer Holmberg; michael.hammer@yaanatech.com; pkyzivat@alum.mit.edu;= dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx Subject: AW: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt +1 Roland -----Urspr=FCngliche Nachricht----- Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Ho= lmberg Gesendet: Donnerstag, 8. Januar 2015 15:28 An: Michael Hammer; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nost= rum.com; rlb@ipv.sx Betreff: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt Hi Michael, Personally I am ok also with the text you suggest :) Regards, Christer -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: 8. tammikuuta 2015 16:19 To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@n= ostrum.com; rlb@ipv.sx 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 dispr= oved 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 3= GPP 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:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: Thursday, January 08, 2015 3:40 AM To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes (rlb@ipv.sx) 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=20 3GPP networks. The usage of the parameter within other types of networks i= s=20 undefined." ...with: "The SIP URI 'iotl' parameter defined in this document it's not likely to = be=20 particularly useful anywhere but in a 3GPP network." Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 07 January 2015 18:41 To: dispatch@ietf.org 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=20 > Internet and say "it's not defined for any part of the Internet that's=20 > 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=20 > 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 li= kely 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 succe= ss. I think it would require creating a framework that formalizes the notio= n of "legs" in sip signaling. But the people who want this didn't seem to w= ant 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=20 > introduction, and section 2 altogether. > > We have lots of extensions that only make sense to the devices that=20 > implement the extension. Everything else ignores it. That's what the=20 > extension in this document is doing. > > RjS > > On 1/7/15 4:37 AM, R.Jesske@telekom.de wrote: >> Yes I also think we should keep the current 3GPP scope. And as=20 >> Christer said we did discuss it in DISPATCH, and that was the outcome. >> >> Best Regards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von=20 >> Christer Holmberg >> Gesendet: Freitag, 19. Dezember 2014 21:11 >> An: Paul Kyzivat; dispatch@ietf.org >> 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=20 >>>>>> several places saying that this is applicable only to 3gpp=20 >>>>>> networks, and add a short sentence reminding the reader that >>>>>> RFC3261 expects new URI parameters to be standardized and defines=20 >>>>>> how unknown URI parameters are handled. >>>>> My problem with this is that IMO the semantics of traffic legs,=20 >>>>> and the particular types of traffic legs, is not defined in a way=20 >>>>> that makes any sense outside of an IMS network. >>>> I understand that, but, really, so what? This does no harm to=20 >>>> non-IMS networks. >>>> If other relations of hops make sense in some other deployment,=20 >>>> they can use the value extension point to say something sensical=20 >>>> for that deployment. >>>> I think what you're looking it is a version of "the things that=20 >>>> know and care about this thing are the things that know and care=20 >>>> about this thing." >>> My concern is that this smells like a do-what-I-mean thing - syntax=20 >>> without semantics. >> Just to clarify, as I've also said before, in the 3GPP usage there is=20 >> absolutely no do-what-I-mean about iotl. The starting entity of a=20 >> traffic leg typically has no idea, and makes no assumptions, about=20 >> what/if the ending entity (and/or any mid-traffic leg entity) is=20 >> going to do with the information - especially if the traffic leg=20 >> spans multiple operators. >> >>> I especially could not understand when it would make sense to define=20 >>> new traffic leg types. Could the new types coexist in the same call,=20 >>> 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=20 >>> defined. You need to, for the environment where you use iotl, define=20 >>> each traffic leg for that environment. >>> >>> ISTM that traffic leg transitions ought to constitute a sort of=20 >>> 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=20 >>> 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=20 >> discuss it in DISPATCH, and that was the outcome. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 8 11:30:49 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B71A906D for ; Thu, 8 Jan 2015 11:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8eGvm5VBn_s for ; Thu, 8 Jan 2015 11:30:42 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CBC1A906C for ; Thu, 8 Jan 2015 11:30:42 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t08JUZNx062941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2015 13:30:35 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54AEDAD6.30407@nostrum.com> Date: Thu, 08 Jan 2015 13:30:30 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "R.Jesske@telekom.de" , "michael.hammer@yaanatech.com" , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" , "rlb@ipv.sx" References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80F3804@HE113667.emea1.cds.t-internal.com> <7594FB04B1934943A5C02806D1A2204B1D6281CC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6281CC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:30:46 -0000 I am On 1/8/15 11:51 AM, Christer Holmberg wrote: > Robert/Paul, are you ok with Michael's suggested change to the text? > > Regards, > > Christer > > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: 08 January 2015 18:53 > To: Christer Holmberg; michael.hammer@yaanatech.com; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > Subject: AW: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt > > +1 > > Roland > > -----Ursprüngliche Nachricht----- > Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Holmberg > Gesendet: Donnerstag, 8. Januar 2015 15:28 > An: Michael Hammer; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > 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:michael.hammer@yaanatech.com] > Sent: 8. tammikuuta 2015 16:19 > To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > 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:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, January 08, 2015 3:40 AM > To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes > (rlb@ipv.sx) > 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:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 07 January 2015 18:41 > To: dispatch@ietf.org > 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, R.Jesske@telekom.de 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:dispatch-bounces@ietf.org] Im Auftrag von >>> Christer Holmberg >>> Gesendet: Freitag, 19. Dezember 2014 21:11 >>> An: Paul Kyzivat; dispatch@ietf.org >>> 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 >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 8 23:54:39 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045CA1A86E7 for ; Thu, 8 Jan 2015 23:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB8m2XPPlEcN for ; Thu, 8 Jan 2015 23:54:36 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9181A86E8 for ; Thu, 8 Jan 2015 23:54:35 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-a2-54af89398f2e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.06.04231.9398FA45; Fri, 9 Jan 2015 08:54:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 08:54:33 +0100 From: Christer Holmberg To: "dispatch@ietf.org" , "rjsparks@nostrum.com" , "Richard Barnes (rlb@ipv.sx)" Thread-Topic: Draft new version: iotl-04 Thread-Index: AdAr4ULq9k0tRZioQCmqFAmIf2DvoQ== Date: Fri, 9 Jan 2015 07:54:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6300ED@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6300EDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvja5l5/oQg4YluhZLJy1gtbg2p5HN YmqfrQOzx5IlP5k8Jm+cxeIxa+cTlgDmKC6blNSczLLUIn27BK6Mjdf+shXMl6hYdc6xgXGv aBcjJ4eEgInE9xM7mCFsMYkL99azdTFycQgJHGGU+DJpATOEs5hRYuvpCUxdjBwcbAIWEt3/ tEHiIgIdjBJt1/6xgsSFBZQlPq4xBhkkIqAh0dr5lRnC1pP4sWozG0gJi4CKxLwtkSBhXgFf iTlfrjOC2IxAe7+fWsMEYjMLiEvcejKfCeIeAYkle85D3SYq8fIxyCYQW1Fi59l2Zoj6fIkL E2ayQ8wUlDg58wnLBEahWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/F KFqcWlycm25krJdalJlcXJyfp5eXWrKJERg1B7f81t3BuPq14yFGAQ5GJR5eA5f1IUKsiWXF lbmHGKU5WJTEeW8LA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw8r6ZNGFHwO/oE2c2LX6l b7RS1l2us5HDOPwc56vDk1ZqSM8Ke74zK7H6/bH8aP9TBydYa0qZuD8N2LxVnGVp5xJDJ7/c 1YmH5XJ2feKr0ZWaGvn13MQva9zn3tmlfuqYcPpqzl0yK+9slHqw+MvH2mvfMhb7PzimOuEw X5hexomzlf0xr5mUnyixFGckGmoxFxUnAgBexqu1ewIAAA== Archived-At: Subject: [dispatch] Draft new version: iotl-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 07:54:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6300EDESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on Robert's Gen-ART review, and the list discussions, I've submitted = a new version (-04) of the iotl draft. The main difference compared to the previous version is that the 3GPP scope= has been removed. Thanks to everyone who provided comments and input! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D6300EDESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on Robert’s Gen-ART review, and the list= discussions, I’ve submitted a new version (-04) of the iotl draft.

 

The main difference compared to the previous version= is that the 3GPP scope has been removed.

 

Thanks to everyone who provided comments and input!<= o:p>

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D6300EDESESSMB209erics_-- From nobody Fri Jan 9 08:36:00 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F691A8990 for ; Fri, 9 Jan 2015 08:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5uUmjW_Fgs2 for ; Fri, 9 Jan 2015 08:35:57 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026FF1A897C for ; Fri, 9 Jan 2015 08:35:56 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-08v.sys.comcast.net with comcast id dsbo1p0062D5gil01sbwHV; Fri, 09 Jan 2015 16:35:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id dsbu1p00M3Ge9ey01sbuNQ; Fri, 09 Jan 2015 16:35:56 +0000 Message-ID: <54B0036A.3020302@alum.mit.edu> Date: Fri, 09 Jan 2015 11:35:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "R.Jesske@telekom.de" , "michael.hammer@yaanatech.com" , "dispatch@ietf.org" , "rjsparks@nostrum.com" , "rlb@ipv.sx" References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80F3804@HE113667.emea1.cds.t-internal.com> <7594FB04B1934943A5C02806D1A2204B1D6281CC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6281CC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420821356; bh=y7erOPZ25VnLjuXertkC5C+IZexxRlqwHDfv1yXVpu4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WUsFrSAkjaRBUmIgOBlWHpHi/Aexwvfzu1+h6tYD/7Kfse9Fjk/ErWO8rA1TxyIWm zfxvXPS9HlZMNKqKckJkltL+QEAxn+UarrZtvHsS5CzAThCbceozFZIfy8MfW6oafz YhgOUiSnQpFcLHbemhxHmSx909suSW6QJbBV6YZs4raC/1ZQ/Jvd0erjyTLbWoccFo U98AEhHWxMC5k04iM1tPfQy6uq7APZOr6GBh+pAosXKvXR1lidMr3oIrctePBDORrY p2iXO6Vf2QCEa8nENZHqruYAmHKXSFoJcA0E6kCGKWPCvIiBdI37ItYxway1cbGLei e3zEGVqhsXcCQ== Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 16:35:59 -0000 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: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: 08 January 2015 18:53 > To: Christer Holmberg; michael.hammer@yaanatech.com; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > Subject: AW: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt > > +1 > > Roland > > -----Ursprüngliche Nachricht----- > Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Holmberg > Gesendet: Donnerstag, 8. Januar 2015 15:28 > An: Michael Hammer; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > 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:michael.hammer@yaanatech.com] > Sent: 8. tammikuuta 2015 16:19 > To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > 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:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, January 08, 2015 3:40 AM > To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes > (rlb@ipv.sx) > 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:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 07 January 2015 18:41 > To: dispatch@ietf.org > 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, R.Jesske@telekom.de 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:dispatch-bounces@ietf.org] Im Auftrag von >>> Christer Holmberg >>> Gesendet: Freitag, 19. Dezember 2014 21:11 >>> An: Paul Kyzivat; dispatch@ietf.org >>> 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 >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Jan 9 09:25:03 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06F41A8ACB for ; Fri, 9 Jan 2015 09:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LxQIVi5mJT8 for ; Fri, 9 Jan 2015 09:24:45 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9542F1A1B22 for ; Fri, 9 Jan 2015 09:24:44 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-77-54b00eda38e2 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.3A.04076.ADE00B45; Fri, 9 Jan 2015 18:24:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 18:24:41 +0100 From: Christer Holmberg To: Paul Kyzivat , "R.Jesske@telekom.de" , "michael.hammer@yaanatech.com" , "dispatch@ietf.org" , "rjsparks@nostrum.com" , "rlb@ipv.sx" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQgB1BHdCAADfDAIAAHYMAgAEbvzCAAE7agIAAEuoQgAAoswCAABBuYIABbIEAgAAeZZ8= Date: Fri, 9 Jan 2015 17:24:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D631E6A@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80019FC@HE113667.emea1.cds.t-internal.com> <54AD48EE.9040207@nostrum.com> <54AD61B0.6090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6262DD@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3BC01B5D5@sc9-ex2k10mb1.corp.yaanatech.com> <7594FB04B1934943A5C02806D1A2204B1D627CFF@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E5F80F3804@HE113667.emea1.cds.t-internal.com> <7594FB04B1934943A5C02806D1A2204B1D6281CC@ESESSMB209.ericsson.se>, <54B0036A.3020302@alum.mit.edu> In-Reply-To: <54B0036A.3020302@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D631E6AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM+Jvje4tvg0hBtv3qFssnbSA1WLdym8s Fis2HGC1aLrTxWZxbU4jm8XUPlsHNo+/7z8weSxZ8pPJY/LGWSwes3Y+YfFoe6ngcf1gD2MA WxSXTUpqTmZZapG+XQJXxtqZvawFbZsYKx5v2cTYwPhtGmMXIyeHhICJxKu/y1ggbDGJC/fW s3UxcnEICRxhlFhwoJ0ZwlnMKLF712GgKg4ONgELie5/2iBxEYFeJomZdz6xg3QLC/hKTD6/ E6xGRCBA4vrreoiaLkaJf28/gG1gEVCR6FyxhwmkhheoflmrAMT8N6wSG+eeYQOp4RTQkWj4 ugqsnhHoou+n1jCB2MwC4hJNX1ayQlwqILFkz3lmCFtU4uXjf6wQNfkS75Z8A6vnFRCUODnz CcsERuFZSNpnISmbhaQMIm4g8eX9bShbW2LZwtfMELa+RPf700zI4gsY2VcxihanFhfnphsZ 6aUWZSYXF+fn6eWllmxiBEbkwS2/rXYwHnzueIhRgINRiYfXwGV9iBBrYllxZe4hRmkOFiVx 3tvCQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MsstNL/8QtDqacX6yJefD9UbPZx7YHPL2 RNhh6R3Xr6i95LrgIHVzmZTQ2v9cSvKXTVXO9JyOXpK0wEb2XT/Ptv3nBVZFqvtsPfG1ZcV1 ofoOm+Wb1X+8yuopmtCVvVZoZlJjQOX86j+Ry/Q8FGM+2k8NWOX6rXzZ/exVBnz7Gl9Mv6Ab wOEkr8RSnJFoqMVcVJwIABcs5kmpAgAA Archived-At: Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 17:24:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D631E6AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Great! Thanks! Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD09/=FD01/=FD2015 18:51 To: Christer Holmberg; R.Jesske@tele= kom.de; michael.hammer@yaanatech.com; dispatch@ietf.org; rj= sparks@nostrum.com; rlb@ipv.sx Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt 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: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: 08 January 2015 18:53 > To: Christer Holmberg; michael.hammer@yaanatech.com; pkyzivat@alum.mit.ed= u; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx > Subject: AW: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03= .txt > > +1 > > Roland > > -----Urspr=FCngliche Nachricht----- > Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer = Holmberg > Gesendet: Donnerstag, 8. Januar 2015 15:28 > An: Michael Hammer; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks@no= strum.com; rlb@ipv.sx > 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:michael.hammer@yaanatech.com] > Sent: 8. tammikuuta 2015 16:19 > To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks= @nostrum.com; rlb@ipv.sx > 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 dis= proved in time. > Also, positive language would be better. > > Why not just say: > > "The SIP URI 'iotl' parameter defined in this document has known u= ses 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:dispatch-bounces@ietf.org] On Behalf Of Christer H= olmberg > Sent: Thursday, January 08, 2015 3:40 AM > To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes > (rlb@ipv.sx) > 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 app= licable to > 3GPP networks. The usage of the parameter within other types of ne= tworks is > undefined." > > ...with: > > "The SIP URI 'iotl' parameter defined in this document it's not li= kely to be > particularly useful anywhere but in a 3GPP network." > > Regards, > > Christer > > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyziv= at > Sent: 07 January 2015 18:41 > To: dispatch@ietf.org > 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 trie= d to understand the semantics enough to see how to do that, but without suc= cess. I think it would require creating a framework that formalizes the not= ion 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 doin= g 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, R.Jesske@telekom.de 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=FCngliche Nachricht----- >>> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von >>> Christer Holmberg >>> Gesendet: Freitag, 19. Dezember 2014 21:11 >>> An: Paul Kyzivat; dispatch@ietf.org >>> 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 IM= S. >>>> 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 >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --_000_7594FB04B1934943A5C02806D1A2204B1D631E6AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Great! Thanks= !

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD09= /=FD01/=FD2015 18:51
To: Christer Holmberg; R.Jesske@telekom.de; michael.hammer@yaanatech.com; disp= atch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx
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: R.Jesske@telekom.de [mail= to:R.Jesske@telekom.de]
> Sent: 08 January 2015 18:53
> To: Christer Holmberg; michael.hammer@yaanatech.com; pkyzivat@alum.mit= .edu; dispatch@ietf.org; rjsparks@nostrum.com; rlb@ipv.sx
> Subject: AW: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl= -03.txt
>
> +1
>
> Roland
>
> -----Urspr=FCngliche Nachricht-----
> Von: dispatch [mailto:dis= patch-bounces@ietf.org] Im Auftrag von Christer Holmberg
> Gesendet: Donnerstag, 8. Januar 2015 15:28
> An: Michael Hammer; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjsparks= @nostrum.com; rlb@ipv.sx
> 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:michael.hammer@yaanatech.com]
> Sent: 8. tammikuuta 2015 16:19
> To: Christer Holmberg; pkyzivat@alum.mit.edu; dispatch@ietf.org; rjspa= rks@nostrum.com; rlb@ipv.sx
> 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' par= ameter defined in this document has known uses in 3GPP networks.
>        Usage in other networks is a= lso possible."
>
> If other networks never define a usage, then the statement is still tr= ue.
> If other networks do define a usage, then the statement is still true.=
>
> Mike
>
> -----Original Message-----
> From: dispatch [mailto:di= spatch-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: Thursday, January 08, 2015 3:40 AM
> To: Paul Kyzivat; dispatch@ietf.org; Robert Sparks; Richard Barnes
> (rlb@ipv.sx)
> Subject: Re: [dispatch] Gen-art LC review:
> draft-holmerg-dispatch-iotl-03.txt
>
> Hi,
>
> So, I suggest to replace:
>
>        "The SIP URI 'iotl' par= ameter 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' par= ameter 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:di= spatch-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 07 January 2015 18:41
> To: dispatch@ietf.org
> 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 Intern= et 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 n= ot likely
>> to be particularly useful anywhere but in a 3GPP network". >
> That would work for me. I certainly have no problem with somebody find= ing 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 t= ried 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 signalin= g. 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 communi= ty.
>
>        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 tha= t
>> implement the extension. Everything else ignores it. That's what t= he
>> extension in this document is doing.
>>
>> RjS
>>
>> On 1/7/15 4:37 AM, R.Jesske@telekom.de 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=FCngliche Nachricht-----
>>> Von: dispatch [ma= ilto:dispatch-bounces@ietf.org] Im Auftrag von
>>> Christer Holmberg
>>> Gesendet: Freitag, 19. Dezember 2014 21:11
>>> An: Paul Kyzivat; dispatch@ietf.org
>>> 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 t= he reader that
>>>>>>> RFC3261 expects new URI parameters to be stand= ardized 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 d= efined 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 de= ployment,
>>>>> they can use the value extension point to say somethin= g sensical
>>>>> for that deployment.
>>>>> I think what you're looking it is a version of "t= he things that
>>>>> know and care about this thing are the things that kno= w 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 t= here is
>>> absolutely no do-what-I-mean about iotl. The starting entity o= f a
>>> traffic leg typically has no idea, and makes no assumptions, a= bout
>>> what/if the ending entity (and/or any mid-traffic leg entity) = is
>>> going to do with the information - especially if the traffic l= eg
>>> 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 d= efine new
>>>> *collections* of traffic leg types that work with one anot= her?
>>>>
>>>> The only reason I can think of is some completely new call= model is
>>>> defined. You need to, for the environment where you use io= tl, define
>>>> each traffic leg for that environment.
>>>>
>>>> ISTM that traffic leg transitions ought to constitute a so= rt of
>>>> state machine. But Christer didn't think so.
>>>>
>>>> I can live with this state of affairs while the scope is l= imited to IMS.
>>>> But if it is opened up then I think those issues need to b= e sorted out.
>>>> But nobody outside the IMS community could see a use for t= his, so
>>>> there was no interest in doing to work to define it more g= enerally.
>>> 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
>>> dispatch@ietf.org
>>> htt= ps://www.ietf.org/mailman/listinfo/dispatch
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> htt= ps://www.ietf.org/mailman/listinfo/dispatch
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/dispatch
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch
>

 --_000_7594FB04B1934943A5C02806D1A2204B1D631E6AESESSMB209erics_-- From nobody Sun Jan 11 10:17:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588971A86F3 for ; Sun, 11 Jan 2015 10:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.732 X-Spam-Level: X-Spam-Status: No, score=-99.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htgjlIqCkOvW for ; Sun, 11 Jan 2015 10:17:33 -0800 (PST) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3211A82E2 for ; Sun, 11 Jan 2015 10:17:31 -0800 (PST) Received: from [151.252.64.147] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 7099204 for dispatch@ietf.org; Sun, 11 Jan 2015 21:17:29 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Sun, 11 Jan 2015 23:17:02 +0500 MIME-Version: 1.0 Message-ID: <54B2BE1E.16173.111682E0@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Archived-At: Subject: Re: [dispatch] Draft minutes from IETF 91- Issue "forking correlation" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 18:17:35 -0000 Dear All, This seems to be related to the problem of semantics. Tradidtionally, IETF defines syntax of protocols, but not semantics. However, sometimes this position hinders interoperability (what we see here). To add to all my previous posts: what about From-URI in conference invitations? Should it be conference-URI or inviting party's AoR? Convenor, focus? From nobody Tue Jan 13 08:14:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B830C1A8F3A for ; Tue, 13 Jan 2015 08:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKRber84KH50 for ; Tue, 13 Jan 2015 08:14:29 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 368D91A8BBD for ; Tue, 13 Jan 2015 08:14:27 -0800 (PST) X-AuditID: 1207440d-f79976d000005643-5c-54b544622205 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 37.CF.22083.26445B45; Tue, 13 Jan 2015 11:14:26 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0DGEQOi015388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Jan 2015 11:14:26 -0500 Message-ID: <54B54462.8060308@alum.mit.edu> Date: Tue, 13 Jan 2015 11:14:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> In-Reply-To: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixO6iqJvksjXEYG27jsXSSQtYHRg9liz5 yRTAGMVtk5RYUhacmZ6nb5fAnbFhcjtrwTT+it6bbUwNjPt5uhg5OSQETCRmrVrGBmGLSVy4 tx7I5uIQErjMKNHxfCszhPOfSWJ76yJ2kCpeAW2J6V9+gnWwCKhKHH50gxnEZhPQkphz6D8L iC0qkCyxZuskqHpBiZMzn4DFRYB6j67qAqsXFoiT2NbxGMjmAFrgIDHzDB9ImFPAUeLAsjNM EAf5SByf3QFWzixgJtG1tYsRwpaX2P52DvMERoFZSDbMQlI2C0nZAkbmVYxyiTmlubq5iZk5 xanJusXJiXl5qUW6Rnq5mSV6qSmlmxghYcm7g/H/OplDjAIcjEo8vAJ5W0KEWBPLiitzDzFK cjApifI2yW0NEeJLyk+pzEgszogvKs1JLT7EKMHBrCTC+8gcKMebklhZlVqUD5OS5mBREudV W6LuJySQnliSmp2aWpBaBJPV4+AQ+PLx3CdGgUtvur8ySrHk5eelKknw3nMCGiVYlJqeWpGW mVOC0MDEwQmyjktKpDg1LyW1KLG0JCMeFM3xxcB4BknxAF3C4QxySXFBYi5QFKL1FKOilDjv SZC5AiCJjNI8uLGwhPSKURzob2HeXyBVPMBkBtf9CmgwE9Dgxe2bQQaXJCKkpBoYPbe/vFOr w/69zjH918XJO5327djyymQp08k5Z1ZNOrRq+unaq1Gru6IXfcsV4HEXM32x8UelUv7Fq4y/ CtevVp957Fj+cbNHt0Meq0s5cG8zmL9u9t3tV8UfXPQ8+iQw/NOWgJ37as8yGVgeOM4R9S// Vc/9o+J7pLzFIrV2zz8X+5Ht/J2z+vlKLMUZiYZazEXFiQAEqc4BIwMAAA== Archived-At: Subject: [dispatch] Fwd: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 16:14:31 -0000 Dispatchers: I have just submitted a new draft (see below) that needs to be dispatched. It defines a new Call-Info 'purpose' parameter value. The intended audience for this draft is quite limited - to the providers of the Video Relay Service in the US, and to the FCC that sponsors that service. The Intro section explains this. I'm hoping this can be dispatched without causing a lot of bother for anybody. I don't anticipate that it needs time in Dallas. IIUC documents of this sort are often AD sponsored. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt Date: Tue, 13 Jan 2015 07:46:47 -0800 From: internet-drafts@ietf.org To: Paul Kyzivat , "Paul Kyzivat" A new version of I-D, draft-kyzivat-dispatch-trs-call-info-purpose-00.txt has been successfully submitted by Paul Kyzivat and posted to the IETF repository. Name: draft-kyzivat-dispatch-trs-call-info-purpose Revision: 00 Title: Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) Document date: 2015-01-13 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-info-purpose-00.txt Status: https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purpose/ Htmlized: http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-purpose-00 Abstract: This document defines and registers a value of "original-identity" for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jan 13 09:59:28 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF91A9045 for ; Tue, 13 Jan 2015 09:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81AA5LN39vTo for ; Tue, 13 Jan 2015 09:59:25 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD9B1A904F for ; Tue, 13 Jan 2015 09:59:15 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i8so3444471qcq.11 for ; Tue, 13 Jan 2015 09:59:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=IjQuz9GpGOf8cMyuasEgA4FO3rbwEXNAZVm8n/LVIQE=; b=ie8XovtR85S+y54PtNAnC7VF8HrusnLnTAmq8dmG301NNfPVfVXkc1QpPMhI5DHOBz lMq5o9XPG9gSyAN0MA7/ywcGlzH+SMr/Ht8uqHgAsFRlD2yMnrqd5CMW3TdrmaXyUs9H o1OcP9tNYLukqFQ1hK4W5+U51pxtNKoltlnKVu7Jn/L45v5KVLtK561iTh6o5pHtTFQf KH4E3375xNRbvyQvvGbO96sPbRWH9Sh8WN1irJblhj6inhrY1u+4VBnsKlvuhl76ldz0 jwBTzDHQSN4alGDqwPZ6Fu6wJry5zcoPqVoKoAVcQPoEza69DLYuVI6Pe0JODRFBf50n MC3A== X-Gm-Message-State: ALoCoQk/0eY2g2uepXkQuTV/ASDqB+/3liEWKtQ/KXkr2rwh4/T+8pDtsUnQHDjfuill+QVSp+Dy X-Received: by 10.224.57.142 with SMTP id c14mr9556602qah.48.1421171955109; Tue, 13 Jan 2015 09:59:15 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAvWoxcGYjx9v/aTaGqPvcK+QHgBw== Date: Tue, 13 Jan 2015 12:59:14 -0500 Message-ID: To: pkyzivat@alum.mit.edu, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dispatch] draft-kyzivat-dispatch-trs-call-info-purpose-00: comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 17:59:27 -0000 Hi, The following are some comments concerning draft-kyzivat-dispatch-trs-call-info-purpose-00. Thanks, Brett ------ General comment: It might be better to introduce a new header instead of using Call-Info. For instance, is the following RFC 3261 section 20.9 recommendation acceptable for the new purpose value? "Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element." Section 2: Concerning the example, the sip-uri should be within brackets. Section 2: Concerning the example, the original-identity should not be within quotes. Section 3 paragraph 1: Comparing it to an identify header (instead of Contact) might be more accurate since it might be displayed to the user and has a billing impact. However, I guess that the same could be said about Contact and they both can be spoofed. From nobody Tue Jan 13 10:30:40 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388CB1A9034 for ; Tue, 13 Jan 2015 10:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BURQTmTG-nz for ; Tue, 13 Jan 2015 10:30:35 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id A355F1A902F for ; Tue, 13 Jan 2015 10:30:35 -0800 (PST) X-AuditID: 1207440d-f79976d000005643-d3-54b5644ad84f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 58.C4.22083.A4465B45; Tue, 13 Jan 2015 13:30:35 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0DIUYB4022002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 13:30:34 -0500 Message-ID: <54B5644A.4050807@alum.mit.edu> Date: Tue, 13 Jan 2015 13:30:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brett Tate , dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYndR1PVO2RpicGIho0Xz/H+MFksnLWB1 YPL4cTvQY8mSn0wBTFHcNkmJJWXBmel5+nYJ3BnNx/ezFhzkrTiyfAp7A+Mjri5GTg4JAROJ rbdOsEPYYhIX7q1n62Lk4hASuMwoMWP2ORYI5zmTxK838xhBqngFtCU+3fkM1sEioCpxYsY9 JhCbTUBLYs6h/ywgtqhAssSarZPYIeoFJU7OfAIU5+AQETCXmH+zEiQsLOAm0b1pNliJkICt xKpbf1hBbE4BO4mj334wg9jMAmYSXVu7GCFseYntb+cwT2Dkn4Vk6iwkZbOQlC1gZF7FKJeY U5qrm5uYmVOcmqxbnJyYl5dapGukl5tZopeaUrqJERKQvDsY/6+TOcQowMGoxMMrkLclRIg1 say4MvcQoyQHk5Ior2PQ1hAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryPzIFyvCmJlVWpRfkw KWkOFiVxXrUl6n5CAumJJanZqakFqUUwWT0ODoEvH899YhS49Kb7K6MUS15+XqqSBO+jRKBR gkWp6akVaZk5JQgNTBycIOu4pESKU/NSUosSS0sy4kFRG18MjFuQFA/QJZxJIJcUFyTmAkUh Wk8xKkqJ8z4EmSsAksgozYMbC0tFrxjFgf4W5j0GUsUDTGNw3a+ABjMBDV7cvhlkcEkiQkqq gXHy7TDnUoGg27M6FyZGHpIJ0LdVSFh/vEctOSmB/7HxpvjKB/P3/vMXOrNUZd7Wg59uHrxx zlD20sW5tqIbz/T9cGJdLTt93w7h2Wm8Xws/XhSv2nrlCNcxk65z4XMv6VW5aF/dcXiv6i7f yQG/YrcyOFgoGGoWeTRKGTlfqI39u2SuM9diw/tKLMUZiYZazEXFiQAR4TcMIAMAAA== Archived-At: Subject: Re: [dispatch] draft-kyzivat-dispatch-trs-call-info-purpose-00: comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:30:38 -0000 Brett, Thanks for commenting. On 1/13/15 12:59 PM, Brett Tate wrote: > Hi, > > The following are some comments concerning > draft-kyzivat-dispatch-trs-call-info-purpose-00. > > Thanks, > Brett > > ------ > > General comment: It might be better to introduce a new header instead of > using Call-Info. For instance, is the following RFC 3261 section 20.9 > recommendation acceptable for the new purpose value? > > "Therefore, it is RECOMMENDED that a UA only render the information in the > Call-Info > header field if it can verify the authenticity of the element that > originated the header field and trusts that element." So your concern is that with Call-Info the information might be rendered to the user? I don't think that is an important concern. Other purposes aren't intended for rendering. E.g. - list-management (RFC5367) - call-completion (RFC6910) - impp (RFC6993) (Though this might end up being rendered indirectly) - ccmp (RFC7082) IMO using Call-Info for original-identity seems in line with the other uses. > Section 2: Concerning the example, the sip-uri should be within brackets. > > Section 2: Concerning the example, the original-identity should not be > within quotes. Thanks for catching these. The fixes will be in the next version. > Section 3 paragraph 1: Comparing it to an identify header (instead of > Contact) might be more accurate since it might be displayed to the user > and has a billing impact. However, I guess that the same could be said > about Contact and they both can be spoofed. > Yes. I think making an analogy to the Identity header would raise lots of other concerns that aren't appropriate here. Thanks, Paul From nobody Wed Jan 14 06:20:29 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAC61B2C72 for ; Wed, 14 Jan 2015 06:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p5fIzPwXQVP for ; Wed, 14 Jan 2015 06:20:16 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BAE1A005B for ; Wed, 14 Jan 2015 06:20:16 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id j5so7092494qga.7 for ; Wed, 14 Jan 2015 06:20:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=aT9G5oIN0PAKDH+VUt1m3pb8XUP3Wa5zVA9KWzvwgNo=; b=XCF1kYlKDBQfIBK99iRbnx0wACLGJSx1cqOMWuYz1S2hGakNJ+D5snTaLmMYkJivZr ow7kv2WSN88IdBgpcCLi24cOfAs2mZ9sLDjtHKBeIu5BHJ0k5zbr6OeMWFCKxGtPmjLr rF57xtyGmOIpzld/2au1WeU5iKYJ4vi3BmgFJPDJMwzIv0qNASXuKEXVCRTSEhDWBH1j WIX6LBhl30XVOddys0yzIa/4bUwT8m4JMpzGl9tWlhKwlQMOx0OJeV8+L9DNcexUrhZq 8QTotyXa2+tEK+7vXIfJpJodM2mZerd/TdsMAbVVsisJEQxNjBHtTigjp3OEzqePhGQX sPSQ== X-Gm-Message-State: ALoCoQnvLFDhFQe49klG84eNZn5bk2fljgRpheL3/TLJHBDdDye7LS3YyRktVjbWSaEcQUKv5mDS X-Received: by 10.229.48.132 with SMTP id r4mr7119302qcf.5.1421245215864; Wed, 14 Jan 2015 06:20:15 -0800 (PST) From: Brett Tate References: <54B5644A.4050807@alum.mit.edu> In-Reply-To: <54B5644A.4050807@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLlksX9x+q0Vb275oXrT09hAgTT1QFRUMEEmopMDHA= Date: Wed, 14 Jan 2015 09:20:14 -0500 Message-ID: To: Paul Kyzivat , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] draft-kyzivat-dispatch-trs-call-info-purpose-00: comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 14:20:22 -0000 Hi, Thanks for the response; reply is inline. > > General comment: It might be better to introduce a new header > > instead of using Call-Info. For instance, is the following > > RFC 3261 section 20.9 recommendation acceptable for the new > > purpose value? > > > > "Therefore, it is RECOMMENDED that a UA only render the > > information in the Call-Info header field if it can verify the > > authenticity of the element that originated the header field > > and trusts that element." > > So your concern is that with Call-Info the information might be > rendered to the user? Actually, I couldn't tell from the draft if it was intended to be somehow rendered to the user or not. Similarly I'm not sure if any clients render Call-Info values if the purpose is unknown. > I don't think that is an important concern. Other purposes > aren't intended for rendering. E.g. > - list-management (RFC5367) > - call-completion (RFC6910) > - impp (RFC6993) (Though this might end up being rendered indirectly) > - ccmp (RFC7082) At first glance, it seems like they are some that would potentially be rendered to the user (directly or indirectly). > IMO using Call-Info for original-identity seems in line with > the other uses. I wasn't sure if you selected Call-Info for 1) potential rendering, 2) better B2BUA traversal, or 3) some other reason. From nobody Wed Jan 14 07:28:56 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1B81A8A05 for ; Wed, 14 Jan 2015 07:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YHNK4z7G4QJ for ; Wed, 14 Jan 2015 07:28:52 -0800 (PST) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id B9E391A89B5 for ; Wed, 14 Jan 2015 07:28:47 -0800 (PST) X-AuditID: 1207440e-f79bc6d000000c43-76-54b68b2e25d5 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E3.CA.03139.E2B86B45; Wed, 14 Jan 2015 10:28:47 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0EFSjPJ011241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 10:28:46 -0500 Message-ID: <54B68B2D.7040201@alum.mit.edu> Date: Wed, 14 Jan 2015 10:28:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brett Tate , dispatch@ietf.org References: <54B5644A.4050807@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYndR1NXv3hZi8PE9i0Xz/H+MFksnLWB1 YPL4cTvQY8mSn0wBTFHcNkmJJWXBmel5+nYJ3BnPmu6yFXwWqri+eitbA2MHfxcjJ4eEgInE sRlb2CBsMYkL99YD2VwcQgKXGSX+NTSxQzjPmSS291xlBKniFdCWmDfpPCuIzSKgKvHs6gdm EJtNQEtizqH/LCC2qECyxJqtk9gh6gUlTs58AhTn4BARMJeYf7MSJCws4CbRvWk21Px+Rokf +6aD9XIK2EnsfrYYbCazgJlE19YuRghbXmL72znMExj5ZyEZOwtJ2SwkZQsYmVcxyiXmlObq 5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5ihIQk3w7G9vUyhxgFOBiVeHhfHNwaIsSaWFZc mXuIUZKDSUmU907+thAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxPy4FyvCmJlVWpRfkwKWkO FiVxXrUl6n5CAumJJanZqakFqUUwWT0ODoEvH899YhS49Kb7K6MUS15+XqqSBO/zTqBRgkWp 6akVaZk5JQgNTBycIOu4pESKU/NSUosSS0sy4kFxG18MjFyQFA/QJYdB2nmLCxJzgaIQracY FaXEeVeBJARAEhmleXBjYcnoFaM40N/CvC9BqniAiQyu+xXQYCagwQ1JW0EGlyQipKQaGBkW RtzXClDMnVTwhIWH66ZStFqwf1/YzFklem0lHr1Jjh8r5yZOffl43SqvhbfuVU2tyXrTcPIJ 2+7KjRmXfG8p3Al2Phk8z1fyi+Tk7jvbFvFqBLxsX52ygbU8Ys8hi4jtr35NqXb5Gxxi9fPy FbZdiasvfYxPzNGcwL+alVGh4OnnmrsTQ5VYijMSDbWYi4oTAZmOZNEhAwAA Archived-At: Subject: Re: [dispatch] draft-kyzivat-dispatch-trs-call-info-purpose-00: comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 15:28:55 -0000 On 1/14/15 9:20 AM, Brett Tate wrote: > Hi, > > Thanks for the response; reply is inline. > >>> General comment: It might be better to introduce a new header >>> instead of using Call-Info. For instance, is the following >>> RFC 3261 section 20.9 recommendation acceptable for the new >>> purpose value? >>> >>> "Therefore, it is RECOMMENDED that a UA only render the >>> information in the Call-Info header field if it can verify the >>> authenticity of the element that originated the header field >>> and trusts that element." >> >> So your concern is that with Call-Info the information might be >> rendered to the user? > > Actually, I couldn't tell from the draft if it was intended to be somehow > rendered to the user or not. Similarly I'm not sure if any clients render > Call-Info values if the purpose is unknown. AFAIK each call-info purpose is expected to be handled independently based on its individual definition. For the built-in ones it clearly is not intended that the URI itself be rendered as a string. Rather then intent is that the URI be dereferenced and rendered in a purpose-specific way. Without knowing what the purpose-specific way is, you can't do anything useful with it. Presumably a receiving device that doesn't understand could decide to render the URI as a sort of "diagnostic". This is equally an issue for any newly specified purpose value. >> I don't think that is an important concern. Other purposes >> aren't intended for rendering. E.g. >> - list-management (RFC5367) >> - call-completion (RFC6910) >> - impp (RFC6993) (Though this might end up being rendered indirectly) >> - ccmp (RFC7082) > > At first glance, it seems like they are some that would potentially be > rendered to the user (directly or indirectly). As I noted above, that could be the case for impp, though a rich client will presumably simply use the URI to establish an xmpp session. Possibly the UI for the XMPP session might show that URI. This seems much less likely for list-management and call-completion. >> IMO using Call-Info for original-identity seems in line with >> the other uses. > > I wasn't sure if you selected Call-Info for 1) potential rendering, 2) > better B2BUA traversal, or 3) some other reason. For better B2BUA traversal. Do you have any suggestions on how to make this all clearer? Thanks, Paul From nobody Tue Jan 20 09:53:12 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC0B1B2AF8 for ; Tue, 20 Jan 2015 09:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW4iOLhcnxgy for ; Tue, 20 Jan 2015 09:53:04 -0800 (PST) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24A671B2AE2 for ; Tue, 20 Jan 2015 09:53:04 -0800 (PST) X-AuditID: 1207440c-f79376d00000680a-31-54be95ffb37f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 6F.89.26634.FF59EB45; Tue, 20 Jan 2015 12:53:03 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0KHr2fb028789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 20 Jan 2015 12:53:03 -0500 Message-ID: <54BE95FE.8090104@alum.mit.edu> Date: Tue, 20 Jan 2015 12:53:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> <54B54462.8060308@alum.mit.edu> In-Reply-To: <54B54462.8060308@alum.mit.edu> Content-Type: multipart/mixed; boundary="------------080705090503080103030502" X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa0wUVxTOnZldBmT0sixyuhgapr6qxZVqUlotGlQ0mhgfxEQxgRFGdsPu QGd2rfRP/WGbQINYCirLw02FDeADFcxaUAirsa5BBAEVIxoUCN1WUn+ItoXQeSxq7b/vnO9x 77kzhyYNfSEm2io4eFHgbKw+jDKErI+Lny5rS13+cIhNrC1x69aiTTU1fxHb0J5Zq/dxjgM7 rdmCOSljluX+0ZdkXiDp4L2mV7pDaHJlIQqlAa+ECf8k0vBc6H7cqC9EYbQB9yIYbjpDasU0 Ae7aHwlFxeCl0NPzWq9gCi+Ae1cL1b4eL4FK3zSl4CicCWculYRo+gjwlw+rfSOOgpN1P6v9 SJwIFb5BFRtwBlR3F+sUHIo/gV8f+lU9ibfBeF0BdRTNdr0T5XqHciFaxqtgolXU2h+C93kl qeHP4LuuUd3/+0nw/eMyvWIFHA1/H05xqeNnwEDLgJpuwGtg/E6pLFGmb0fgGaygtOIcgsPH /TqtqENQ4P2J0uwR0NlXFaLh6wT80xOniX5D0HTSo3MFn/tJ6QNCwQh/Cq1dgWBSPQEnagaC B15EMD0yGoxdDCfqu5FG9CG4ebuT1IoyBMXXi3X/fRnlNT6Gxhbz+1PrcSycDhxDLvU77IZm /6BqjcRpUH2nOXiYEcb7h0gNx8Dl552UdtVYeH3jGeFG8xtQLGdz2uPtnNUm8ZnxUiYnCLwY n7DMbnUs47OcF5H2V4ZfRhPn5vkQphEbzow1XE016LgDUr7dhz6gCTaK+aOkLdUwe19uVr6F kyzpotPGSz40X7700/Onu5GJEnIFnjUyjwpkHZPF5X/Di7kzshiaYqOZBTWLthpwNufgc3g+ jxdn2Hk0zQLzS6lsjBD5bP7gfqvN8ZYm6FAfAjrMZJR4IYsXOafDkq6sSrok74pChcvnehU7 I+VxdrmrWW+hOFM0064QWCEsTuFN7MwyBlC0PHEk862iCpdX9Y07IAcTcvDclitKsIN7S5kO oWTj1jVkVUd1+80j1p0dU81frIgYTJv8PCE31VxKbenZMwevc7+69lGOZ12aZ21X0YUN28tH 7rK3K5IbRnOOTGXWJu7YmDRkNw/ZNv8+RntHv9r1w4Vdp5KLLMVe6ku7w901tXDzKm+9t/zr FX/uPms5ey2maLjV79zb0ttoftG/w5PCUpKFS1hCihL3L4gEkYlnBAAA Archived-At: Subject: [dispatch] draft-kyzivat-dispatch-trs-call-info-purpose-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 17:53:07 -0000 This is a multi-part message in MIME format. --------------080705090503080103030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Based on feedback from the chairs and Brett Tate I have submitted an updated version of this draft. It gives more motivation and a list of requirements. Thanks, Paul On 1/13/15 11:14 AM, Paul Kyzivat wrote: > Dispatchers: > > I have just submitted a new draft (see below) that needs to be > dispatched. It defines a new Call-Info 'purpose' parameter value. > > The intended audience for this draft is quite limited - to the providers > of the Video Relay Service in the US, and to the FCC that sponsors that > service. The Intro section explains this. > > I'm hoping this can be dispatched without causing a lot of bother for > anybody. I don't anticipate that it needs time in Dallas. IIUC documents > of this sort are often AD sponsored. > > Thanks, > Paul > > -------- Original Message -------- > Subject: New Version Notification for > draft-kyzivat-dispatch-trs-call-info-purpose-00.txt > Date: Tue, 13 Jan 2015 07:46:47 -0800 > From: internet-drafts@ietf.org > To: Paul Kyzivat , "Paul Kyzivat" > > > > A new version of I-D, draft-kyzivat-dispatch-trs-call-info-purpose-00.txt > has been successfully submitted by Paul Kyzivat and posted to the > IETF repository. > > Name: draft-kyzivat-dispatch-trs-call-info-purpose > Revision: 00 > Title: Telecommunications Relay Service Purpose for the Call-Info > Header Field in the Session Initiation Protocol (SIP) > Document date: 2015-01-13 > Group: Individual Submission > Pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-info-purpose-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purpose/ > > Htmlized: > http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-purpose-00 > > > Abstract: > This document defines and registers a value of "original-identity" > for the "purpose" header field parameter of the Call-Info header > field in the Session Initiation Protocol (SIP). > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------080705090503080103030502 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: srs0=t1jh=ch=ietf.org=internet-drafts@alum.mit.edu Received: from reszmta-po-05v.sys.comcast.net (LHLO reszmta-po-05v.sys.comcast.net) (96.114.154.197) by resmail-ch2-746v.sys.comcast.net with LMTP; Tue, 20 Jan 2015 17:45:36 +0000 (UTC) Received: from resimta-po-23v.sys.comcast.net ([96.114.154.154]) by reszmta-po-05v.sys.comcast.net with comcast id iHkf1p0033L8Pe801HlcmB; Tue, 20 Jan 2015 17:45:36 +0000 Received: from alum-mailsec-relay-1.mit.edu ([18.7.68.21]) by resimta-po-23v.sys.comcast.net with comcast id iHlb1p01K0TXlVu01Hlbrb; Tue, 20 Jan 2015 17:45:36 +0000 X-CAA-SPAM: 00000 X-Authority-Analysis: v=2.1 cv=TuBohVnh c=1 sm=1 tr=0 a=Wi4y3NnR1l0PtLBv7sRrcQ==:117 a=14+JVjaIrF5vHQZXOdm4Ag==:17 a=C_IRinGWAAAA:8 a=GGcpBh7Jt_oA:10 a=cu4gVCrfnpsA:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=YNv0rlydsVwA:10 a=Ubr_DmNpJdcz6yveouAA:9 a=QEXdDO2ut3YA:10 Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by alum-mailsec-relay-1.mit.edu (8.14.7/8.12.8) with ESMTP id t0KHjEeK015820 for ; Tue, 20 Jan 2015 12:45:35 -0500 X-AuditID: 1207440e-f79bc6d000000c43-18-54be943ee297 Authentication-Results: symauth.service.identifier Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 5F.BE.03139.E349EB45; Tue, 20 Jan 2015 12:45:34 -0500 (EST) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1201ACE2F for ; Tue, 20 Jan 2015 09:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSQvi8Qg5FCr for ; Tue, 20 Jan 2015 09:45:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE09E1B2ABE; Tue, 20 Jan 2015 09:45:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Paul Kyzivat , "Paul Kyzivat" Subject: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120174531.24897.84139.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 09:45:31 -0800 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRWlGSWpSXmKPExsXCIn9MR9duyr4Qg9aFlhYrNhxgdWD0+Pv+ A1MAYxSXTUpqTmZZapG+XQJXxuXte5kLGrgqenZfYGtgfMPexcjJISFgInF/yg0mEJtRwEhi 97lXrBBxMYkL99azdTFycQgJrGSSmLHkJpSziVHi/9NnLBBVGhIzVl5ghEhcYZQ4cfYMM4Qz lVGi/0g/2CxeAUGJkzOfAHVwcDALaEqs36UPEmYWkJfY/nYOM4jNJiAnsfrVNEYQW0QgSGL3 1ENsILawQLTEvPNboJaJSLy7+pAZwpaW2PH2DAvE2XISP449BntBQEBA4t+kC2CreAUcJQ5f 8gAJswioSnye2co+gVFkFpKDZiEcNAvJQQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW6Rrr 5WaW6KWmlG5iBAa9ELsL3w7G9vUyhxgFOBiVeHhfrNobIsSaWFZcmXuIUZKDSUmU982kfSFC fEn5KZUZicUZ8UWlOanFhxglOJiVRHjvdALleFMSK6tSi/JhUtIcLErivGpL1P2EBNITS1Kz U1MLUotgskwc7IcYZTg4lCR4H4BMFixKTU+tSMvMKUFWwwkiuEDW8ACtEZ0Msqa4IDG3ODMd ougUoy7Hms17ZjIJseTl56VKifNeBZkmAFKUUZoHNwyWwC4xykoJ8zIyMDAI8QBdAwwEVPlH jIIcL9mF2LiYUvMEVKTAhr5iFAcGijBvL8h6nsy8Erjtr4AOYwI6TGzXHpDDShIRUlINjPOM /nleE9i5r2/iwn39DU/r7P7d0szyTm96ae7oKXTzdnz7Q1mtvEu9Gz8K9MntbwyVy3kTH9nQ sLjsV7h066SZLve/yN140JYxn9nw9tRNq58e6+OYONfghsc6lX0iK6QuqB95eu7d8Z/s+ds1 9xlbW3ddfujUctzpj+anWxe2S7q8/PzmymslluKMREMt5qLiRACF5sWrbwMAAA== A new version of I-D, draft-kyzivat-dispatch-trs-call-info-purpose-01.txt has been successfully submitted by Paul Kyzivat and posted to the IETF repository. Name: draft-kyzivat-dispatch-trs-call-info-purpose Revision: 01 Title: Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) Document date: 2015-01-20 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-info-purpose-01.txt Status: https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purpose/ Htmlized: http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-purpose-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-dispatch-trs-call-info-purpose-01 Abstract: This document defines and registers a value of "original-identity" for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------080705090503080103030502-- From nobody Tue Jan 20 13:13:42 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7164C1B2AB0; Tue, 20 Jan 2015 13:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLyFeTOVFe_d; Tue, 20 Jan 2015 13:13:39 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129471B2A0D; Tue, 20 Jan 2015 13:13:39 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so36707028lab.11; Tue, 20 Jan 2015 13:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HwA2aU6as90hyWGLm0snEWSmdWRJ7a89h6yiLeasbeY=; b=DCGeRhjy2ZqGccvpT54ee0AAn6NaENxNr/0pqvOvmsR0+8IkM84u/sImx/p3mN8uxm lWEygPrD5LW9K1RgsqHCWklQJQyr+6q0NzuMO16F2/iNaYQ8ORXhWUYKD2kiiJSGpyOQ +rUP2Xe+kNR3n1ItgxszFqfEGH774gyuk4LWh7jcGJL9sr8xoCK1nuT75+jphWnyzleZ deuaICBJRZjq6L15dXpGYkJgUoCVdleekTS7cZ5zOTT2uTPacGyzaQT/j6JHJWHDMIw1 yDAyUUA1Tn2xAPOqT9RgDOzLfmwuSRt1OOMSf0HxPvwjB4DkpP1i/Z8h6yN3AN+DprxU scjg== MIME-Version: 1.0 X-Received: by 10.112.55.199 with SMTP id u7mr39783114lbp.74.1421788417582; Tue, 20 Jan 2015 13:13:37 -0800 (PST) Received: by 10.25.170.193 with HTTP; Tue, 20 Jan 2015 13:13:37 -0800 (PST) In-Reply-To: <20150115235145.17162.58589.idtracker@ietfa.amsl.com> References: <20150115235145.17162.58589.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 15:13:37 -0600 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH Content-Type: multipart/alternative; boundary=001a1133fa76936a4f050d1be961 Archived-At: Subject: [dispatch] Fwd: NomCom 2014 - announcement of IESG positions X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 21:13:41 -0000 --001a1133fa76936a4f050d1be961 Content-Type: text/plain; charset=UTF-8 FYI...for folks that might not be on the IETF announcement or discussion lists. Regards, Mary. ---------- Forwarded message ---------- From: NomCom Chair 2014 Date: Thu, Jan 15, 2015 at 5:51 PM Subject: NomCom 2014 - announcement of IESG positions To: IETF Announcement List The 2014-15 IETF NomCom is pleased to announce its selection of the IESG members whose two year terms start at IETF 92 in March 2015. The NomCom thanks all the nominees and the community for the extensive and very valuable feedback. Please look for subsequent messages on IAOC and IAB, as those get confirmed. IESG was previously is now APP: Pete Resnick empty as requested INT: Ted Lemon Terry Manderson OPS: Joel Jaeggli Joel Jaeggli RAI: Richard Barnes Ben Campbell RTG: Adrian Farrel Alvaro Retana SEC: Stephen Farrell Stephen Farrell TSV: Spencer Dawkins Spencer Dawkins GEN/Chair: Jari Arkko Jari Arkko Combined with the existing members, this produces an IESG as follows: APP: Barry Leiba - Huawei INT: Terry Manderson - ICANN Brian Haberman - Johns Hopkins University OPS: Joel Jaeggli - Fastly Benoit Claise - Cisco RAI: Ben Campbell - Oracle Alissa Cooper - Cisco RTG: Alvaro Retana - Cisco Alia Atlas - Juniper Networks SEC: Stephen Farrell - Trinity College Dublin Kathleen Moriarty - EMC Corporation TSV: Spencer Dawkins - Huawei Martin Stiemerling - NEC & Darmstadt University GEN/Chair: Jari Arkko - Ericsson The new IESG will have three members from Cisco. Should the IESG have to go towards their (alternative) voting process, it is possible for a document to be blocked by three ADs voting "no". The IESG is in charge of its informal and formal rules, and could fix this in a variety of ways if it becomes necessary. The nomcom did not start its deliberations with any quotas or limits; rather, the NomCom asked who can best do the job, and went from there. The NOMCOM believes that the IESG members, new and old, can and will act as individuals, and will recuse themselves as appropriate. Evidence from past experience is that this has been true in the past as well. Michael Richardson NomCom Chair 2014-15 nomcom-chair-2014@ietf.org, mcr+nomcom@sandelman.ca --001a1133fa76936a4f050d1be961 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...for folks that might not be on the IETF announcement= or discussion lists.

Regards,
Mary.

---------- Forwarded message ----------
= From: NomCom Chair 2014 <nomcom-chair-2014@ietf.o= rg>
Date: Thu, Jan 15, 2015 at 5:51 PM
Subject: NomCom = 2014 - announcement of IESG positions
To: IETF Announcement List <ietf-announce@ietf.org>

The 2014-15 IETF NomCom is pleased to announce its selection of the IESG members whose two year terms start at IETF 92 in March 2015.

The NomCom thanks all the nominees and the community for the
extensive and very valuable feedback.

Please look for subsequent messages on IAOC and IAB, as those get confirmed= .

IESG was previously=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is now APP: Pete Resnick=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0emp= ty as requested
INT: Ted Lemon=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Terry Manderson
OPS: Joel Jaeggli=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Joe= l Jaeggli
RAI: Richard Barnes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ben Camp= bell
RTG: Adrian Farrel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alvaro R= etana
SEC: Stephen Farrell=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stephen Farre= ll
TSV: Spencer Dawkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Spencer Dawki= ns
GEN/Chair: Jari Arkko=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jari Arkko
Combined with the existing members, this produces an IESG as follows:

APP: Barry Leiba - Huawei
INT: Terry Manderson - ICANN
=C2=A0 =C2=A0 =C2=A0Brian Haberman=C2=A0 - Johns Hopkins University
OPS: Joel Jaeggli - Fastly
=C2=A0 =C2=A0 =C2=A0Benoit Claise -=C2=A0 Cisco
RAI: Ben Campbell - Oracle
=C2=A0 =C2=A0 =C2=A0Alissa Cooper -=C2=A0 Cisco
RTG: Alvaro Retana - Cisco
=C2=A0 =C2=A0 =C2=A0Alia Atlas - Juniper Networks
SEC: Stephen Farrell - Trinity College Dublin
=C2=A0 =C2=A0 =C2=A0Kathleen Moriarty - EMC Corporation
TSV: Spencer Dawkins - Huawei
=C2=A0 =C2=A0 =C2=A0Martin Stiemerling - NEC & Darmstadt University
GEN/Chair: Jari Arkko - Ericsson

The new IESG will have three members from Cisco.
Should the IESG have to go towards their (alternative) voting process, it i= s
possible for a document to be blocked by three ADs voting "no". T= he IESG is in
charge of its informal and formal rules, and could fix this in a variety of=
ways if it becomes necessary.

The nomcom did not start its deliberations with any quotas or limits;
rather, the NomCom asked who can best do the job, and went from there.

The NOMCOM believes that the IESG members, new and old, can and will act as=
individuals, and will recuse themselves as appropriate. Evidence from past<= br> experience is that this has been true in the past as well.

Michael Richardson
NomCom Chair 2014-15
nomcom-chair-2014@ietf.org, mcr+nomcom@sandelman.ca=


--001a1133fa76936a4f050d1be961-- From nobody Thu Jan 22 19:44:42 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8FF1A8F3E for ; Thu, 22 Jan 2015 19:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BbU1MtzmfMX for ; Thu, 22 Jan 2015 19:44:39 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7951A1A3C for ; Thu, 22 Jan 2015 19:44:37 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-09v.sys.comcast.net with comcast id jFkc1p0082LrikM01FkcnR; Fri, 23 Jan 2015 03:44:36 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-12v.sys.comcast.net with comcast id jFkc1p0021KKtkw01FkcLZ; Fri, 23 Jan 2015 03:44:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id t0N3iZC9004674; Thu, 22 Jan 2015 22:44:35 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t0N3iZTT004671; Thu, 22 Jan 2015 22:44:35 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <54B54462.8060308@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 22 Jan 2015 22:44:35 -0500 Message-ID: <87zj9ayxcs.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1421984676; bh=hZKN7Ah2da9T7DBplohpxJJ/JmDeXJMYz5Q+L67LLkk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=hAlwTyESopnCCi7WqUbTg52lZ13/LmXvdnFpuQx2xcgm2gAyrUCuBBQEqYMJf+dIf MAHtyV27LPQzX8cq9lBluikgWoxSnqhrY3D8u7HMg+P6kDvQ8OnrAMXK/tnIPdGM9H o7jb9+FBYjGyYK+7rNctk3ZzLbg1l6XxJDjEMs7V9kdbqXly+vnnS8BVjQYKpgzffC 6HPqAXjPyYIGPNCOhl+8k4DKG/ZG/BA6nLu7Tfw5ciyV6qZdAPg6N0waMvsK1UKpq/ f1/JJZg+FirNXOiWoY9YxMowXUp3I99ui7Iocsy00vRd4XxWr5hX4UQXDrH8SrmjKY i2SkBSYkRpSSA== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 03:44:40 -0000 Paul Kyzivat writes: > I have just submitted a new draft (see below) that needs to be > dispatched. It defines a new Call-Info 'purpose' parameter value. > > The intended audience for this draft is quite limited - to the providers > of the Video Relay Service in the US, and to the FCC that sponsors that > service. The Intro section explains this. The use of "original IP address" as the means to identify the caller seems rather odd to me. But I assume that this is what the FCC specifies, and they have good reason to do this. Given that: Should the 'purpose' value be "original-ip-address"? Should the draft specify that the URI must have the syntax "sip:" + IPv4address? It doesn't specify that now, although the usage has that restriction. What about IPv6 addresses? Or should we leave no restrictions on the URI to allow future improvements, and just note that the current practice is to use a very limited syntax? Dale From nobody Thu Jan 22 20:29:40 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3641A1AA5 for ; Thu, 22 Jan 2015 20:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfwuAENc3aAl for ; Thu, 22 Jan 2015 20:29:21 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 75E061A01A8 for ; Thu, 22 Jan 2015 20:29:21 -0800 (PST) X-AuditID: 1207440d-f79976d000005643-70-54c1ce206d33 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D7.33.22083.02EC1C45; Thu, 22 Jan 2015 23:29:20 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0N4TJLA023831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 23:29:20 -0500 Message-ID: <54C1CE1F.80001@alum.mit.edu> Date: Thu, 22 Jan 2015 23:29:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <87zj9ayxcs.fsf@hobgoblin.ariadne.com> In-Reply-To: <87zj9ayxcs.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYndR1FU4dzDEYNkHVYulkxawWrw8UebA 5DF5/1dmjyVLfjIFMEVx2yQllpQFZ6bn6dslcGd8mHGIqeAvd8WUGftYGxh3cXYxcnJICJhI fD+wnQ3CFpO4cG89kM3FISRwmVFi8bYrTBDOcyaJZVfmglXxCmhK3Lp1hrWLkYODRUBV4s/e WJAwm4CWxJxD/1lAbFGBZIk1WyexQ5QLSpyc+YQFpFwEqLVjQQ5ImFlAVGLm092MIGFhgVyJ v++jQcJCAkYSe9bMYwYJcwoYS3yexQliMgtYS3zbXQTRKC+x/e0c5gmMArOQjJ+FUDULSdUC RuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGCHhybuD8f86mUOMAhyMSjy8 GpsOhgixJpYVV+YeYpTkYFIS5X23DyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPfJAaAcb0pi ZVVqUT5MSpqDRUmcV22Jup+QQHpiSWp2ampBahFMVoaDQ0mCl/ksUKNgUWp6akVaZk4JQpqJ gxNkOJeUSHFqXkpqUWJpSUY8KD7ji4ERCpLiAdqrDtLOW1yQmAsUhWg9xagoJc778QxQQgAk kVGaBzcWlnReMYoDfSnMewGkigeYsOC6XwENZgIaXLD9AMjgkkSElFQD40TbLZNO3zF72yrC cSyt77fLjUVZIompc3k++F1IPfz6PrNQ/Wrm3QdVU7tcjI7wp3XEXyhZtPWYfq/c/5Rrrva9 c0sFc0UYV7QL1QbGLT25nftmhyD3umlFxxW8ftaHLD+ke13M0N58VVZGJJ+cadNmc0uez6nb Tk9czrb/ruFLoZ8h7EnlSizFGYmGWsxFxYkA5tlcbRUDAAA= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 04:29:28 -0000 On 1/22/15 10:44 PM, Dale R. Worley wrote: > Paul Kyzivat writes: >> I have just submitted a new draft (see below) that needs to be >> dispatched. It defines a new Call-Info 'purpose' parameter value. >> >> The intended audience for this draft is quite limited - to the providers >> of the Video Relay Service in the US, and to the FCC that sponsors that >> service. The Intro section explains this. > > The use of "original IP address" as the means to identify the caller > seems rather odd to me. But I assume that this is what the FCC > specifies, and they have good reason to do this. Given that: It is what it is, whether it makes sense or not. > Should the 'purpose' value be "original-ip-address"? > Should the draft specify that the URI must have the syntax "sip:" + > IPv4address? It doesn't specify that now, although the usage has that > restriction. What about IPv6 addresses? Or should we leave no > restrictions on the URI to allow future improvements, and just note that > the current practice is to use a very limited syntax? I was trying to make the mechanism at least a little less special purpose. In practice, when used for TRS, it will contain an IP address. But the mechanism doesn't need to be that specialized. Currently an IPv6 would be acceptable. And an h323 address might also make sense. (I included use cases for that.) And in some other context (without the FCC requirement) maybe a non-ip address would be ok. Thanks, Paul From nobody Fri Jan 23 11:11:33 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A206A1ACE2E for ; Fri, 23 Jan 2015 11:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l66c38l4yZ9v for ; Fri, 23 Jan 2015 11:11:03 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 067C11A8034 for ; Fri, 23 Jan 2015 11:10:58 -0800 (PST) Message-ID: From: Henning Schulzrinne To: Paul Kyzivat , "Dale R. Worley" Thread-Topic: [dispatch] Fwd: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt Thread-Index: AQHQNr7yZfDbsuPIpE279SUw3i0Yu5zNcKKAgACgFvk= Date: Fri, 23 Jan 2015 19:10:55 +0000 References: <87zj9ayxcs.fsf@hobgoblin.ariadne.com>, <54C1CE1F.80001@alum.mit.edu> In-Reply-To: <54C1CE1F.80001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 19:11:05 -0000 The IP address requirement, while crude, addresses the need to ascertain wh= ether the calling party is currently located in the United States since onl= y such calls are reimbursable. (VPNs are a well-known issue, but the concer= n is not so much that an there will be an occasional VPN user but wholesale= rule bypass. Almost all legitimate calls will originate from consumer or b= usiness end user addresses, not, say, cloud servers or other likely VPN ent= ities. There are well-known and pretty accurate IP address-to-country datab= ases, as well as databases of which ISP has the address. The number of VRS = users is sufficiently small that any odd-looking patterns can be investigat= ed manually.)=0A= =0A= Apparently, since other countries, including other countries in North Ameri= ca, do not offer the same level of VRS service, there's an incentive to "lo= an" accounts to friends and family elsewhere, or to use it by citizens livi= ng abroad.=0A= =0A= The idea is not "to identify the caller" as an individual; each caller is a= lready authenticating to the service.=0A= =0A= There could well be other uses for this, particularly as other proprietary = video communication systems are bridged into VRS.=0A= =0A= ________________________________________=0A= From: dispatch [dispatch-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzi= vat@alum.mit.edu]=0A= Sent: Thursday, January 22, 2015 11:29 PM=0A= To: Dale R. Worley=0A= Cc: dispatch@ietf.org=0A= Subject: Re: [dispatch] Fwd: New Version Notification for draft-kyzivat-dis= patch-trs-call-info-purpose-00.txt=0A= =0A= =0A= > The use of "original IP address" as the means to identify the caller=0A= > seems rather odd to me. But I assume that this is what the FCC=0A= > specifies, and they have good reason to do this. Given that:=0A= =0A= It is what it is, whether it makes sense or not.=0A= =0A= > Should the 'purpose' value be "original-ip-address"?=0A= =0A= =0A= > Should the draft specify that the URI must have the syntax "sip:" +=0A= > IPv4address? It doesn't specify that now, although the usage has that=0A= > restriction. What about IPv6 addresses? Or should we leave no=0A= > restrictions on the URI to allow future improvements, and just note that= =0A= > the current practice is to use a very limited syntax?=0A= =0A= I was trying to make the mechanism at least a little less special=0A= purpose. In practice, when used for TRS, it will contain an IP address.=0A= But the mechanism doesn't need to be that specialized.=0A= =0A= Currently an IPv6 would be acceptable. And an h323 address might also=0A= make sense. (I included use cases for that.) And in some other context=0A= (without the FCC requirement) maybe a non-ip address would be ok.=0A= =0A= =0A= =0A= =0A= Thanks,=0A= Paul=0A= From nobody Mon Jan 26 05:58:46 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359211A8906 for ; Mon, 26 Jan 2015 05:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFyHMommnYn3 for ; Mon, 26 Jan 2015 05:58:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9401A8AAF for ; Mon, 26 Jan 2015 05:58:39 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id EEA1E1904DB for ; Mon, 26 Jan 2015 14:58:35 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id D599F384049 for ; Mon, 26 Jan 2015 14:58:35 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Mon, 26 Jan 2015 14:58:36 +0100 From: To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt Thread-Index: AQHQNXI/TzIZMTr/aUuPWqfF7F6tsZzSNsxg Date: Mon, 26 Jan 2015 13:58:35 +0000 Message-ID: <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> In-Reply-To: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8142DC24APEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Subject: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 13:58:43 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8142DC24APEXCVZYM12corpo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQoNCg0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFm dCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2Ut Zm9yLXNlcnZpY2UtbnVtYmVyLTAxIChzZWUgYmVsb3cpLg0KDQoNCg0KWW91IGNhbiBzZWUgdGhl IGZvbGxvd2luZyBjaGFuZ2VzOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0gRWRpdG9yaWFsIGNvbW1lbnRzIGZyb20gdGhlIG1haWxp bmcgbGlzdCBoYXZlIGJlZW4gdGFrZW4gaW50byBhY2NvdW50DQoNCi0gTW9yZSBlZGl0b3JpYWwg Y2hhbmdlcyBoYXZlIGJlZW4gZG9uZSA6IHJlbWFpbmluZyAiaGVhZGVyIiBpbnRvICJoZWFkZXIg ZmllbGQiLCAiTVVTVCIgaW50byAibXVzdCIsDQoNCi0gQWZ0ZXIgSsO2cmdlbuKAmXMgY29tbWVu dCBhYm91dCB1c2FnZSBvZiB0aGlzIG5ldyBjYXVzZS1wYXJhbSB2YWx1ZSBpbiB0aGUgSGlzdG9y eS1JbmZvIGhlYWRlciBmaWVsZCB3aXRoIHRoZSBwcmUtcmVxdWlzdGUgb2YgdGhlICJtcCIgcGFy YW1ldGVyIG9yIG5vdCBJIGNoYW5nZWQgdGhlIHdheSB0byBkZWZpbmVkIHRoaXMgbmV3IHZhbHVl IHdpdGhvdXQgbWFraW5nIGEgcHJlLXJlcXVpc3RlIGNvbmRpdGlvbiBjb25jZXJuaW5nIHRoZSBo aS10YXJnZXQtcGFyYW0gdG8gYmUgdXNlZCAicmMiIG9yICJtcCIgaW4gdGhlIEhpc3RvcnktSW5m byBoZWFkZXItZmllbGQuDQoNCi0gSSBhbHNvIGFkZGVkIG1vcmUgdGV4dCBvbiB0aGUgZmFjdCB0 aGF0IHRoaXMgZG9jdW1lbnQgaXMgb25seSBhYm91dCB0aGUgY2F1c2UgVVJJIHBhcmFtZXRlciBh bmQgbm90IHRoZSBjYXVzZSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyIG9mIHRoZSBSZWFzb24gaGVh ZGVyLiBJbmRlZWQsIHRoZSBsYWNrIG9mIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhvc2Ug MiAiY2F1c2UiIHBhcmFtZXRlcnMgYnJvdWdodCBtYW55IGNvbmZ1c2lvbiBpbiB0aGUgcGFzdCBm b3IgdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgaW1wbGVtZW50YXRpb24uDQoNCi0gQWZ0ZXIgRGFs ZeKAmXMgY29tbWVudCBjb25jZXJuaW5nIHRoZSAiSU4iIHdvcmRpbmcgcmVmZXJlbmNlIGFuZCB2 b2NhYnVsYXJ5LCBJIGFkZGVkIHNvbWUgZXhwbGFuYXRvcnkgdGV4dCByZWZlcnJpbmcgdG8gUTEy MDEgdG8gZ2l2ZSBtb3JlIGJhY2tncm91bmQgdG8gdGhlIHJlYWRlciBvbiB0aGlzIG9sZCB3b3Jk aW5nIGFuZCB0aGUgbGluayB3aXRoIHRoZSBuZXcgdm9jYWJ1bGFyeS4NCg0KLSBBIGNvbXBsZXRl IGV4YW1wbGUgYmFzZWQgb24gdGhlIFRvbGwtRnJlZSBleGFtcGxlIGluIFJGQzcxMzEgaGFzIGJl ZW4gYWRkZWQuDQoNCg0KDQpJIGhvcGUgdGhpcyBuZXcgdmVyc2lvbiB3b3VsZCBiZSBmaW5lIGFu ZCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBzb21lIHJldmlldyBhbmQgZmVlZGJhY2sgb24gaXQuDQoN Cg0KDQpXaXRoIHRoZSBwcmV2aW91cyBmZWVkYmFja3MgYW5kIGludGVyZXN0cywgSSBob3BlIHRo aXMgZG9jdW1lbnQgY291bGQgaGF2ZSBhIGdvb2QgcHJvZ3Jlc3MgaW4gdGhlIHdvcmtpbmcgZ3Jv dXAgYW5kIGJlIHByZXNlbnRlZCBhdCB0aGUgbmV4dCBtZWV0aW5nLg0KDQoNCg0KDQoNCkJlc3Qg UmVnYXJkcywNCg0KTWFyaWFubmUNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K RGUgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddDQpFbnZvecOpIDogbWVyY3JlZGkgMjEgamFudmllciAyMDE1IDEzOjAzDQrDgCA6IE1P SEFMSSBNYXJpYW5uZSBJTVQvT0xOOyBNT0hBTEkgTWFyaWFubmUgSU1UL09MTg0KT2JqZXQgOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1m b3Itc2VydmljZS1udW1iZXItMDEudHh0DQoNCg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDEudHh0DQoN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyaWFubmUgTW9oYWxpIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KDQoNCk5hbWU6ICAgICAgICAgICAgICBk cmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyDQoNClJldmlzaW9u OiAgICAgICAgICAwMQ0KDQpUaXRsZTogICAgICAgICAgICAgICAgIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKSBDYXVzZSBVUkkgcGFyYW1ldGVyIGZvciBTZXJ2aWNlIE51bWJlciB0 cmFuc2xhdGlvbg0KDQpEb2N1bWVudCBkYXRlOiAgICAgICAgICAgIDIwMTUtMDEtMjENCg0KR3Jv dXA6ICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAgICAgICAg ICAgOA0KDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci0wMS50eHQN Cg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXIvDQoNCkh0bWxpemVkOiAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1 c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTAxDQoNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZp Y2UtbnVtYmVyLTAxDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgW1JGQzQ0NThdIGRlZmluZXMgYSAi Y2F1c2UiIFVSSSBwYXJhbWV0ZXIgYXMgaGF2aW5nIHByZWRlZmluZWQgdmFsdWVzDQoNCiAgIGZv ciBSZWRpcmVjdGluZyByZWFzb25zIGFzIGEgbWFwcGluZyBmcm9tIElUVS1UIFEuNzMyLjItNSBS ZWRpcmVjdGluZw0KDQogICBSZWFzb25zLiAgVGhlICJjYXVzZSIgVVJJIHBhcmFtZXRlciBpcyB0 byBiZSB1c2VkIGluIFNJUCBvciBTSVBzIFVSSS4NCg0KICAgSW4gcGFydGljdWxhciwgaXQgbWF5 IGFwcGVhciBpbiB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZA0KDQogICBkZWZpbmVkIGlu IFtSRkM3MDQ0XSB0aGF0IG11c3QgYmUgYWRkZWQgaW4gcmV0YXJnZXRlZCByZXF1ZXN0cy4NCg0K ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcgcHJlZGVmaW5lZCB2YWx1ZSBmb3Ig Y2FzZXMgd2hlbiB0aGUNCg0KICAgcmV0YXJnZXRpbmcgaXMgY2F1c2VkIGJ5IGEgc3BlY2lmaWMg c2VydmljZSBhY3Rpb24gbGVhZGluZyB0byBhDQoNCiAgIGNhbGxlZCBzZXJ2aWNlIGFjY2VzcyBu dW1iZXIgdHJhbnNsYXRpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDNDQ1OF0u DQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_8B970F90C584EA4E97D5BAAC9172DBB8142DC24APEXCVZYM12corpo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFp blRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCnNwYW4uVGV4dGVicnV0Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBicnV0IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJU ZXh0ZSBicnV0IjsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgYWxsLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFm dA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9oYWxpLWRpc3Bh dGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci0wMSI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTAxPC9h PiAoc2VlIGJlbG93KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+WW91IGNhbiBzZWUgdGhl IGZvbGxvd2luZyBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gRWRpdG9yaWFsIGNvbW1lbnRzIGZy b20gdGhlIG1haWxpbmcgbGlzdCBoYXZlIGJlZW4gdGFrZW4gaW50byBhY2NvdW50DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+LSBNb3JlIGVkaXRvcmlhbCBjaGFuZ2VzIGhhdmUgYmVlbiBkb25lIDogcmVtYWluaW5nICZx dW90O2hlYWRlciZxdW90OyBpbnRvICZxdW90O2hlYWRlciBmaWVsZCZxdW90OywgJnF1b3Q7TVVT VCZxdW90OyBpbnRvICZxdW90O211c3QmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gQWZ0ZXIgSsO2cmdlbuKA mXMgY29tbWVudCBhYm91dCB1c2FnZSBvZiB0aGlzIG5ldyBjYXVzZS1wYXJhbSB2YWx1ZSBpbiB0 aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCB3aXRoIHRoZSBwcmUtcmVxdWlzdGUgb2YgdGhl ICZxdW90O21wJnF1b3Q7IHBhcmFtZXRlciBvciBub3QgSSBjaGFuZ2VkIHRoZSB3YXkgdG8gZGVm aW5lZCB0aGlzIG5ldyB2YWx1ZSB3aXRob3V0IG1ha2luZyBhIHByZS1yZXF1aXN0ZQ0KIGNvbmRp dGlvbiBjb25jZXJuaW5nIHRoZSBoaS10YXJnZXQtcGFyYW0gdG8gYmUgdXNlZCAmcXVvdDtyYyZx dW90OyBvciAmcXVvdDttcCZxdW90OyBpbiB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlci1maWVsZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+LSBJIGFsc28gYWRkZWQgbW9yZSB0ZXh0IG9uIHRoZSBmYWN0IHRoYXQgdGhpcyBk b2N1bWVudCBpcyBvbmx5IGFib3V0IHRoZSBjYXVzZSBVUkkgcGFyYW1ldGVyIGFuZCBub3QgdGhl IGNhdXNlIGhlYWRlciBmaWVsZCBwYXJhbWV0ZXIgb2YgdGhlIFJlYXNvbiBoZWFkZXIuIEluZGVl ZCwgdGhlIGxhY2sgb2YgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiB0aG9zZSAyICZxdW90O2Nh dXNlJnF1b3Q7DQogcGFyYW1ldGVycyBicm91Z2h0IG1hbnkgY29uZnVzaW9uIGluIHRoZSBwYXN0 IGZvciB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBB ZnRlciBEYWxl4oCZcyBjb21tZW50IGNvbmNlcm5pbmcgdGhlICZxdW90O0lOJnF1b3Q7IHdvcmRp bmcgcmVmZXJlbmNlIGFuZCB2b2NhYnVsYXJ5LCBJIGFkZGVkIHNvbWUgZXhwbGFuYXRvcnkgdGV4 dCByZWZlcnJpbmcgdG8gUTEyMDEgdG8gZ2l2ZSBtb3JlIGJhY2tncm91bmQgdG8gdGhlIHJlYWRl ciBvbiB0aGlzIG9sZCB3b3JkaW5nIGFuZCB0aGUgbGluayB3aXRoIHRoZSBuZXcgdm9jYWJ1bGFy eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+LSBBIGNvbXBsZXRlIGV4YW1wbGUgYmFzZWQgb24gdGhlIFRvbGwtRnJlZSBl eGFtcGxlIGluIFJGQzcxMzEgaGFzIGJlZW4gYWRkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGhvcGUgdGhpcyBuZXcgdmVyc2lvbiB3b3VsZCBiZSBmaW5lIGFuZCBJIHdvdWxkIGxpa2Ug dG8gaGF2ZSBzb21lIHJldmlldyBhbmQgZmVlZGJhY2sgb24gaXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5XaXRoIHRoZSBwcmV2aW91cyBmZWVkYmFja3MgYW5kIGludGVyZXN0cywgSSBob3Bl IHRoaXMgZG9jdW1lbnQgY291bGQgaGF2ZSBhIGdvb2QgcHJvZ3Jlc3MgaW4gdGhlIHdvcmtpbmcg Z3JvdXAgYW5kIGJlIHByZXNlbnRlZCBhdCB0aGUgbmV4dCBtZWV0aW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TWFyaWFu bmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpGUiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KRGUm bmJzcDs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gPGJyPg0KRW52b3nDqSZuYnNwOzogbWVyY3JlZGkgMjEgamFudmllciAyMDE1IDEz OjAzPGJyPg0Kw4AmbmJzcDs6IE1PSEFMSSBNYXJpYW5uZSBJTVQvT0xOOyBNT0hBTEkgTWFyaWFu bmUgSU1UL09MTjxicj4NCk9iamV0Jm5ic3A7OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDEudHh0PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbW9oYWxpLWRpc3BhdGNo LWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyaWFu bmUgTW9oYWxpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtbW9oYWxp LWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIENhdXNlIFVSSSBwYXJhbWV0ZXIgZm9y IFNlcnZpY2UgTnVtYmVyIHRyYW5zbGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Eb2N1bWVudCBkYXRlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE1LTAxLTIxPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Q YWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1vaGFsaS1kaXNwYXRjaC1j YXVzZS1mb3Itc2VydmljZS1udW1iZXItMDEudHh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVt YmVyLTAxLnR4dDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdGF0dXM6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb2hhbGktZGlz cGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJl ci88L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SHRtbGl6ZWQ6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2Ut bnVtYmVyLTAxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVj b3JhdGlvbjpub25lIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb2hhbGktZGlz cGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTAxPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkRpZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2Ut bnVtYmVyLTAxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVj b3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tb2hh bGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTAxPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFtSRkM0NDU4XSBkZWZpbmVzIGEgJnF1b3Q7Y2F1c2Um cXVvdDsgVVJJIHBhcmFtZXRlciBhcyBoYXZpbmcgcHJlZGVmaW5lZCB2YWx1ZXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBmb3IgUmVkaXJlY3Rp bmcgcmVhc29ucyBhcyBhIG1hcHBpbmcgZnJvbSBJVFUtVCBRLjczMi4yLTUgUmVkaXJlY3Rpbmc8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBSZWFz b25zLiZuYnNwOyBUaGUgJnF1b3Q7Y2F1c2UmcXVvdDsgVVJJIHBhcmFtZXRlciBpcyB0byBiZSB1 c2VkIGluIFNJUCBvciBTSVBzIFVSSS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBpdCBtYXkgYXBwZWFyIGluIHRoZSBI aXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBbUkZDNzA0NF0gdGhhdCBtdXN0IGJlIGFk ZGVkIGluIHJldGFyZ2V0ZWQgcmVxdWVzdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcg cHJlZGVmaW5lZCB2YWx1ZSBmb3IgY2FzZXMgd2hlbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyByZXRhcmdldGluZyBpcyBjYXVzZWQgYnkg YSBzcGVjaWZpYyBzZXJ2aWNlIGFjdGlvbiBsZWFkaW5nIHRvIGE8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBjYWxsZWQgc2VydmljZSBhY2Nlc3Mg bnVtYmVyIHRyYW5zbGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDNDQ1OF0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_8B970F90C584EA4E97D5BAAC9172DBB8142DC24APEXCVZYM12corpo_-- From nobody Mon Jan 26 11:30:44 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CCE1ACEAD for ; Mon, 26 Jan 2015 11:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH--v2PzCevb for ; Mon, 26 Jan 2015 11:30:40 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 245041A90FA for ; Mon, 26 Jan 2015 11:30:39 -0800 (PST) X-AuditID: 1207440d-f79976d000005643-48-54c695df428c Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 35.0F.22083.FD596C45; Mon, 26 Jan 2015 14:30:39 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0QJUbA3012439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Jan 2015 14:30:39 -0500 Message-ID: <54C695DD.1050704@alum.mit.edu> Date: Mon, 26 Jan 2015 14:30:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqHt/6rEQg+ePRC2WTlrA6sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7oyfayayFLzUqfjRcoilgfGfchcjJ4eEgInE0RcbmCBsMYkL 99azdTFycQgJXGaUmLRuHSNIQkjgP5PEs3viIDavgLbE3WmbwBpYBFQlZm/ayQxiswloScw5 9J8FxBYVSJZYs3USO0S9oMTJmU/A4iICohLzVywCiwsLZEncnjSDBWLZbkaJ70f3MYM4nAJt jBKXFtxlBaliFrCVuDN3NzOELS/RvHU28wRG/llIBs9CUjYLSdkCRuZVjHKJOaW5urmJmTnF qcm6xcmJeXmpRbpGermZJXqpKaWbGCEhyLuD8f86mUOMAhyMSjy8Dc1HQ4RYE8uKK3MPMUpy MCmJ8ib3HwsR4kvKT6nMSCzOiC8qzUktPsQowcGsJMIrnQuU401JrKxKLcqHSUlzsCiJ86ot UfcTEkhPLEnNTk0tSC2CycpwcChJ8O6ZAtQoWJSanlqRlplTgpBm4uAEGc4lJVKcmpeSWpRY WpIRD4rK+GJgXIKkeID2zgBp5y0uSMwFikK0nmJUlBLn7QJJCIAkMkrz4MbCEssrRnGgL4V5 X4NU8QCTElz3K6DBTECD+1YeARlckoiQkmpgDKxbV/Du1XnL642zamXaJyyfrHV8zcEQDYvo Fz7XWtkDLi2Q+dN3TLZFj0//76+tmYV1X7p4iliKra5Ku8sWSbclt153/ftTqcAlJnPGxw27 C5pLbPJZtk7dKPdAc0at55xYV6lE5pAaY4c/IgmSwcHnyo8+/PLuTLNejI+//CKzrzy9/y4o sRRnJBpqMRcVJwIAy9k0XQcDAAA= Archived-At: Subject: Re: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 19:30:42 -0000 This makes more sense to me now than when I first read -00. (I don't know if it is because the text is better, or because of all the conversation in the meantime.) I do have a comment: The introduction now points out that the cause parameter can be used in the R-URI as well as in the History-Info header. But the solution only mentions the new cause parameter value being used in H-I. Is there a reason why it can't be used in the the R-URI? Also, in message F2 of the example, it *isn't* used in the R-URI of the retargeted request, even though it is included in the H-I entry containing that same URI. IIUC that URI in the H-I ought to match what is in the R-URI. Thanks, Paul On 1/26/15 8:58 AM, marianne.mohali@orange.com wrote: > Hi all, > > I have submitted a new version of the draft > http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-number-01 > (see below). > > You can see the following changes: > > ---------------------------------------------------- > > - Editorial comments from the mailing list have been taken into account > > - More editorial changes have been done : remaining "header" into > "header field", "MUST" into "must", > > - After Jörgen’s comment about usage of this new cause-param value in > the History-Info header field with the pre-requiste of the "mp" > parameter or not I changed the way to defined this new value without > making a pre-requiste condition concerning the hi-target-param to be > used "rc" or "mp" in the History-Info header-field. > > - I also added more text on the fact that this document is only about > the cause URI parameter and not the cause header field parameter of the > Reason header. Indeed, the lack of clear distinction between those 2 > "cause" parameters brought many confusion in the past for the > History-Info header implementation. > > - After Dale’s comment concerning the "IN" wording reference and > vocabulary, I added some explanatory text referring to Q1201 to give > more background to the reader on this old wording and the link with the > new vocabulary. > > - A complete example based on the Toll-Free example in RFC7131 has been > added. > > I hope this new version would be fine and I would like to have some > review and feedback on it. > > With the previous feedbacks and interests, I hope this document could > have a good progress in the working group and be presented at the next > meeting. > > Best Regards, > > Marianne > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Envoyé : mercredi 21 janvier 2015 13:03 > Ŕ : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN > Objet : New Version Notification for > draft-mohali-dispatch-cause-for-service-number-01.txt > > A new version of I-D, draft-mohali-dispatch-cause-for-service-number-01.txt > > has been successfully submitted by Marianne Mohali and posted to the > IETF repository. > > Name: draft-mohali-dispatch-cause-for-service-number > > Revision: 01 > > Title: Session Initiation Protocol (SIP) Cause URI > parameter for Service Number translation > > Document date: 2015-01-21 > > Group: Individual Submission > > Pages: 8 > > URL: > http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service-number-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number/ > > Htmlized: > http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-number-01 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-cause-for-service-number-01 > > Abstract: > > [RFC4458] defines a "cause" URI parameter as having predefined values > > for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting > > Reasons. The "cause" URI parameter is to be used in SIP or SIPs URI. > > In particular, it may appear in the History-Info header field > > defined in [RFC7044] that must be added in retargeted requests. > > This specification creates a new predefined value for cases when the > > retargeting is caused by a specific service action leading to a > > called service access number translation. > > This document updates [RFC4458]. > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Jan 29 06:40:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FAD1A0086 for ; Thu, 29 Jan 2015 06:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1e01b6OIvRz for ; Thu, 29 Jan 2015 06:40:55 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC4A1A038A for ; Thu, 29 Jan 2015 06:40:54 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-a5-54ca4674612f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 19.EA.04231.4764AC45; Thu, 29 Jan 2015 15:40:52 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.199]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 15:40:52 +0100 From: =?Windows-1252?Q?Jaime_Jim=E9nez?= To: Kovatsch Matthias Thread-Topic: [dispatch] Review of draft-jimenez-p2psip-coap-reload Thread-Index: Ac/3gYDEXGtUD/glRdqzegozose6XwFPCxQAD8LhRoA= Date: Thu, 29 Jan 2015 14:40:51 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B52A3EF5FF@MBX110.d.ethz.ch> <326CB7C2-90FC-448B-B181-63DA92FCA86E@ericsson.com> In-Reply-To: <326CB7C2-90FC-448B-B181-63DA92FCA86E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_81EC5568-FB6F-41BC-8838-E574207A4DA5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM+JvjW6J26kQg42TlCyWTlrAavHseQuj A5PHkiU/mTxuv57PHMAUxWWTkpqTWZZapG+XwJWx95l9wbLTjBWz7q9kaWA8uZGxi5GTQ0LA RGLZvqNsELaYxIV764FsLg4hgSOMEk+PdjJCOEsYJc6cX8AMUsUm4CrRsfQiK4gtIqAj8X/+ I7BJzAILGCUu3i8GsYUFnCT+v37M0sXIAVTjLPHyiR+EaSXx7aM4SAWLgKrEy437wTp5Bewl 3rS+ZwMpERKolViyVQ8kzCngIDH/A8RwRqDTvp9awwSxSFzi1pP5TBAni0g8vHga6nxRiZeP /7FC2EoSi25/ZgK5nllgCqPEsXkdzBC7BCVOznzCMoFRdBaSWbOQ1c1CUgdRlCTRufoIM4St LbFs4Wso20DiaecrVkxxfYk37+YwQdimEq+PfmSEsK0lZvw6yAZhK0pM6X7IvoCRexWjaHFq cXFuupGxXmpRZnJxcX6eXl5qySZGYEQf3PJbdwfj6teOhxgFOBiVeHgNFp0MEWJNLCuuzD3E KM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI//lveFftry9+bdE9Cm3lKO4 cn+Y2JaWVU92yaj/85vCsPGerJ3M7NWbu3pTf9+essh474e9jxQii5Yxlt+Me9yxX+5GbsnZ zdKJbI3bM57eDWMMXHpRPNPYNunK1PtfHxwOWv5u0qtGBZ/ncv3dL2YpKM1/5DetJv+ST7Xj 17ene118uJmNmJRYijMSDbWYi4oTAQhGBVTJAgAA Archived-At: Cc: =?Windows-1252?Q?Ari_Ker=E4nen?= , "dispatch@ietf.org" Subject: Re: [dispatch] Review of draft-jimenez-p2psip-coap-reload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 14:40:58 -0000 --Apple-Mail=_81EC5568-FB6F-41BC-8838-E574207A4DA5 Content-Type: multipart/alternative; boundary="Apple-Mail=_A301BC37-BBBC-4733-952A-7320C47CFB53" --Apple-Mail=_A301BC37-BBBC-4733-952A-7320C47CFB53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I just submitted the latest version of the draft: http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/ =46rom previous discussions I have gathered all the actionable items on = the draft. Reviewer: Thanks for your comments, they really helped to get the = whole idea. I think it would improve the draft when the introduction = clearly explains the layering (by also providing use cases) and lists = the features that CoAP will use from RELOAD (e.g., caching and that DNS = becomes obsolete and that the addresses are resolved in a completely = different way). [TODO:1] DONE Reviewer: The caching and discovery mechanisms do not appear to be = compatible with the normal CoAP mechanisms. I think from a programmers = point of view, this abstraction should be transparent, that is, the = programmer can use the same CoAP APIs and make the same requests to = achieve application goals as if there was no RELOAD network underneath. = Maybe this is the case, but it is hard to see with all the new IANA = considerations :) [TODO:2] DONE: Normal CoAP caching is done at the proxies (section 7), = RELOAD caching requires some form of structure of the data to be stored = in the overlay. I have removed the Resource type part of the IANA = considerations, when we first did the draft, CoAP=92s RD did not define = the proper way to name resource types. Now it does and we can use the = same resource types. The rest of the IANA considerations are for the = RELOAD part of the Usage, not the CoAP one. Reviewer: The main technical issue is then the use of URIs. Since = they mean something completely different in this draft, they need their = own scheme. A look at the alternative transports in CoRE might help = here, but it was also their main issue and I currently do not know if it = is resolved yet. [TODO:3] Right, this issue is still being discussed. That is why we = chose to use URIs in a way whose definition was stable. Reviewer: A secondary issue is the integration with resource = directories. I think, it would be good if normal RDs and RELOAD-RDs = could coexist and link to each other. This would mean they use the same = mechanisms BTW: Normal RDs are not distributed in the P2P sense, but they can be = mirrored and distributed like DNS servers. [TODO:4] Yes, that is an interesting idea, which would result in a = different approach to the whole issue than the one taken by the draft. = It may be worth exploring this space in the future, but we prefer to = stick to the traditional RELOAD usage in this draft. Reviewer: It might be useful to align the terminology for = constrained nodes with the LWIG terminology RFC 7228 (cf. LR-WPAN). + I will align the terms when applicable. Reviewer: The description for PN missing (used in figure and = probably a CoAP proxy node). + You are right, I should write that part too. [TODO:5] DONE Reviewer: The RELOAD term "rendezvous" is misleading, since the = described action is a simple lookup and not the establishment of a = connection. + I will change the title to Lookup instead of Rendezvous. [TODO:6] DONE Reviewer: CoAP "Nodes" to lower case + I will change that 4. Registering CoAP URIs Reviewer: "registering register" in first paragraph + I will change that 6. Forming a direct connection and reading data Reviewer: Title capitalization is missing for this section heading + I will change that [TODO:7] DONE Thanks! - - Jaime Jimenez On 10 Nov 2014, at 10:09, ejajimn wrote: > Hi Matthias, >=20 > Thank you for the comments, I still haven=92t modified the draft but I = will take them into account and forward you the modified version as soon = as it is done.=20 >=20 > Now regarding the link to the paper you forwarded. I have briefly = scanned through it and what they proposed is similar to our draft and = even more similar to our paper in 2012 = (http://link.springer.com/article/10.1186%2F1687-1499-2012-121) and the = DRD draft = (http://tools.ietf.org/html/draft-jimenez-distributed-resource-directory-0= 0.html). Of course now in late 2014 their approach introduces a lot of = new things from CoRE that we did not have back then. Seeing that other = people come up with this problem and similar solution is encouraging to = try to work on it some more. >=20 > The basic principle of having a distributed network of WSN islands is = the same as in our work. They also rely on a gateway that acts as CoAP = server/client/http proxy/=85and as a local RD on behalf of other CoAP = EPs in the WSN. They use the .well-known to link the EP resources to the = .well-known on the GW, which makes sense. The different part is that = they use two different DHT systems: DGT and DLS, the GW has to be a peer = on both of them. DGT ads the GPS coordinates to the mapping, making = discovery bind to the location of the device, this means that in = mobility scenarios it would not work alone. That is why they also use = DLS in parallel, to also have name resolution.=20 >=20 > In our draft we are only looking at the second case, and we already do = it very similarly as they do using DLS. Another issue is that we are = trying to marry RELOAD and CoAP, not only DHTs and CoAP. RELOAD has its = own quirks so I would suggest to keep the two differentiated even if = they are similar. However it would be great to have people collaborate = on DRD too. >=20 > Ciao, > - - Jaime Jimenez >=20 > On 03 Nov 2014, at 18:51, Kovatsch Matthias = wrote: >=20 >> Dear Gonzalo and Jaime, >> dear list >>=20 >> Thanks for your comments, they really helped to get the whole idea. I = think it would improve the draft when the introduction clearly explains = the layering (by also providing use cases) and lists the features that = CoAP will use from RELOAD (e.g., caching and that DNS becomes obsolete = and that the addresses are resolved in a completely different way). >>=20 >> I think I will need this update to better understand some of the = described features. The caching and discovery mechanisms do not appear = to be compatible with the normal CoAP mechanisms. I think from a = programmers point of view, this abstraction should be transparent, that = is, the programmer can use the same CoAP APIs and make the same requests = to achieve application goals as if there was no RELOAD network = underneath. Maybe this is the case, but it is hard to see with all the = new IANA considerations :) >>=20 >> The main technical issue is then the use of URIs. Since they mean = something completely different in this draft, they need their own = scheme. A look at the alternative transports in CoRE might help here, = but it was also their main issue and I currently do not know if it is = resolved yet. >>=20 >> A secondary issue is the integration with resource directories. I = think, it would be good if normal RDs and RELOAD-RDs could coexist and = link to each other. This would mean they use the same mechanisms >> BTW: Normal RDs are not distributed in the P2P sense, but they can be = mirrored and distributed like DNS servers. >>=20 >> I also stumbled upon this paper, which proposes a similar approach: >> = http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?tp=3D&arnumber=3D689957= 9 >> Are you aware of this work? Maybe there is something useful that can = be included in the draft. >>=20 >> Best regards >> Matthias >=20 --Apple-Mail=_A301BC37-BBBC-4733-952A-7320C47CFB53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,

I just submitted = the latest version of the draft:
http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/

=46rom previous discussions I have gathered all = the actionable items on the = draft.

Reviewer:  Thanks = for your comments, they really helped to get the whole idea. I think it = would improve the draft when the introduction clearly explains the = layering (by also providing use cases) and lists the features that CoAP = will use from RELOAD (e.g., caching and that DNS becomes obsolete and = that the addresses are resolved in a completely different = way).
[TODO:1] = DONE

Reviewer:  The = caching and discovery mechanisms do not appear to be compatible with the = normal CoAP mechanisms. I think from a programmers point of view, this = abstraction should be transparent, that is, the programmer can use the = same CoAP APIs and make the same requests to achieve application goals = as if there was no RELOAD network underneath. Maybe this is the case, = but it is hard to see with all the new IANA considerations = :)
[TODO:2] DONE:  Normal CoAP = caching is done at the proxies (section 7), RELOAD caching requires some = form of structure of the data to be stored in the overlay. I have = removed the Resource type part of = the IANA considerations, when we first did the draft, CoAP=92s RD did not define the proper way to name = resource types. Now it does and we can use the same resource = types. The rest of the IANA considerations are for the = RELOAD part of the Usage, not the CoAP = one.

Reviewer:  The main = technical issue is then the use of URIs. Since they mean something = completely different in this draft, they need their own scheme. A look = at the alternative transports in CoRE might help here, but it was also = their main issue and I currently do not know if it is resolved = yet.
[TODO:3] Right, this issue is still = being discussed. That is why we chose to use URIs in a way whose = definition was = stable.

Reviewer:  A = secondary issue is the integration with resource directories. I think, = it would be good if normal RDs and RELOAD-RDs could coexist and link to = each other. This would mean they use the same mechanisms
BTW: = Normal RDs are not distributed in the P2P sense, but they can be = mirrored and distributed like DNS = servers.
[TODO:4] Yes, that is an = interesting idea, which would result in a different approach to the = whole issue than the one taken by the draft. It may be worth exploring = this space in the future, but we prefer to stick to the traditional = RELOAD usage in this = draft.

Reviewer:   It = might be useful to align the terminology for constrained nodes with the = LWIG terminology RFC 7228 (cf. LR-WPAN).
+ I will align the = terms when applicable.
Reviewer:  The = description for PN missing (used in figure and probably a CoAP proxy = node).
+ You are right, I should write that part = too.
[TODO:5] = DONE

Reviewer:  The = RELOAD term "rendezvous" is misleading, since the described action is a = simple lookup and not the establishment of a connection.
+ I = will change the title to Lookup instead of = Rendezvous.
[TODO:6] = DONE

Reviewer:  =  CoAP "Nodes" to lower case
+ I will change = that
4. Registering CoAP URIs
Reviewer:  = "registering register" in first paragraph
+ I will = change that
6. Forming a direct connection and reading = data
Reviewer:  Title capitalization is missing = for this section heading
+ I will change = that
[TODO:7] = DONE


Thanks!
- - Jaime Jimenez

On 10 Nov 2014, at 10:09, ejajimn <jaime.jimenez@ericsson.com&= gt; wrote:

Hi = Matthias,

Thank you for the comments, I still haven=92t= modified the draft but I will take them into account and forward you = the modified version as soon as it is = done. 

Now regarding the link to the paper = you forwarded. I have briefly scanned through it and what they proposed = is similar to our draft and even more similar to our paper in 2012 (http:= //link.springer.com/article/10.1186%2F1687-1499-2012-121) and = the DRD draft (http://tools.ietf.org/html/draft-jimenez-distributed-resour= ce-directory-00.html). Of course now in late 2014 their approach = introduces a lot of new things from CoRE that we did not have back then. = Seeing that other people come up with this problem and similar solution = is encouraging to try to work on it some = more.

The basic principle of having a = distributed network of WSN islands is the same as in our work. They also = rely on a gateway that acts as CoAP server/client/http proxy/=85and as a = local RD on behalf of other CoAP EPs in the WSN. They use the = .well-known to link the EP resources to the .well-known on the GW, which = makes sense.  The different part is that they use two different DHT = systems: DGT and DLS, the GW has to be a peer on both of them. DGT ads = the GPS coordinates to the mapping, making discovery bind to the = location of the device, this means that in mobility scenarios it would = not work alone. That is why they also use DLS in parallel, to also have = name resolution. 

In our draft we are only = looking at the second case, and we already do it very similarly as they = do using DLS. Another issue is that we are trying to marry RELOAD and = CoAP, not only DHTs and CoAP. RELOAD has its own quirks so I would = suggest to keep the two differentiated even if they are similar. However = it would be great to have people collaborate on DRD = too.

Ciao,
- - Jaime Jimenez

On 03 Nov 2014, at 18:51, Kovatsch Matthias <kovatsch@inf.ethz.ch> = wrote:

Dear Gonzalo and Jaime,
dear list

Thanks for = your comments, they really helped to get the whole idea. I think it = would improve the draft when the introduction clearly explains the = layering (by also providing use cases) and lists the features that CoAP = will use from RELOAD (e.g., caching and that DNS becomes obsolete and = that the addresses are resolved in a completely different way).

I = think I will need this update to better understand some of the described = features. The caching and discovery mechanisms do not appear to be = compatible with the normal CoAP mechanisms. I think from a programmers = point of view, this abstraction should be transparent, that is, the = programmer can use the same CoAP APIs and make the same requests to = achieve application goals as if there was no RELOAD network underneath. = Maybe this is the case, but it is hard to see with all the new IANA = considerations :)

The main technical issue is then the use of = URIs. Since they mean something completely different in this draft, they = need their own scheme. A look at the alternative transports in CoRE = might help here, but it was also their main issue and I currently do not = know if it is resolved yet.

A secondary issue is the integration = with resource directories. I think, it would be good if normal RDs and = RELOAD-RDs could coexist and link to each other. This would mean they = use the same mechanisms
BTW: Normal RDs are not distributed in the = P2P sense, but they can be mirrored and distributed like DNS = servers.

I also stumbled upon this paper, which proposes a = similar approach:
http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?tp=3D&am= p;arnumber=3D6899579
Are you aware of this work? Maybe there is = something useful that can be included in the draft.

Best = regards
Matthias


= --Apple-Mail=_A301BC37-BBBC-4733-952A-7320C47CFB53-- --Apple-Mail=_81EC5568-FB6F-41BC-8838-E574207A4DA5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISLjCCBX0w ggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNVBAYTAkZJ MQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcxMDE4MTI1 MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVs aWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMK+6yfw IaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65ItqwA3GV1 7CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75Ljo1kB1c4 VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJjmhnXb88 lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c3TxHoLs1 iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+JWov3F0fU TPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0hADnJoWji UIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4pgd7gUY2 BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTwEhDcTwK7 EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVNAgMBAAGj ggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYDVR0gBBIw EDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1j5qWDNXr +nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVsaWFzb25l cmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxpYXNvbmVy YS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqGSIb3DQEB BQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4oPxOL9ZVG nhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMKziBdedr0 HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6pAKqZcnJf rI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqok3yH1wZh C+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF7zCCA9egAwIBAgIQaMOcrhMS zJ9bT5CvjeS9KjANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDkxMzIzMTFaFw0xNzEyMDkxMzIz MTBaMGkxETAPBgNVBAoMCEVyaWNzc29uMRcwFQYDVQQDDA5KYWltZSBKaW3DqW5lejEpMCcGCSqG SIb3DQEJARYaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VqYWppbW4wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDP0OJMI4KFvVthfKtVKePF9XFn40apqMV7MYZJ YBbJyCROSJV0e7sSTz2W6hQJT0Pwq6R5KXN4gW75N1wA3N6VY5SqbncOHrgp+i63GQjWDUU6Tz6j jm2MEWrDvGSdfIRSFn39cuppe5F3DuwK873VnTlHfuHAaGxw7szR+C+VG1YHFqpsL8iS+Oj48+q3 nOnH4YVqqwnT7hlBaOtvoj7x7wQDEKkuoH0eYIDO0j7OiD+3NpINB12BBWMsMCd2+cpHOJC86thz mS8keRfMtxYhMNiaLmlmuA1EEkvamiLBKilA+UXlsaNpFi7ZYHK1d7ZIMSPW+K6qlp7W/HLv4B1T AgMBAAGjggHAMIIBvDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNv bS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUH MAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjAlBgNVHREE HjAcgRpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB EjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29t L0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFDnygukSH/lWUDcy od3eCAbLZw+nMB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAgEAFwlz0hUpi0O2/EYNygVsAW816If5tFoS7V30FZGGO1vxkBTn zouaxLBuUf7atsVG2KyugpTCru1nKNC0KsvtGZrTIzvink81nuwZ+bPI1lPfeF9NkQOjtuMp1pSD QQsHNC+22Mgivu0FV/1yl04DI6QafeioYSiY+LNEOIqtcEPdXygyJtedANv3SGDxMmYtv2arJpGe 7XO3FXbnzmolRdc8C3W/qpTLbdX62Y4TsnMzGtDBrlS6mhL+a5pBKxHsS917ulcGDyMREzujhVkk gDssjnmiDJvfs7tbbOEhNfNseCNDMuhLoyieMg96AK/ekuB0vHTNeGlJRPX2qDYuZfWxdPEskFIm nl56/7HwHsfXi1ozwWmwBUYtxyy2M+7E5pt2Y01oS99IEvsY+1DlKKUNMx1vGG24U+U/7Wni08Lo D/zlhCjOpMoKCTbx6ajxS6lO3bwNmB8/lvvGkFueuwD/ZpFimZXYDLwE53yDg75k/RZkP3+8911Q MFg+kmJK6Up7q6PXm+yKIFjgPbvZVLR0ynBc6+aQopL9kCZqvLCTSHJuXaZv4Zbjnr43wIRJYPgk gcAGhfFUBprQZ0YTIvWVISbDuM5TaHlQCGWEeo+52lKhosmCpq14/YKFZga/8PCRH1tWm47yTWiF +MkDifSqDF86RZTbexmCjrj3kqMwgga2MIIEnqADAgECAhEAoAzLzJuZmOziOnD0fMHAWTANBgkq hkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEg Um9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZKFzoDkgTIVuhcxlb eUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCTu7CiMnfi0cuJf/JC iuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+ 25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicngZrxLowTbCBIFEOiX EBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo0+rn/IdpLjyMKw4E BTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechwx0gQXkG1QF5vMEkw wX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr8IZF2ncYemSDF84G +lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6m wOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0dyE+0G86tqH9xNbNf MaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0 cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEu Y2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4Bggr BgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYD VR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNv bmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5S J6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2 cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN06XqaUNslpMgQZqB 1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3 X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs5orjYfaJ87oREdsm ISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB47tDJA84joZvgVcD 2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY4if7vQX6q8qmabnZ 1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT 81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzOxnkkvyxRnvOCpiY0 w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBOMDoxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLM n1tPkK+N5L0qMAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE1MDEyOTE0NDA1MVowIwYJKoZIhvcNAQkEMRYEFH+H1VYmot0eV/fpRBIfUX/y 7653MF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEGjDnK4TEsyfW0+Qr43kvSowXwYLKoZIhvcNAQkQAgsx UKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFs IENBIHYyAhBow5yuExLMn1tPkK+N5L0qMA0GCSqGSIb3DQEBAQUABIIBAJYkz8YrhyxAvbo5mhrF /DUpTN6HGR2qfWqfs2XXoQJcoQvw4W21sbtP9jix3ByOHez2XIaqYRsrAjvREGAmYMs60L956wQg mC83ucJr1orLWyE2oTlsrxVqBRWFtTCmSBmpiGNropR6HE1nZgRlX7gxfWT1YPtJ89os+/7fP5v6 yjzq6CoRTekD14GZ34gofZl8st0ui0edFb3HyVAOU0eexaXQZ7z3FxLGWH/ZvsLcanT8Y4Y1EV4G oxuJLNpG3gcZhmNolZji5Bpi+5cL6fJgV+IM0F7AhvfR1fI8+wsLw+qh3eDVLgwMZ0DCmAmE53l3 Q3Of60sEZlt5IrKG0O0AAAAAAAA= --Apple-Mail=_81EC5568-FB6F-41BC-8838-E574207A4DA5--