From nobody Mon Feb 2 07:08: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 5B4E51A1B25 for ; Mon, 2 Feb 2015 07:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 O6timftEhrNR for ; Mon, 2 Feb 2015 07:07:44 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7514F1A1B3F for ; Mon, 2 Feb 2015 07:07:38 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id pv20so41604837lab.7 for ; Mon, 02 Feb 2015 07:07:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Wp4tee/NediKP6lHrfKdi/VpoI3kyipJeDahn+eWvrE=; b=bGcrBPauMQ2NPELwUqRVURcuSdevpU3SQRxjpUcvJl4g/htvboN34f+zbxXuQH2OR/ qs5a4NyBeMsmRsHt/eQ9yM/xlmmS24Dy0arDvYnBDx6zfwYrb+pSdzlr1WWs3Dyx/Qux 6yC/Thh82dDIKGn/TgfON0PSWAaeScHnDqvUa2l17+WmPUeT7Ujx6TTON30BixSIhofS L5xl4B/Z6H2J3VfoAMFn33aPZy2R/d0cwtDy+RmLPJ/WHpznkQP/m0/2Qvb+8E8GDmh7 GAiG3IGOdmuuHMewdt39bTMNXrgK4svJJZdrodH4n7zi4TPKJJuluDxhIDpdgXNXsMnJ FuhQ== X-Gm-Message-State: ALoCoQn8VUGMCSMDorULedkDoeZ1p4u8Lwq21A2lpA4pr/A6MS/ixcuUiOQZGt2glPXrJh+iO2/5 MIME-Version: 1.0 X-Received: by 10.152.20.169 with SMTP id o9mr20139745lae.50.1422889654213; Mon, 02 Feb 2015 07:07:34 -0800 (PST) Received: by 10.25.201.86 with HTTP; Mon, 2 Feb 2015 07:07:34 -0800 (PST) In-Reply-To: <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> <7594FB04B1934943A5C02806D1A2204B1D631E6A@ESESSMB209.ericsson.se> Date: Mon, 2 Feb 2015 10:07:34 -0500 Message-ID: From: Richard Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0141aa8a64f6ac050e1c5062 Archived-At: Cc: "dispatch@ietf.org" 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: Mon, 02 Feb 2015 15:07:57 -0000 --089e0141aa8a64f6ac050e1c5062 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey all, Thanks for a productive discussion. I appreciate Robert's concerns, and I think the text in -04 (as agreed below) strikes the right balance between defining something that is in principle usable on the Internet, while at the same time letting the reader know that it is unlikely in practice to be used outside of 3GPP networks. I have added this document to this week's telechat, with the following note in the ballot: """ In response to IETF LC feedback from Robert Sparks, the scoping language was adjusted to clarify that the only current usage of this parameter is in 3GPP networks, but it is also possible to use it in other deployments where its semantics make sense. The text change was discussed and agreed on the DISPATCH mailing list. """ Thanks, --Richard On Fri, Jan 9, 2015 at 12:24 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Great! Thanks! > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Paul Kyzivat > Sent: =E2=80=8E09/=E2=80=8E01/=E2=80=8E2015 18:51 > To: Christer Holmberg ; > R.Jesske@telekom.de; michael.hammer@yaanatech.com; dispatch@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 [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.s= x > > Subject: AW: [dispatch] Gen-art LC review: > draft-holmerg-dispatch-iotl-03.txt > > > > +1 > > > > Roland > > > > -----Urspr=C3=BCngliche 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 tru= e. > > 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 i= s > 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 witho= ut > success. I think it would require creating a framework that formalizes th= e > notion of "legs" in sip signaling. But the people who want this didn't se= em > 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=C3=BCngliche 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 > > > > --089e0141aa8a64f6ac050e1c5062 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

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

I have added this document to this week= 9;s telechat, with the following note in the ballot:
""= "
In response to IETF LC feedback from Robert Sparks, t= he scoping language=C2=A0
was adjusted to clarify that the only c= urrent usage of this parameter is in 3GPP
networks, but it is als= o possible to use it in other deployments where its semantics
mak= e sense.=C2=A0 The text change was discussed and agreed on the DISPATCH
mailing list.
"""

Thanks,
--Richard


On Fri, Jan 9, 2015 at 12:24 PM,= Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Great! Thanks!=

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =E2=80= =8E09/=E2=80=8E01/=E2=80=8E2015 18:51
To: Christer Holm= berg; R.Jesske@telekom.d= e; michael.hammer@yaanatech.com; dispatch@ietf.org; rjsparks@nostrum.= com; rlb@ipv.sx

Subject: Re: [d= ispatch] 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 tex= t?

yes

> Regards,
>
> Christer
>
> -----Original Message-----
> From: R.Jessk= e@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=C3=BCngliche Nachricht-----
> Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Christer Holmb= erg
> 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:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The SIP URI 'iotl&= #39; parameter defined in this document has known uses in 3GPP networks. >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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:dispatch-bounces@ietf.org] On Behalf Of Christer Holmbe= rg
> 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:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The SIP URI 'iotl&= #39; parameter defined in this document is only applicable to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3GPP networks. The usage of = the parameter within other types of networks is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 undefined."
>
> ...with:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The SIP URI 'iotl&= #39; parameter defined in this document it's not likely to be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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@ie= tf.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 In= ternet 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 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 effor= t on that, and I didn't sense any interest in doing so outside the 3gpp= community.
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 wh= at 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=C3=BCngliche 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 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 &qu= ot;the 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 usa= ge there 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
>>> dispatc= h@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatc= h@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>

--089e0141aa8a64f6ac050e1c5062-- From nobody Tue Feb 3 04:11:32 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 665891A00F1 for ; Tue, 3 Feb 2015 04:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.901 X-Spam-Level: X-Spam-Status: No, score=-103.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 hwOsb2n8LZJ9 for ; Tue, 3 Feb 2015 04:11:27 -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 6FB981A009E for ; Tue, 3 Feb 2015 04:11:26 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-e6-54d0baec59cb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DC.8B.04231.CEAB0D45; Tue, 3 Feb 2015 13:11:24 +0100 (CET) Received: from [131.160.36.87] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Tue, 3 Feb 2015 13:11:23 +0100 Message-ID: <54D0BAEB.8090008@ericsson.com> Date: Tue, 3 Feb 2015 14:11:23 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?windows-1252?Q?Jaime_Jim=E9nez?= , Kovatsch Matthias References: <55877B3AFB359744BA0F2140E36F52B52A3EF5FF@MBX110.d.ethz.ch> <326CB7C2-90FC-448B-B181-63DA92FCA86E@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvje6bXRdCDBomylu07tjEZLF00gJW i2fPWxgdmD2WLPnJ5HH79Xxmj2/XN7IGMEdx2aSk5mSWpRbp2yVwZfzre8RYsNuh4u/ObywN jEeNuxg5OSQETCR+zpvADGGLSVy4t56ti5GLQ0jgCKPE2sOToZxVjBIXH65lBaniFdCWuHjl NQuIzSKgInHowmcmEJtNwEJiy637YHFRgSiJ2ecfQNULSpyc+QQsLiKQL/F48lomkKHMAusZ Ja68+MkIkhAWcJL4//oxC8Q2oMSx70vAEpwCDhJ3Ol+C2cwCBhJHFs1hhbDlJZq3zga7Wwjo ouXPWlgmMArOQrJwFpKWWUhaFjAyr2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIDOSDW37r 7mBc/drxEKMAB6MSD+8GywshQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGanphakFsUXleak Fh9iZOLglGpgtCjxVuQ3OV8/qbcne9GyxI41fsumrivOF7+xQFpSwTRk4rG6HUGCRZuXNv3m yjms3nrMwKhbR9Qs5L9Gtqi2a/6ZW/rXv0/IvH7uTc17s96CaPNFnEuy2BSX+Tkf48wVqGi/ 7dd5/tKktqgZK7IqD/Tk3jL+H7PqfIP3C6sw58knzjpwzX2hxFKckWioxVxUnAgA5lN5r0UC AAA= Archived-At: Cc: =?windows-1252?Q?Ari_Ker=E4?= =?windows-1252?Q?nen?= , "dispatch@ietf.org" , Carlos Jesus Bernardos Cano 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: Tue, 03 Feb 2015 12:11:30 -0000 Hi, thanks Matthias for all your input. At this point, revision 07 of the draft (with a Security Considerations Section, which was missing in 06) addresses all the comments received. We are going to ask the document shepherd (Carlos in the cc:, who cochairs the P2PSIP WG) to initiate the publication request process. Thanks, Gonzalo On 29/01/2015 4:40 PM, Jaime Jiménez wrote: > Hi, > > I just submitted the latest version of the draft: > http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/ > > From 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’s 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, >> >> Thank you for the comments, I still haven’t 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-resource-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/…and 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 > > 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=&arnumber=6899579 >>> Are you aware of this work? Maybe there is something useful that can >>> be included in the draft. >>> >>> Best regards >>> Matthias >> > From nobody Tue Feb 3 06:40:31 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 AC0F51A0439 for ; Tue, 3 Feb 2015 06:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 oNSEj9rUbWdm for ; Tue, 3 Feb 2015 06:40:15 -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 E52681A19EF for ; Tue, 3 Feb 2015 06:39:56 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id CC3212AC16C; Tue, 3 Feb 2015 15:39:54 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B354038404E; Tue, 3 Feb 2015 15:39:54 +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; Tue, 3 Feb 2015 15:39:54 +0100 From: To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt Thread-Index: AQHQNXI/TzIZMTr/aUuPWqfF7F6tsZzSNsxggACKq4CADBivYA== Date: Tue, 3 Feb 2015 14:39:53 +0000 Message-ID: <23955_1422974394_54D0DDBA_23955_500_1_8B970F90C584EA4E97D5BAAC9172DBB8142F6155@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54C695DD.1050704@alum.mit.edu> In-Reply-To: <54C695DD.1050704@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 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: Tue, 03 Feb 2015 14:40:21 -0000 Hi Paul, Thank you for your feedback. You said: >The introduction now points out that the cause parameter can be used in th= e R-URI as well as in the History-Info header. But the solution only mentio= ns 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? [MM] Actually there is no particular reason but having no usage example I f= ocused the description on the usage we have in mind. In the same manner, RF= C4458 was more focused on a usage in the Request-URI towards voicemail than= in the History-Info for call forwarding service in general. If because it = is a SIP/SIPS URI header (in general), you think I should add some text to = give the same importance on its usage in a R-URI and/or in the History-Info= header, I can do it. Is it your point? If yes, I should add a warning tha= t usage in the R-URI would have some limitation in regards with usage in th= e H-I header having more capabilities to give the information on why, how t= he incoming request arrives with privacy information... >Also, in message F2 of the example, it *isn't* used in the R-URI of the re= targeted request, even though it is included in the H-I entry containing th= at same URI. IIUC that URI in the H-I >ought to match what is in the R-URI. [MM] No, the entry in the H-I is not mandatory to match exactly the one in = the R-URI. The entry in the R-URI is a minimum base to create the correspon= ding H-I entry. You can have a simple R-URI and when it is added in the new= H-I entry, the service can add some additional headers/parameters (eg. Rea= son, Privacy/ cause, target) in this entry or in the entry that retargeted = the request (identified by the hi-target-param) before sending the request = downstream. This example is exactly an example from RFC7131 with a usage of= the cause-param only in the History-Info header. Depending on your respons= e on the first point, I can add an example to show this new cause value in = a R-URI.=20 Best regards, Marianne -----Message d'origine----- De=A0: dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul Kyziv= at Envoy=E9=A0: lundi 26 janvier 2015 20:31 =C0=A0: dispatch@ietf.org Objet=A0: Re: [dispatch] New Version Notification for draft-mohali-dispatch= -cause-for-service-number-01.txt This makes more sense to me now than when I first read -00. (I don't know i= f it is because the text is better, or because of all the conversation in t= he 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 mention= s 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 ret= argeted request, even though it is included in the H-I entry containing tha= t 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-num > ber-01 > (see below). > > You can see the following changes: > > ---------------------------------------------------- > > - Editorial comments from the mailing list have been taken into=20 > account > > - More editorial changes have been done : remaining "header" into=20 > "header field", "MUST" into "must", > > - After J=F6rgen's comment about usage of this new cause-param value in= =20 > 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=20 > making a pre-requiste condition concerning the hi-target-param to be=20 > used "rc" or "mp" in the History-Info header-field. > > - I also added more text on the fact that this document is only about=20 > the cause URI parameter and not the cause header field parameter of=20 > the Reason header. Indeed, the lack of clear distinction between those=20 > 2 "cause" parameters brought many confusion in the past for the=20 > History-Info header implementation. > > - After Dale's comment concerning the "IN" wording reference and=20 > vocabulary, I added some explanatory text referring to Q1201 to give=20 > more background to the reader on this old wording and the link with=20 > the new vocabulary. > > - A complete example based on the Toll-Free example in RFC7131 has=20 > been added. > > I hope this new version would be fine and I would like to have some=20 > review and feedback on it. > > With the previous feedbacks and interests, I hope this document could=20 > have a good progress in the working group and be presented at the next=20 > meeting. > > Best Regards, > > Marianne > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Envoy=E9= =20 > : mercredi 21 janvier 2015 13:03 =C0 : MOHALI Marianne IMT/OLN; MOHALI=20 > Marianne IMT/OLN Objet : New Version Notification for=20 > draft-mohali-dispatch-cause-for-service-number-01.txt > > A new version of I-D,=20 > draft-mohali-dispatch-cause-for-service-number-01.txt > > has been successfully submitted by Marianne Mohali and posted to the=20 > 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-se > rvice-number-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-servi > ce-number/ > > Htmlized: > http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-num > ber-01 > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-mohali-dispatch-cause-for-servi > ce-number-01 > > Abstract: > > [RFC4458] defines a "cause" URI parameter as having predefined=20 > values > > for Redirecting reasons as a mapping from ITU-T Q.732.2-5=20 > 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=20 > 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=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > > The IETF Secretariat > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > > _______________________________________________ > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Thu Feb 5 02: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 CF6411A0122 for ; Thu, 5 Feb 2015 02:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.732 X-Spam-Level: X-Spam-Status: No, score=-77.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_WHITELIST=-100] 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 4h8BB7HJW1Js for ; Thu, 5 Feb 2015 02:29:36 -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 A165B1A00FE for ; Thu, 5 Feb 2015 02:29:35 -0800 (PST) Received: from [151.252.89.60] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 7919722 for dispatch@ietf.org; Thu, 05 Feb 2015 13:29:32 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Thu, 05 Feb 2015 15:29:02 +0500 MIME-Version: 1.0 Message-ID: <54D345EE.9747.3B18B34@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: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-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: Thu, 05 Feb 2015 10:29:38 -0000 Dear all, A long-awaited I-D is finally posted! I've spent 25 years to make a telephone a telephone, not this annoying box. ;) Surely, there are still issues to discuss. For instance, should Reason go to the body, or into header? Is NOTIFY an appropriate method there (or should be INFO)? There was a discussion for another I-D. Regards, Anton. ------- Forwarded message follows ------- From: internet-drafts@ietf.org To: "Anton Tveretin" , Anton Tveretin Subject: New Version Notification for draft-tveretin-dispatch-remote-00.txt Date sent: Thu, 05 Feb 2015 00:35:57 -0800 A new version of I-D, draft-tveretin-dispatch-remote-00.txt has been successfully submitted by Anton Tveretin and posted to the IETF repository. Name: draft-tveretin-dispatch-remote Revision: 00 Title: Remote Call Control and Call Pick-up in SIP Document date: 2015-02-05 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-00.txt Status: https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/ Htmlized: http://tools.ietf.org/html/draft-tveretin-dispatch-remote-00 Abstract: This memo defines a mechanism by which a SIP user agent could inspect calls at another user agent, and control a call, including picking up for itself. 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 ------- End of forwarded message ------- From nobody Thu Feb 5 10:03:11 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 134BA1A8A0B for ; Thu, 5 Feb 2015 09:59:18 -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 6zap-wNIjywG for ; Thu, 5 Feb 2015 09:59:16 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FCA1A8A23 for ; Thu, 5 Feb 2015 09:59:08 -0800 (PST) Received: from dhcp-169-229-230-156.lips.berkeley.edu ([169.229.230.156]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1YJQhk-0008V8-A5; Thu, 05 Feb 2015 09:59:05 -0800 Message-ID: <54D3AF68.4070803@berkeley.edu> Date: Thu, 05 Feb 2015 09:59:04 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <54D15A38.5050001@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 05 Feb 2015 10:03:10 -0800 Cc: Pete Resnick , metazool@fastmail.net, Sean Gillies , Barry Leiba Subject: Re: [dispatch] Forming and chartering a GeoJSON WG 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, 05 Feb 2015 17:59:20 -0000 hello. On 2015-02-03 16:40 , Richard Barnes wrote: > Sorry for the delay here. It looks like the next step here is to send a > charter proposal to the DISPATCH mailing list, dispatch@ietf.org we have had conversations about establishing an IETF WG for GeoJSON, which would be chartered with taking the current GeoJSON definition, and turning it into an IETF RFC. the next step in this process seems to be proposing a charter. please find the proposed charter in this email to dispatch@ietf.org, and it also is available online here: https://github.com/geojson/draft-geojson/blob/master/charter.md ============================================================== Proposed GeoJSON WG Charter GeoJSON GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). It was published at http://geojson.org in 2008. It has succeeded in streamlining geographic information system standards and making them accessible to practitioners of modern web development. GeoJSON today plays an important role in many spatial databases, web APIs, and open data platforms. This WG will work on a GeoJSON Format RFC that specifies the format more precisely and serves as a better guide for implementers. The work will start from an Internet-Draft written by the original authors. This I-D, draft-butler-geojson-04, substantially improves the format specification. The remaining tasks of the WG are: * Further clarification of the GeoJSON format specification. * Addition of implementation advice based on lessons learned since 2008. * geoAddition of more explicit extension advice to the specification. The addition of new features to the GeoJSON format is not within the scope of this WG. One possible exception to this (depending on WG consensus) is the adoption of JSON Text Sequences as an alternative way of serializing sets of GeoJSON objects. ============================================================== thanks a lot and kind regards, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Thu Feb 5 10:32:06 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 A474A1A898B for ; Thu, 5 Feb 2015 10:32:00 -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 CTtJFMMCzbcy for ; Thu, 5 Feb 2015 10:31:50 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 62CE61A1A7D for ; Thu, 5 Feb 2015 10:31:50 -0800 (PST) X-AuditID: 12074413-f79f26d0000030e7-93-54d3b71575e7 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E1.6F.12519.517B3D45; Thu, 5 Feb 2015 13:31:49 -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 t15IVmMU000820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Feb 2015 13:31:49 -0500 Message-ID: <54D3B714.6000509@alum.mit.edu> Date: Thu, 05 Feb 2015 13:31:48 -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: marianne.mohali@orange.com, "dispatch@ietf.org" References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54C695DD.1050704@alum.mit.edu> <23955_1422974394_54D0DDBA_23955_500_1_8B970F90C584EA4E97D5BAAC9172DBB8142F6155@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <23955_1422974394_54D0DDBA_23955_500_1_8B970F90C584EA4E97D5BAAC9172DBB8142F6155@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixO6iqCu6/XKIwYkDKhZLJy1gtdjWvI/J gcljyZKfTB4tz06yBTBFcdskJZaUBWem5+nbJXBnzP3xirVghX/Fpt6bbA2Msxy6GDk5JARM JBY82sMIYYtJXLi3nq2LkYtDSOAyo8TtA3tYQRJCAs+YJBY/qQWxeQW0JX7tW8sCYrMIqEoc v/eXDcRmE9CSmHPoP1hcVCBZYs3WSewQ9YISJ2c+AYuLCLhLXL2yCiwuLJAlcXvSDBaIZdeY JN7Oe84O4nAKtDNKfDz2GGgzBwezgLXEt91FIA3MAvISzVtnM09g5J+FZO4shKpZSKoWMDKv YpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgJSeEdjLtOyh1iFOBgVOLhfbD7 UogQa2JZcWXuIUZJDiYlUd64jZdDhPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw3mkGyvGmJFZW pRblw6SkOViUxHnVlqj7CQmkJ5akZqemFqQWwWRlODiUJHj/bQVqFCxKTU+tSMvMKUFIM3Fw ggznkhIpTs1LSS1KLC3JiAdFZHwxMCZBUjxAe6O2gewtLkjMBYpCtJ5iVJQS5+UHSQiAJDJK 8+DGwhLNK0ZxoC+FeYtAqniASQqu+xXQYCagwbIXL4AMLklESEk1MBocZLyz/2zD7BvtLg/c 3u22Cbt45sg0ydd/ZFYm381/F3r3d3xRhBLr1GefrW3+r2/SvjOxWYJp/0q9XYKOMe8uxIu1 hNYKur3Rrb+83DxDMIsn7FOxp/fLCXs4DJhyXgo+v3baRX/yTT/uAAX1D8sEzbuS932Xfjfr u6yep+QVYcaNH2UX3FdiKc5INNRiLipOBABD54GPDwMAAA== 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: Thu, 05 Feb 2015 18:32:00 -0000 Hi Marianne, On 2/3/15 9:39 AM, marianne.mohali@orange.com wrote: > Hi Paul, > > Thank you for your feedback. > > You said: > >> 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? > [MM] Actually there is no particular reason but having no usage example I focused the description on the usage we have in mind. In the same manner, RFC4458 was more focused on a usage in the Request-URI towards voicemail than in the History-Info for call forwarding service in general. If because it is a SIP/SIPS URI header (in general), you think I should add some text to give the same importance on its usage in a R-URI and/or in the History-Info header, I can do it. Is it your point? If yes, I should add a warning that usage in the R-URI would have some limitation in regards with usage in the H-I header having more capabilities to give the information on why, how the incoming request arrives with privacy information... > >> 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. > [MM] No, the entry in the H-I is not mandatory to match exactly the one in the R-URI. The entry in the R-URI is a minimum base to create the corresponding H-I entry. You can have a simple R-URI and when it is added in the new H-I entry, the service can add some additional headers/parameters (eg. Reason, Privacy/ cause, target) in this entry or in the entry that retargeted the request (identified by the hi-target-param) before sending the request downstream. This example is exactly an example from RFC7131 with a usage of the cause-param only in the History-Info header. Depending on your response on the first point, I can add an example to show this new cause value in a R-URI. I realize there is no *requirement* that the parameters be in the R-URI before that is moved into the H-I header. But it still seems to me to be the *intent* of H-I that the URIs included in it were ones that were used during the past history of the request. So IMO stuffing extra URI parameters in when putting the URI into H-I is an abuse or at least a hack. In the case of F2, I can see no reason why the parameter would not be appropriate for use in the R-URI. I would expect the recipient would look there first, and then, if not found there, look back into the H-I for evidence of a cause earlier in the history of the request. Thanks, Paul > Best regards, > Marianne > > -----Message d'origine----- > De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul Kyzivat > Envoyé : lundi 26 janvier 2015 20:31 > À : dispatch@ietf.org > Objet : Re: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt > > 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-num >> ber-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-se >> rvice-number-01.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-servi >> ce-number/ >> >> Htmlized: >> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-num >> ber-01 >> >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-cause-for-servi >> ce-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 >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Fri Feb 6 08:39:05 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 8809C1A6F30 for ; Fri, 6 Feb 2015 08:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 qxVriNt5NnyH for ; Fri, 6 Feb 2015 08:38:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B06D1A6F3A for ; Fri, 6 Feb 2015 08:38:55 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 8AFD91B81B6; Fri, 6 Feb 2015 17:38:53 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 6CE4C18008F; Fri, 6 Feb 2015 17:38:53 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 6 Feb 2015 17:38:53 +0100 From: To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt Thread-Index: AQHQNXI/TzIZMTr/aUuPWqfF7F6tsZzSNsxggACKq4CADBivYIADjjIAgAEViIA= Date: Fri, 6 Feb 2015 16:38:52 +0000 Message-ID: <4397_1423240733_54D4EE1D_4397_4876_2_8B970F90C584EA4E97D5BAAC9172DBB8142F8C5B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54C695DD.1050704@alum.mit.edu> <23955_1422974394_54D0DDBA_23955_500_1_8B970F90C584EA4E97D5BAAC9172DBB8142F6155@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54D3B714.6000509@alum.mit.edu> In-Reply-To: <54D3B714.6000509@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.6.133922 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: Fri, 06 Feb 2015 16:39:03 -0000 Hi Paul, [MM2] > -----Message d'origine----- > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy=E9=A0: jeudi 5 f=E9vrier 2015 19:32 > =C0=A0: MOHALI Marianne IMT/OLN; dispatch@ietf.org > Objet=A0: Re: [dispatch] New Version Notification for draft-mohali-dispat= ch-cause-for- > service-number-01.txt >=20 > Hi Marianne, >=20 > On 2/3/15 9:39 AM, marianne.mohali@orange.com wrote: > > Hi Paul, > > > > Thank you for your feedback. > > > > You said: > > > >> The introduction now points out that the cause parameter can be used i= n 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? > > [MM] Actually there is no particular reason but having no usage example= I > focused the description on the usage we have in mind. In the same manner, > RFC4458 was more focused on a usage in the Request-URI towards voicemail = than > in the History-Info for call forwarding service in general. If because it= is a SIP/SIPS > URI header (in general), you think I should add some text to give the same > importance on its usage in a R-URI and/or in the History-Info header, I c= an do it. Is > it your point? If yes, I should add a warning that usage in the R-URI wo= uld have > some limitation in regards with usage in the H-I header having more capab= ilities to > give the information on why, how the incoming request arrives with privacy > information... > > > >> 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 containin= g that same > URI. IIUC that URI in the H-I >ought to match what is in the R-URI. > > [MM] No, the entry in the H-I is not mandatory to match exactly the one= in the R- > URI. The entry in the R-URI is a minimum base to create the corresponding= H-I > entry. You can have a simple R-URI and when it is added in the new H-I en= try, the > service can add some additional headers/parameters (eg. Reason, Privacy/ = cause, > target) in this entry or in the entry that retargeted the request (identi= fied by the hi- > target-param) before sending the request downstream. This example is exac= tly an > example from RFC7131 with a usage of the cause-param only in the History-= Info > header. Depending on your response on the first point, I can add an examp= le to > show this new cause value in a R-URI. > I realize there is no *requirement* that the parameters be in the R-URI b= efore that is > moved into the H-I header. But it still seems to me to be the *intent* of= H-I that the > URIs included in it were ones that were used during the past history of t= he request. > So IMO stuffing extra URI parameters in when putting the URI into H-I is = an abuse > or at least a hack. [MM2] IMO, they are 3 points that we have to distinct:=20 1) There are headers that H-I RFC clearly mandate (with a *MUST*) to be add= ed in the URI into the H-I only (Reason and Privacy headers). 2) There are SIP URI parameters that can be present in the R-URI anyway ('c= ause' and 'target' parameters included).=20 3) There are H-I parameters that can be added only in the H-I header entrie= s. IIUC, your point concerns only 2).=20 Indeed, I think RFC4458 was principally designed to use the 'cause' paramet= er in the R-URI (maybe because it was discussed in // of H-I when it was a = draft) but it is not mentioned as a requirement and for several reasons it = has been understood and interpreted as a parameter that can be present eith= er only in the History-Info (as 3GPP use it) or in the R-URI and so automat= ically included in the H-I (as a copy of the R-URI). So usage in the Histor= y-Info is the minimum. As an example, when privacy must be applied, RFC4458 states that the cause = parameter must be removed from the R-URI whereas having it in the H-I enabl= e to keep this forwarding reason but indicating the requested Privacy with = the priv-value "history". So terminating entities that would rely on this p= arameter value, will go directly into the H-I to be sure to find it...and s= o why have it in the R-URI... IMO, having this 'cause' in the R-URI + H-I or only H-I should be an implem= entor choice. Anyway, I have no problem with adding an example with the 'cause' both in R= -URI and H-I in the draft and adding an explicit sentence to state that thi= s 'cause' param can be only in H-I or in the R-URI copied in H-I. FYI, in the Voicemail example (section 3.6) of RFC7131 you can find the fol= lowing call flow where there is no "cause" parameter in the R-URI but it is= present in the corresponding hi-entry. F4 INVITE example.com -> Carol INVITE sip:carol@192.0.2.4 SIP/2.0 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK4522 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 Max-Forwards: 69 From: Alice ;tag=3Dkkaz- To: Bob Supported: histinfo Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;index=3D1.2.1;rc=3D1.2 Contact: Alice Content-Type: application/sdp Content-Length: [SDP Not Shown] > In the case of F2, I can see no reason why the parameter would not be app= ropriate > for use in the R-URI. I would expect the recipient would look there first= , and then, if > not found there, look back into the H-I for evidence of a cause earlier i= n the history > of the request. [MM2] Actually, many recipients directly go through H-I to have the cause i= nformation (avoiding the double check). In 3GPP specification it is describ= ed as to be added in the H-I with no specific requirement on its adding in = the R-URI. At the end, my feeling is that the 'cause' parameter is optional= in the R-URI. However, if this new draft can be the opportunity to give some clarificatio= ns, I would be happy to add them in the text but I think it should not brin= g contradictory information with existing texts.=20 BR, Marianne >=20 > Thanks, > Paul >=20 > > Best regards, > > Marianne > > > > -----Message d'origine----- > > De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul > > Kyzivat Envoy=E9 : lundi 26 janvier 2015 20:31 =C0 : dispatch@ietf.org > > Objet : Re: [dispatch] New Version Notification for > > draft-mohali-dispatch-cause-for-service-number-01.txt > > > > 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 b= e 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-nu > >> m > >> ber-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=F6rgen'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=E9 > >> : mercredi 21 janvier 2015 13:03 =C0 : 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-s > >> e > >> rvice-number-01.txt > >> > >> Status: > >> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-serv > >> i > >> ce-number/ > >> > >> Htmlized: > >> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-nu > >> m > >> ber-01 > >> > >> Diff: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-mohali-dispatch-cause-for-serv > >> i > >> ce-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 q= ue les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. 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 > >> > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > 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 qu= e les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. 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 b= een > modified, changed or falsified. > > Thank you. > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Fri Feb 6 09:47:38 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 ADF731A700C for ; Fri, 6 Feb 2015 09:47:35 -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 vyYyBC_w_Kjv for ; Fri, 6 Feb 2015 09:47:31 -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 92A4A1A7D84 for ; Fri, 6 Feb 2015 09:47:30 -0800 (PST) X-AuditID: 1207440e-f79bc6d000000c43-d6-54d4fe31bf6c 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 3D.3F.03139.13EF4D45; Fri, 6 Feb 2015 12:47:29 -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 t16HlSnU030757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2015 12:47:29 -0500 Message-ID: <54D4FE30.9050304@alum.mit.edu> Date: Fri, 06 Feb 2015 12:47:28 -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: marianne.mohali@orange.com, "dispatch@ietf.org" References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54C695DD.1050704@alum.mit.edu> <23955_1422974394_54D0DDBA_23955_500_1_8B970F90C584EA4E97D5BAAC9172DBB8142F6155@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54D3B714.6000509@alum.mit.edu> <4397_1423240733_54D4EE1D_4397_4876_2_8B970F90C584EA4E97D5BAAC9172DBB8142F8C5B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <4397_1423240733_54D4EE1D_4397_4876_2_8B970F90C584EA4E97D5BAAC9172DBB8142F8C5B@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixO6iqGv470qIwcznZhZLJy1gtdjWvI/J gcljyZKfTB4tz06yBTBFcdskJZaUBWem5+nbJXBnbGv8yFpwqoWxYsf8I0wNjF+zuhg5OCQE TCSWP9ftYuQEMsUkLtxbz9bFyMUhJHCZUeLz+6/sEM4zJolFK1ewgzTwCmhL/H7AAdLAIqAq cf/7QSYQm01AS2LOof8sILaoQLLEmq2T2EFsXgFBiZMzn4DFRQTcJa5eWQUWFxbIkrg9aQYL xPwPzBLLp1xlA0lwCrQxSizdmAiyi1nAWuLb7iKQMLOAvETz1tnMExj5ZyEZOwuhahaSqgWM zKsY5RJzSnN1cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxQgKSbwdj+3qZQ4wCHIxKPLwJ vFdChFgTy4orcw8xSnIwKYnyXnkCFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC27MUKMebklhZ lVqUD5OS5mBREudVW6LuJySQnliSmp2aWpBaBJOV4eBQkuBNeg3UKFiUmp5akZaZU4KQZuLg BBnOJSVSnJqXklqUWFqSEQ+Kx/hiYESCpHiA9vZ+BNlbXJCYCxSFaD3FqCglztsAkhAASWSU 5sGNhaWZV4ziQF8K8678AFTFA0xRcN2vgAYzAQ1eDPZQcUkiQkqqgXHD1e1f3tjWTFsu8mal 3rL7bDYilTLXFU6xes3fUeS9Mnvr7tonfT8Kuz/cnLrArqvQKSsmYnHDucLLAsL3AkIs5JVT 3V5FvVwTuvmgwLV3oko/ta9xsGryO72csMzL//zJsndXzENeHmZUP6q6qHLptujVgTWneHTY XTosZkqteLXs/vdNj/yVWIozEg21mIuKEwGkzOk6DgMAAA== 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: Fri, 06 Feb 2015 17:47:35 -0000 Hi Marianne, Further discussion inline. On 2/6/15 11:38 AM, marianne.mohali@orange.com wrote: > Hi Paul, > > [MM2] > >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Envoyé : jeudi 5 février 2015 19:32 >> À : MOHALI Marianne IMT/OLN; dispatch@ietf.org >> Objet : Re: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for- >> service-number-01.txt >> >> Hi Marianne, >> >> On 2/3/15 9:39 AM, marianne.mohali@orange.com wrote: >>> Hi Paul, >>> >>> Thank you for your feedback. >>> >>> You said: >>> >>>> 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? >>> [MM] Actually there is no particular reason but having no usage example I >> focused the description on the usage we have in mind. In the same manner, >> RFC4458 was more focused on a usage in the Request-URI towards voicemail than >> in the History-Info for call forwarding service in general. If because it is a SIP/SIPS >> URI header (in general), you think I should add some text to give the same >> importance on its usage in a R-URI and/or in the History-Info header, I can do it. Is >> it your point? If yes, I should add a warning that usage in the R-URI would have >> some limitation in regards with usage in the H-I header having more capabilities to >> give the information on why, how the incoming request arrives with privacy >> information... >>> >>>> 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. >>> [MM] No, the entry in the H-I is not mandatory to match exactly the one in the R- >> URI. The entry in the R-URI is a minimum base to create the corresponding H-I >> entry. You can have a simple R-URI and when it is added in the new H-I entry, the >> service can add some additional headers/parameters (eg. Reason, Privacy/ cause, >> target) in this entry or in the entry that retargeted the request (identified by the hi- >> target-param) before sending the request downstream. This example is exactly an >> example from RFC7131 with a usage of the cause-param only in the History-Info >> header. Depending on your response on the first point, I can add an example to >> show this new cause value in a R-URI. > >> I realize there is no *requirement* that the parameters be in the R-URI before that is >> moved into the H-I header. But it still seems to me to be the *intent* of H-I that the >> URIs included in it were ones that were used during the past history of the request. >> So IMO stuffing extra URI parameters in when putting the URI into H-I is an abuse >> or at least a hack. > [MM2] IMO, they are 3 points that we have to distinct: > 1) There are headers that H-I RFC clearly mandate (with a *MUST*) to be added in the URI into the H-I only (Reason and Privacy headers). These are actually SIP Headers, encoded into the URI as sip uri *header* parameters. These actually cannot be included in an R-URI. (If they were in a URI that is to be used as the target for a request, they would be removed from the uri before it became the R-URI, and added to the request as sip headers.) > 2) There are SIP URI parameters that can be present in the R-URI anyway ('cause' and 'target' parameters included). These are examples of "regular" SIP URI parameters, that may be present in an R-URI. Their semantics is defined independent of where the URI containing them appears. > 3) There are H-I parameters that can be added only in the H-I header entries. Yes. These are not URI parameters at all, they are present in the H-I header field, outside of the URI. > IIUC, your point concerns only 2). Yes. > Indeed, I think RFC4458 was principally designed to use the 'cause' parameter in the R-URI (maybe because it was discussed in // of H-I when it was a draft) yes. Indeed IIRC it was proposed as a mechanism that would support voicemail servers *without* the need to use H-I. > but it is not mentioned as a requirement and for several reasons it has been understood and interpreted as a parameter that can be present either only in the History-Info (as 3GPP use it) My point is that this appears, to me, to be (choose one or more): inappropriate, a hack, an abuse, a bug. > or in the R-URI and so automatically included in the H-I (as a copy of the R-URI). So usage in the History-Info is the minimum. That is what I am discussing. > As an example, when privacy must be applied, RFC4458 states that the cause parameter must be removed from the R-URI That is interesting. I note that this statement in 4458 is non-normative. It seems to be trying to restate something implicit in RFC3323. But when I look at RFC3323 I see no such requirement. Nor can I think of any rationale for why these URI parameters would need to be removed as part of header privacy. > whereas having it in the H-I enable to keep this forwarding reason but indicating the requested Privacy with the priv-value "history". So terminating entities that would rely on this parameter value, will go directly into the H-I to be sure to find it...and so why have it in the R-URI... > IMO, having this 'cause' in the R-URI + H-I or only H-I should be an implementor choice. I recognize that this is a fuzzy area. I bring it up for broader discussion. > Anyway, I have no problem with adding an example with the 'cause' both in R-URI and H-I in the draft and adding an explicit sentence to state that this 'cause' param can be only in H-I or in the R-URI copied in H-I. That would be an improvement. > FYI, in the Voicemail example (section 3.6) of RFC7131 you can find the following call flow where there is no "cause" parameter in the R-URI but it is present in the corresponding hi-entry. > > F4 INVITE example.com -> Carol > > INVITE sip:carol@192.0.2.4 SIP/2.0 > Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4522 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 > Max-Forwards: 69 > From: Alice ;tag=kkaz- > To: Bob > Supported: histinfo > Call-ID: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;\ > index=1.1;rc=1 > History-Info: ;index=1.2;mp=1 > History-Info: ;index=1.2.1;rc=1.2 > Contact: Alice > Content-Type: application/sdp > Content-Length: > [SDP Not Shown] > > >> In the case of F2, I can see no reason why the parameter would not be appropriate >> for use in the R-URI. I would expect the recipient would look there first, and then, if >> not found there, look back into the H-I for evidence of a cause earlier in the history >> of the request. > [MM2] Actually, many recipients directly go through H-I to have the cause information (avoiding the double check). And so they would fail to function properly when receiving a request where RFC4458 was in use but H-I wasn't. :-( > In 3GPP specification it is described as to be added in the H-I with no specific requirement on its adding in the R-URI. At the end, my feeling is that the 'cause' parameter is optional in the R-URI. > However, if this new draft can be the opportunity to give some clarifications, I would be happy to add them in the text but I think it should not bring contradictory information with existing texts. Thanks. Paul > BR, > Marianne >> >> Thanks, >> Paul >> >>> Best regards, >>> Marianne >>> >>> -----Message d'origine----- >>> De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul >>> Kyzivat Envoyé : lundi 26 janvier 2015 20:31 À : dispatch@ietf.org >>> Objet : Re: [dispatch] New Version Notification for >>> draft-mohali-dispatch-cause-for-service-number-01.txt >>> >>> 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-nu >>>> m >>>> ber-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-s >>>> e >>>> rvice-number-01.txt >>>> >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-serv >>>> i >>>> ce-number/ >>>> >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-nu >>>> m >>>> ber-01 >>>> >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-cause-for-serv >>>> i >>>> ce-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 >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> 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. >>> >>> > > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Sun Feb 8 14:39:26 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 AB8CC1A1BC7 for ; Sun, 8 Feb 2015 14:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 nPdVnRvhR7pW for ; Sun, 8 Feb 2015 14:38:39 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAF91A1B35 for ; Sun, 8 Feb 2015 14:38:38 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-11v.sys.comcast.net with comcast id pyeP1p0024tLnxL01yedhr; Sun, 08 Feb 2015 22:38:37 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-02v.sys.comcast.net with comcast id pyeb1p00V1KKtkw01yecRW; Sun, 08 Feb 2015 22:38:37 +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 t18McY2T017859; Sun, 8 Feb 2015 17:38:34 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t18McWGE017854; Sun, 8 Feb 2015 17:38:32 -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: "Anton Tveretin" In-Reply-To: <54D345EE.9747.3B18B34@fas_vm.surguttel.ru> Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 08 Feb 2015 17:38:32 -0500 Message-ID: <87d25km3kn.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1423435117; bh=0kL6ywu3boXFXDyXv5JnSzn8fdr/itVO5R7MECuBin0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=nGGMVR77LZzLNRjIWL9FvuCpAHlukn6UxUaBb+q553hMUZrLaDBauvwmetmybe2e2 HZwpJuu7YsJJ3vupEjq2p0zD8a5hLt5BX13ZqFpaMEmOYMKu9cfpcLDHnj39icpL0p QT2puJ/sJX5HscBmFfPtd+54i7nFySGfJSHPkNARf6e749q2qzZvwdGCv0qhqQKeh5 rUp9Aq0U9z2cJitEF98RNPcKddOvGNhVrx4trCWJG0a3LhhJogXhC5CKtCnua6iutg t2cqZoeRPVLStAyx9AaumyegpwRnPdm8cMFPOfGlzw38HeVgPCvtxLo00PbbneC4wa k/gYQoK72LAyQ== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-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: Sun, 08 Feb 2015 22:38:41 -0000 > Name: draft-tveretin-dispatch-remote > Revision: 00 > Title: Remote Call Control and Call Pick-up in SIP > Document date: 2015-02-05 > Group: Individual Submission > Pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-00.txt > Status: https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/ > Htmlized: http://tools.ietf.org/html/draft-tveretin-dispatch-remote-00 > > > Abstract: > This memo defines a mechanism by which a SIP user agent could inspect > calls at another user agent, and control a call, including picking up > for itself. The facilities in this draft are interestingly different from those provided by the REFER method. REFER always commands the UAS to generate a particular request, and if used with Target-Dialog, can command the request to be made within a particular dialog. E.g., this can be used to terminate an existing dialog between the UAS and a third UA by ordering a BYE to be sent. Call pickup can be implemented using INVITE/Replaces. But the facilities described in the draft generally command the UAS to respond to a particular INVITE in early-dialog state with a particular response: 200 - accept the call 4xx - refuse the call 302 - forward/transfer the call (none) - stop alerting but keep the dialog in early state Excepting for that last function (stop alerting), it seems like they could be implemented by a version of REFER that specifies the response code to be returned to an early dialog. This would effectively fold ANSWER, REJECT, and PICKUP into a variant of REFER. First, B2 MUST identify the call ambiguously. The only way for this is to use dialog-id [RFC3261]. Thus, B2 must ask B1 somehow for the dialog-id in question. An [RFC4235] solution exists, but only some information will be supplied. Can you expand on why the information provided by dialog events (RFC 4235) is insufficient? I say this having worked on a system that has for years used RFC 4235 to implement call pick-up, and the information it provides has always been sufficient. Dale From nobody Mon Feb 9 11:39:45 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 3F15F1A873C for ; Mon, 9 Feb 2015 11:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 cJz4s94TIBIv for ; Mon, 9 Feb 2015 11:12:45 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CB11A8736 for ; Mon, 9 Feb 2015 11:12:08 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CEC9521017 for ; Mon, 9 Feb 2015 14:12:07 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 09 Feb 2015 14:12:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:from:content-type:content-transfer-encoding:subject :date:message-id:cc:to:mime-version; s=mesmtp; bh=Ru/rV325V0fb1E SwaFublE0Nhjw=; b=OhFXVhBWToWiM0TWSQ93z1G2fi7AdL8VqwLo6bZDUIJzeo rWWNzLpLtjQ4WPGRri/r/7L4uUMB4c2yY8Rljqy+3nnDb4JNMzf3qZBReKuxqGK3 M9qR1tIEO0/ePLuce50vn5HJ2sL28FDYAlhS0mCp2Y5jnjXTPZ7rlvr7skpGA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version; s=smtpout; bh=Ru/rV325V0fb1ESwaFublE0Nhjw=; b=AXK zoHSKSV3KaslrZdGP9PqAOluOXDWFQoW8Zg49CjiWez6xCuvYZ5V+gLYFjjYk5Sw eMuuXKhzoPdqOY/OVDVBvIPA8KvM3n+QjxdUaP65DPMbxKHjJzrWnieLL3OzX8IF IJeWPGoAMeMCbKh9fJcTfilubhMLvakMzO6rG3qY= X-Sasl-enc: ZcsHAWcIXRAsRNk2/S9X6eFnC7OhRP4FOghnwrPVKPBW 1423509127 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id 265C16800D5; Mon, 9 Feb 2015 14:12:05 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2015 11:12:04 -0800 Message-Id: <359F2A08-9474-4967-9A64-0D82F2A5DAC3@cooperw.in> To: dispatch@ietf.org, rai@ietf.org, rai-chairs@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Ben Campbell Subject: [dispatch] AD shepherding of WGs 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, 09 Feb 2015 19:12:47 -0000 Hi all, Ben and I have had some discussion about who will be shepherding which = WGs after he is seated at IETF 92 and we=92ve settled on the preliminary = division below. We may still continue to tweak this at various times but = wanted to give you a heads up in advance since I will not be at IETF 92. Ben: AVTCORE AVTEXT CODEC MMUSIC PAYLOAD SIPCORE XMPP STOX DRINKS INSIPID STRAW Alissa: CLUE ECRIT RTCWEB SIPREC STIR WEBPUSH XRBLOCK P2PSIP BFCPBIS LMAP Please let us know if you have questions. =97Alissa and Ben From nobody Mon Feb 9 12:32:08 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 E19BB1A1EFF for ; Mon, 9 Feb 2015 11:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 ogpdlsSFChgt for ; Mon, 9 Feb 2015 11:49:38 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316921A1C02 for ; Mon, 9 Feb 2015 11:49:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 770AE20ED8 for ; Mon, 9 Feb 2015 14:49:37 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 09 Feb 2015 14:49:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=flygmNNTz6XZo0B3 tM+tbuniVQk=; b=MW3Fw3rN4iw4vw4eTpqdxtXX6D+RpGFe8Q63eKvqGBOw1Fjo RJj3r/H5swAplOgfooCSDXrW27so6A5mUv8lXSr6GqF9ZhupIOe0tC/bngVbMWND 9EF9p7RY/gsNosQOl2RozQaWJ5q2H2Lm60AWlDGnXbzHlSxjgkkRbnNLedY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=flygmNNTz6XZo0B3tM+tbuniVQk=; b=Xm/RQ+PEkQk5Yp7J8yGg tUxriCrG0EvXw3za6TX2Xn/vzLFruqu6L6vAPkzsJF60g/lT0+vRAiZuG0th/A6i A+2pHnaWcbhoCvXfQjEnYxvA2SMVwCnZQfvMmHbNMs3OrkFtFMCzAlC0QQSo1jwp uxUdfbH1PkDN0iDGp8vv9cY= X-Sasl-enc: 5Wv/QLIAvpTpEVrPpuSwJf4XR749N35qsk+FZ6f4Hdxg 1423511377 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id CAA54680153; Mon, 9 Feb 2015 14:49:35 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_52FD762E-C32B-4B3C-8FBE-2379BB2CAFA4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <359F2A08-9474-4967-9A64-0D82F2A5DAC3@cooperw.in> Date: Mon, 9 Feb 2015 11:49:34 -0800 Message-Id: References: <359F2A08-9474-4967-9A64-0D82F2A5DAC3@cooperw.in> To: dispatch@ietf.org, rai@ietf.org, rai-chairs@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Ben Campbell Subject: Re: [dispatch] AD shepherding of WGs 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, 09 Feb 2015 19:49:40 -0000 --Apple-Mail=_52FD762E-C32B-4B3C-8FBE-2379BB2CAFA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert pointed out to me that we left DISPATCH off the list below. = Updated list is below. Note that these changes will not take effect = until Ben gets seated in Dallas. Ben: DISPATCH AVTCORE AVTEXT CODEC MMUSIC PAYLOAD SIPCORE XMPP STOX DRINKS INSIPID STRAW Alissa: CLUE ECRIT RTCWEB SIPREC STIR WEBPUSH XRBLOCK P2PSIP BFCPBIS LMAP (handed off from Benoit [1]) [1] = http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13597.html On Feb 9, 2015, at 11:12 AM, Alissa Cooper wrote: > Hi all, >=20 > Ben and I have had some discussion about who will be shepherding which = WGs after he is seated at IETF 92 and we=92ve settled on the preliminary = division below. We may still continue to tweak this at various times but = wanted to give you a heads up in advance since I will not be at IETF 92. >=20 > Ben: > AVTCORE > AVTEXT > CODEC > MMUSIC > PAYLOAD > SIPCORE > XMPP > STOX > DRINKS > INSIPID > STRAW >=20 > Alissa: > CLUE > ECRIT > RTCWEB > SIPREC > STIR > WEBPUSH > XRBLOCK > P2PSIP > BFCPBIS > LMAP >=20 > Please let us know if you have questions. > =97Alissa and Ben >=20 >=20 --Apple-Mail=_52FD762E-C32B-4B3C-8FBE-2379BB2CAFA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Robert pointed out to me that we left DISPATCH = off the list below. Updated list is below. Note that these changes will = not take effect until Ben gets seated in = Dallas.

Ben:
DISPATCH
AVTCOREAVTEXT
CODEC
MMUSIC
PAYLOAD
SIPCORE
XMPP
STOX
DRINK= S
INSIPID
STRAW

Alissa:
CLUE
ECRIT
RTCWEB
SIPREC<= br>STIR
WEBPUSH
XRBLOCK
P2PSIP
BFCPBIS
LMAP (handed off = from Benoit [1])


On Feb 9, 2015, at 11:12 AM, Alissa Cooper = <alissa@cooperw.in> = wrote:

Hi all,

Ben and I have had some discussion about = who will be shepherding which WGs after he is seated at IETF 92 and = we=92ve settled on the preliminary division below. We may still continue = to tweak this at various times but wanted to give you a heads up in = advance since I will not be at IETF = 92.

Ben:
AVTCORE
AVTEXT
CODEC
MMUSIC
PAYLOAD
SIPC= ORE
XMPP
STOX
DRINKS
INSIPID
STRAW

Alissa:
CLUEECRIT
RTCWEB
SIPREC
STIR
WEBPUSH
XRBLOCK
P2PSIP
BFC= PBIS
LMAP

Please let us know if you have questions.
=97Alissa= and Ben



= --Apple-Mail=_52FD762E-C32B-4B3C-8FBE-2379BB2CAFA4-- From nobody Mon Feb 9 14:36: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 2FA231A897E for ; Mon, 9 Feb 2015 14:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 SnlMiMKIWehY for ; Mon, 9 Feb 2015 14:14:20 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1A91A895C for ; Mon, 9 Feb 2015 14:14:20 -0800 (PST) Received: by lamq1 with SMTP id q1so16570819lam.5 for ; Mon, 09 Feb 2015 14:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wIvVg7MEqwoR4j+LmzCyNlrQK4r6307H8q4lwauyeCE=; b=L7GnSaaUyiHwXke+N87tRIZZA2aDb9Ft8/3SOarkQNXdx3H1XUYZyM+WwBLahbydPQ 4DnKlM65iSRlUNx3ATi1x4OVaMp8bh76Bb1Vx4pb4eRQOuIUFnzXA+aR/9kDV+nxu5WM 9yNZ2QkuVbV3jy6AT4xWylJoHV+e/9sGVCeiPBs6zhK/hviWqysGRdkZ371uWJiVYBVN FifJTN2FIqJs5HKjwKYeAPet2aPlFwKuS7bqgO8bEv4KZRPSXxCKZlQvl0LAerT3BKQh KvFxmP2DY30FemK1NLXSdCRJKr32OiQdN0FjHrYi7557/t4jJf5XKz2WVEP/aiXom82w A89w== MIME-Version: 1.0 X-Received: by 10.112.170.2 with SMTP id ai2mr14509360lbc.3.1423520058599; Mon, 09 Feb 2015 14:14:18 -0800 (PST) Received: by 10.25.86.137 with HTTP; Mon, 9 Feb 2015 14:14:18 -0800 (PST) Date: Mon, 9 Feb 2015 16:14:18 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a11c33e186c7a73050eaf17df Archived-At: Subject: [dispatch] Reminder: DISPATCH WG deadlines for IETF-92 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, 09 Feb 2015 22:14:22 -0000 --001a11c33e186c7a73050eaf17df Content-Type: text/plain; charset=UTF-8 As a reminder, the deadlines for IETF-92 are as follows: https://tools.ietf.org/wg/dispatch/trac/wiki - February 18, 2015. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. - February 25, 2015. Cutoff for charter proposals for topics. - March 2, 2015. Announcement of topics that have been dispatched for IETF-92. - March 9, 2015. Draft deadline. We've already had some good discussion of a number of drafts and the chairs will be contacting the authors with regards to their (authors) plans as well as to give feedback (if we haven't already). As a reminder, please keep in mind the importance of problem statements/charter proposals and don't hesitate to contact the chairs if you have any questions. Regards, Mary and Cullen --001a11c33e186c7a73050eaf17df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a reminder, the deadlines for IETF-92 are as follows:https://tools.i= etf.org/wg/dispatch/trac/wiki

  • February= 18, 2015. Cutoff date to notify the chairs/DISPATCH WG of plans to submit = a proposal.
  • February 25, 2015. Cutoff for charter pro= posals for topics.=C2=A0
    March 2, 2015. Announcement of= topics that have been dispatched for IETF-92.=C2=A0
  • Ma= rch 9, 2015. Draft deadline.

We've already had s= ome good discussion of a number of drafts and the chairs will be=C2=A0conta= cting the authors with regards to their (authors) plans as well as to give = feedback (if we haven't already). =C2=A0

As a reminder, = =C2=A0please keep in mind the importance of problem statements/charter prop= osals=C2=A0and don't hesitate to contact the chairs if you=C2=A0have an= y questions. =C2=A0=C2=A0

Regards,
Mary and Cullen<= /div>


--001a11c33e186c7a73050eaf17df-- From nobody Thu Feb 12 06:45: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 2DDD71A8A81 for ; Thu, 12 Feb 2015 06:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 8-uE3gnzDPgA for ; Thu, 12 Feb 2015 06:45:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D3E1A8992 for ; Thu, 12 Feb 2015 06:45:26 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 7CF8A1906AD; Thu, 12 Feb 2015 15:45:24 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 61EC83840E3; Thu, 12 Feb 2015 15:45:24 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 15:45:24 +0100 From: To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt Thread-Index: AQHQNXI/TzIZMTr/aUuPWqfF7F6tsZzSNsxggACKq4CADBivYIADjjIAgAEViICAAHBqAIAJO7BA Date: Thu, 12 Feb 2015 14:45:24 +0000 Message-ID: <4216_1423752324_54DCBC84_4216_10469_1_8B970F90C584EA4E97D5BAAC9172DBB8142FAAD8@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20150121120313.27766.23230.idtracker@ietfa.amsl.com> <6309_1422280715_54C6480B_6309_1693_1_8B970F90C584EA4E97D5BAAC9172DBB8142DC24A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54C695DD.1050704@alum.mit.edu> <23955_1422974394_54D0DDBA_23955_500_1_8B970F90C584EA4E97D5BAAC9172DBB8142F6155@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54D3B714.6000509@alum.mit.edu> <4397_1423240733_54D4EE1D_4397_4876_2_8B970F90C584EA4E97D5BAAC9172DBB8142F8C5B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <54D4FE30.9050304@alum.mit.edu> In-Reply-To: <54D4FE30.9050304@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.110918 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: Thu, 12 Feb 2015 14:45:49 -0000 Hi Paul, If I try to sum up: In a general manner, we should consider that the 'cause' parameter should b= e present in both R-URI and in the H-I. It can be present in the H-I as a copy of the R-URI or directly introduced = in the H-I. Indeed, for the following reasons, the cause parameter can be absent from t= he R-URI: 1- because it has been removed/not added for some privacy requirements of t= he diverting party (as mentioned RFC4458) 2- because the R-URI is a TelURI that cannot include the 'cause' parameter = which is a SIP/SIPS URI parameter except by being changed into a SIP URI. (= note that this is also true for the URI in the H-I that must be changed int= o a SIP URI to add the cause param but it is different to change the R-URI = than a hi-entry) Would it be fine if I add something like that in the draft and the 'cause' = in the R-URI in the example section? Of course the purpose of the draft in only to create a new value for the ca= use parameter but it can be also a good opportunity to fix ambiguities crea= ted in the past. Additional answers inline [MM3] Marianne > -----Message d'origine----- > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy=E9=A0: vendredi 6 f=E9vrier 2015 18:47 > =C0=A0: MOHALI Marianne IMT/OLN; dispatch@ietf.org > Objet=A0: Re: [dispatch] New Version Notification for draft-mohali-dispat= ch-cause-for- > service-number-01.txt >=20 > Hi Marianne, >=20 > Further discussion inline. >=20 > On 2/6/15 11:38 AM, marianne.mohali@orange.com wrote: > > Hi Paul, > > > > [MM2] > > > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : jeudi 5 > >> f=E9vrier 2015 19:32 =C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org > >> Objet : Re: [dispatch] New Version Notification for > >> draft-mohali-dispatch-cause-for- service-number-01.txt > >> > >> Hi Marianne, > >> > >> On 2/3/15 9:39 AM, marianne.mohali@orange.com wrote: > >>> Hi Paul, > >>> > >>> Thank you for your feedback. > >>> > >>> You said: > >>> > >>>> 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? > >>> [MM] Actually there is no particular reason but having no usage > >>> example I > >> focused the description on the usage we have in mind. In the same > >> manner, > >> RFC4458 was more focused on a usage in the Request-URI towards > >> voicemail than in the History-Info for call forwarding service in > >> general. If because it is a SIP/SIPS URI header (in general), you > >> think I should add some text to give the same importance on its usage > >> in a R-URI and/or in the History-Info header, I can do it. Is it your > >> point? If yes, I should add a warning that usage in the R-URI would > >> have some limitation in regards with usage in the H-I header having > >> more capabilities to give the information on why, how the incoming req= uest > arrives with privacy information... > >>> > >>>> 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 wha= t is in the > R-URI. > >>> [MM] No, the entry in the H-I is not mandatory to match exactly the > >>> one in the R- > >> URI. The entry in the R-URI is a minimum base to create the > >> corresponding H-I entry. You can have a simple R-URI and when it is > >> added in the new H-I entry, the service can add some additional > >> headers/parameters (eg. Reason, Privacy/ cause, > >> target) in this entry or in the entry that retargeted the request > >> (identified by the hi- > >> target-param) before sending the request downstream. This example is > >> exactly an example from RFC7131 with a usage of the cause-param only > >> in the History-Info header. Depending on your response on the first > >> point, I can add an example to show this new cause value in a R-URI. > > > >> I realize there is no *requirement* that the parameters be in the > >> R-URI before that is moved into the H-I header. But it still seems to > >> me to be the *intent* of H-I that the URIs included in it were ones th= at were used > during the past history of the request. > >> So IMO stuffing extra URI parameters in when putting the URI into H-I > >> is an abuse or at least a hack. > > [MM2] IMO, they are 3 points that we have to distinct: > > 1) There are headers that H-I RFC clearly mandate (with a *MUST*) to be= added in > the URI into the H-I only (Reason and Privacy headers). >=20 > These are actually SIP Headers, encoded into the URI as sip uri *header* > parameters. These actually cannot be included in an R-URI. (If they were = in a URI > that is to be used as the target for a request, they would be removed fro= m the uri > before it became the R-URI, and added to the request as sip headers.) >=20 [MM3] yes > > 2) There are SIP URI parameters that can be present in the R-URI anyway= ('cause' > and 'target' parameters included). >=20 > These are examples of "regular" SIP URI parameters, that may be present i= n an R- > URI. Their semantics is defined independent of where the URI containing t= hem > appears. >=20 [MM3] Exact with the exception that they are only for SIP/SIPS URIs and not= for TelURI and the R-URI can be a TelURI. > > 3) There are H-I parameters that can be added only in the H-I header en= tries. >=20 > Yes. These are not URI parameters at all, they are present in the H-I hea= der field, > outside of the URI. >=20 > > IIUC, your point concerns only 2). >=20 > Yes. >=20 > > Indeed, I think RFC4458 was principally designed to use the 'cause' > > parameter in the R-URI (maybe because it was discussed in // of H-I > > when it was a draft) >=20 > yes. Indeed IIRC it was proposed as a mechanism that would support voicem= ail > servers *without* the need to use H-I. >=20 > > but it is not mentioned as a requirement and for several reasons it > > has been understood and interpreted as a parameter that can be present > > either only in the History-Info (as 3GPP use it) >=20 > My point is that this appears, to me, to be (choose one or more): > inappropriate, a hack, an abuse, a bug. >=20 > > or in the R-URI and so automatically included in the H-I (as a copy of = the R-URI). > So usage in the History-Info is the minimum. >=20 > That is what I am discussing. >=20 > > As an example, when privacy must be applied, RFC4458 states that the > > cause parameter must be removed from the R-URI >=20 > That is interesting. I note that this statement in 4458 is non-normative.= It seems to > be trying to restate something implicit in RFC3323. But when I look at RF= C3323 I > see no such requirement. Nor can I think of any rationale for why these U= RI > parameters would need to be removed as part of header privacy. > [MM3] Correct me if I'm wrong but RFC4458 is informational and as such it c= annot contain normative statement. no? IMO, the rational about the cause removal is not the first point for the pr= ivacy consideration but it is more about the target parameter which explici= tly reveal the diverting user identity.=20 =20 > > whereas having it in the H-I enable to keep this forwarding reason but = indicating > the requested Privacy with the priv-value "history". So terminating entit= ies that > would rely on this parameter value, will go directly into the H-I to be s= ure to find > it...and so why have it in the R-URI... > > IMO, having this 'cause' in the R-URI + H-I or only H-I should be an im= plementor > choice. >=20 > I recognize that this is a fuzzy area. I bring it up for broader discussi= on. >=20 > > Anyway, I have no problem with adding an example with the 'cause' both = in R- > URI and H-I in the draft and adding an explicit sentence to state that th= is 'cause' > param can be only in H-I or in the R-URI copied in H-I. >=20 > That would be an improvement. [MM3] fine for me. >=20 > > FYI, in the Voicemail example (section 3.6) of RFC7131 you can find the > following call flow where there is no "cause" parameter in the R-URI but = it is present > in the corresponding hi-entry. > > > > F4 INVITE example.com -> Carol > > > > INVITE sip:carol@192.0.2.4 SIP/2.0 > > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK4522 > > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > > Max-Forwards: 69 > > From: Alice ;tag=3Dkkaz- > > To: Bob > > Supported: histinfo > > Call-ID: 12345600@example.com > > CSeq: 1 INVITE > > History-Info: ;index=3D1 > > History-Info: ;\ > > index=3D1.1;rc=3D1 > > History-Info: ;index=3D1.2;mp=3D1 > > History-Info: ;index=3D1.2.1;rc=3D= 1.2 > > Contact: Alice > > Content-Type: application/sdp > > Content-Length: > > [SDP Not Shown] > > > > > >> In the case of F2, I can see no reason why the parameter would not be > >> appropriate for use in the R-URI. I would expect the recipient would > >> look there first, and then, if not found there, look back into the > >> H-I for evidence of a cause earlier in the history of the request. > > [MM2] Actually, many recipients directly go through H-I to have the cau= se > information (avoiding the double check). >=20 > And so they would fail to function properly when receiving a request where > RFC4458 was in use but H-I wasn't. :-( >=20 > > In 3GPP specification it is described as to be added in the H-I with no= specific > requirement on its adding in the R-URI. At the end, my feeling is that th= e 'cause' > parameter is optional in the R-URI. > > However, if this new draft can be the opportunity to give some clarific= ations, I > would be happy to add them in the text but I think it should not bring co= ntradictory > information with existing texts. >=20 > Thanks. >=20 > Paul >=20 > > BR, > > Marianne > >> > >> Thanks, > >> Paul > >> > >>> Best regards, > >>> Marianne > >>> > >>> -----Message d'origine----- > >>> De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul > >>> Kyzivat Envoy=E9 : lundi 26 janvier 2015 20:31 =C0 : dispatch@ietf.org > >>> Objet : Re: [dispatch] New Version Notification for > >>> draft-mohali-dispatch-cause-for-service-number-01.txt > >>> > >>> 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- > >>>> nu > >>>> m > >>>> ber-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=F6rgen'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-f= ield. > >>>> > >>>> - 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=E9 > >>>> : mercredi 21 janvier 2015 13:03 =C0 : 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 > >>>> -s > >>>> e > >>>> rvice-number-01.txt > >>>> > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-se > >>>> rv > >>>> i > >>>> ce-number/ > >>>> > >>>> Htmlized: > >>>> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service- > >>>> nu > >>>> m > >>>> ber-01 > >>>> > >>>> Diff: > >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-mohali-dispatch-cause-for-se > >>>> rv > >>>> i > >>>> ce-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 SI= Ps 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, deform= e 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 > >>>> > >>> > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> > >>> > >> > _____________________________________________________________________ > >> _ > >>> ___________________________________________________ > >>> > >>> 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, deform= e 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. > >>> > >>> > > > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > 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 qu= e les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. 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 b= een > modified, changed or falsified. > > Thank you. > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Thu Feb 12 15: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 AB51B1A1ADA for ; Thu, 12 Feb 2015 15:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 1_WbREQbQ-xi for ; Thu, 12 Feb 2015 15:14:41 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11E41A1A37 for ; Thu, 12 Feb 2015 15:14:40 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wo20so13709043obc.5 for ; Thu, 12 Feb 2015 15:14:40 -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 :cc:content-type; bh=3gKlIkXFzLAIXhqCnhTu4xqm0k3rizgqcRfwv6jIi44=; b=BibujRpK1fyE0tTT9AtuLZBJQmm0cqpe8COMZNG2ehv7Ze71ZPlm50cho5SJNr7Zba wfqouD3DfLuAJOjwUNGi1nloNdX9JxqNWAkI8ZvnyrnDmrZZ5SBHzVrH3F8/BENZTF/E wBhfl6QAaYaxTROl+wAa1aArI20BV89nUmrxIx05y35MOWED7p9CKHz7dbRILOqq95Vc J3SEX0DCwwvJWVxWfKjnjk/TqXRioMpFfrJ+QNGvrMPrXShUsc/JP6NqoI/UkrjtBlbS 42PM8R0RQ0yvV0M+xr5Gj4y8lPJafoo/rob4CHnGXyiBcmKs+4eOSnzk2//eHcvtviIc EyrA== MIME-Version: 1.0 X-Received: by 10.60.132.82 with SMTP id os18mr94193oeb.0.1423782880190; Thu, 12 Feb 2015 15:14:40 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 12 Feb 2015 15:14:40 -0800 (PST) In-Reply-To: <54DCBBF9.8010705@gmail.com> References: <54D3AF68.4070803@berkeley.edu> <625863E8-3AE1-4ABB-879E-946C958DC1C7@cooperw.in> <54DCBBF9.8010705@gmail.com> Date: Fri, 13 Feb 2015 10:14:40 +1100 Message-ID: From: Martin Thomson To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] [Geopriv] Fwd: Forming and chartering a GeoJSON WG 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, 12 Feb 2015 23:14:43 -0000 On 13 February 2015 at 01:43, Alexandru Petrescu wrote: > JSON/IP will reach a number of reference systems in wide use, non-WGS-84, > which deserve direct use instead of through conversion. I'd be against this. For those who need other reference systems, GML should serve their needs. Creating a seldom used parameter that subtly (and sometimes not-subtly) changes the meaning of all other parameters is an interoperability problem waiting to happen. From nobody Tue Feb 17 19:39:41 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 53D121A86E0 for ; Tue, 17 Feb 2015 19:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 d1vDbVJ4xuyX for ; Tue, 17 Feb 2015 19:39:37 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4AD1A7D80 for ; Tue, 17 Feb 2015 19:39:36 -0800 (PST) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 17 Feb 2015 22:39:33 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 17 Feb 2015 22:39:32 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Tue, 17 Feb 2015 22:39:32 -0500 From: Andrew Allen To: DISPATCH Thread-Topic: Revised version of draft-allen-dispatch-routing-out-of-dialog-request Thread-Index: AdBLK2suoEtZ1HUNSUmVHxR+2aVIDg== Date: Wed, 18 Feb 2015 03:39:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233A39DBA4XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request 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, 18 Feb 2015 03:39:39 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233A39DBA4XMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted a revised version of draft-allen-dispatch-routing-out-of-d= ialog-request. This document discusses the problems for out of dialog reque= sts that are related to another dialog, caused by B2BUA intermediaries that= modify SIP parameters or terminate dialogs and proposes some possible solu= tions. This draft is related to the recent work on RFC 6665 that deprecates= dialog reuse when creating subscriptions using SUBSCRIBE and REFER. I would like to request discussion time during Dispatch at IETF#92. Earlier= list discussion indicated that either sipcore or STRAW would be the approp= riate place to work on solutions to this issue. The draft can be found at: http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-0= 1.txt Please provide comments on the contents and on which WG would be an appropr= iate for the work. Andrew --_000_BBF5DDFE515C3946BC18D733B20DAD233A39DBA4XMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have submitted a revised version of draft-allen-disp=
atch-routing-out-of-dialog-request. This document discusses the problems fo=
r out of dialog requests that are related to another dialog, caused by B2BU=
A intermediaries that modify SIP parameters or terminate dialogs and propos=
es some possible solutions. This draft is related to the recent work on RFC=
 6665 that deprecates dialog reuse when creating subscriptions using SUBSCR=
IBE and REFER.
 
I would like to request discussion time during Dispatc=
h at IETF#92. Earlier list discussion indicated that either sipcore or STRA=
W would be the appropriate place to work on solutions to this issue.
 
The draft can be found at:
 

http://www.ietf.org/id/draft-allen= -dispatch-routing-out-of-dialog-request-01.txt

 

Please provide comments on the contents and on which= WG would be an appropriate for the work.

 

Andrew

--_000_BBF5DDFE515C3946BC18D733B20DAD233A39DBA4XMB122CNCrimnet_-- From nobody Wed Feb 18 05:28:16 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 3A9D41A87D9 for ; Wed, 18 Feb 2015 05:28:15 -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 4im0cwycMkkw for ; Wed, 18 Feb 2015 05:28:13 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E325E1A874A for ; Wed, 18 Feb 2015 05:28:12 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id m20so778672qcx.0 for ; Wed, 18 Feb 2015 05:28:12 -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=6GBIBOde0+boSXXRwNYxTGQPF55DzNqpJnSQZSZJ7bc=; b=hk6Hb/kKee74wVjRBGjDVJKvqEaQ1wFaS5ZSVjziOEB7/Q78KA9QtqE4tK1K2sO1+z rWshoXCNT/3r1zHMAeTISM2P9slJ9rpJNHfus+Un8lfVsyp8xP6c1s0TVnp3N9dvbXC6 Iew6+MmI+Q1mBY8HAoyeefNqZtssa87sn/tZdmRHd9ZWgOHnVF1QAxI+3Ai4+FOJCp4d aIK6hETrS8nT4quXwdeueXZ+I41gX7Vy4+8yHgVQ1QNqpWTihBfWNnFPbH0szy50vjMu Z1ISYlQFiPyIDkCWKZ2/Zoqh2r4roRaoMSlnVti48Ba8YYZUuB4tcNN3fKSohDGpy5iU 45Sw== X-Gm-Message-State: ALoCoQk1WAJ7YHO8tDxVecaILBKGUc3b0m++VHk64dc9zkvdzEr/NGey+OVsB8N1uaN8MNGZzWO6 X-Received: by 10.140.37.39 with SMTP id q36mr309572qgq.18.1424266092144; Wed, 18 Feb 2015 05:28:12 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBLfruNr26iqRrfQrGfQ3dR2+6Dqg== Date: Wed, 18 Feb 2015 08:28:11 -0500 Message-ID: <701e6e928785d1de8fe18bab9a2f1306@mail.gmail.com> To: draft-allen-dispatch-routing-out-of-dialog-request@tools.ietf.org, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: comments and question 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, 18 Feb 2015 13:28:15 -0000 Hi, The following are a few initial comments concerning draft-allen-dispatch-routing-out-of-dialog-request-01. Thanks, Brett ------ 1) RFC 3725 indicates the following. "Third party call control is possible using only the mechanisms specified within RFC 3261 [1]." This draft appears to currently prevent the above from occurring. Similarly how do you foresee this draft impacting 3PCC call setup such as those depicted within RFC 3725? 2) Section 3.5 indicates the following. "One advantage of this approach is that there may be some backward compatibility with this mechanism because RFC 3261 [5] compliant UAs should use the embedded Route header fields when constructing a request addressed to this Contact URI." That sentence should potentially be adjusted since RFC 3261 section 19.1.5 appears to indicate that the Route SHOULD NOT be honored. "An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks." From nobody Wed Feb 18 09:57:35 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 6E9641A8ADA for ; Wed, 18 Feb 2015 09:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 SSj36CoErJjK for ; Wed, 18 Feb 2015 09:57:32 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3601A8939 for ; Wed, 18 Feb 2015 09:57:31 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with comcast id ttwk1p0032XD5SV01txXAy; Wed, 18 Feb 2015 17:57:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id ttxW1p00E3Ge9ey01txWyF; Wed, 18 Feb 2015 17:57:31 +0000 Message-ID: <54E4D28A.5000707@alum.mit.edu> Date: Wed, 18 Feb 2015 12:57:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1424282251; bh=UKtal+h/2NhXzdhQwvGYvm5kgzmGBPI8FavCrd+IqHg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jWelisXC27hVy+6xSPcOmOwAHj8vz/Yqr74bdZ7fKXqqQBYtMkUjnc687RoUZ2SJA Pjy/BlpyPVDnDdGkhogsByKekjPza1IZj5zMHh3AP04UIgJEBWljMCkR566ptXjHnC jndxWb4N9rH5ieZQSJtWjbexZv471AdJag3PLtcaSErAX6XaZo0S9mTmMjxj8aUFZZ 3cQngehMg7GIQb0TeA7tVFkXFtVHjDfwi4t1fKwEkMIGvihKfZzQjzAwNSl2M4EVyK TzQZT6fED/suVGeVDv0/qSpYnIaR8GnbQZjWAVo/rrkTGJGhNzfB7kPhsfyYzNbHuw /Vl0Tx7xBxjig== Archived-At: Subject: Re: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request 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, 18 Feb 2015 17:57:34 -0000 Andrew, This draft proposes new mechanism(s) intended to mitigate problems caused by certain types of B2BUA intermediaries. My biggest problem with this draft is that it makes assumptions about how such intermediaries function. Those assumptions are not well specified. The way sip deployments have evolved we now have a very complex ecosystem of components interconnected by SIP, with some of their behavior defined by the various ietf SIP standards, and some of it defined by 3gpp specifications, and some by a multitude of proprietary mechanisms. Most of this is dependent on "clever" manipulations by devices loosely described in ietf terms as B2BUAs, but that in practice take license with the few standards governing B2BUA, taking the view that they can break rules features when it suits them. The result is a complex architecture that isn't written down anywhere I know of. For awhile now we have been getting proposals for new features and extensions to existing features to fix things that have been broken by that architecture. (RFC6809 is one, your draft is another.) Each of these propose a "patch". But this seems to be just patching around the edges without any clear understanding of how many (if any) problems are being addressed. I think you must be much more explicit about your assumptions. (E.g., I suspect you have 3gpp intermediaries in mind. Do those assumptions also apply to business systems such as Cisco deploys, that also employ B2BUA intermediaries?) Those who aren't deeply steeped in 3gpp specs don't know what those intermediaries do. Now for some more specific points: * Are the intermediaries you are concerned with all B2BUAs? Or could proxies also have such needs? * I'm confused when you talk about these B2BUAs "even terminating the dialog for some mid session requests", as if that was extraordinary. AFAIK a B2BUA by definition terminates *all* requests and dialogs that reach it. Else it isn't a UA. Of course it may, usually, originate a corresponding request or dialog on the other "side". (For some types of B2BUA it may be unusual when it processes an incoming request in some way other than originating a corresponding request.) If you have a different view of this, then I think we are not talking about a true B2BUA, but rather something that has no formal definition in SIP. * In section 2 you say: One way B2BUAs have have addressed this problem is by acting as two UAs back-to-back with the Contact URI being overwritten to be the URI of the B2BUA. However this means that GRUU of the UA is overwritten by the B2BUA and the meaning of the Contact header field parameters becomes obscure. Do the Contact header field parameters reflect the capabilities of the Contact address (i.e the B2BUA) or do they reflect the capabilities of the remote UA? If they relect the capabilities of the B2BUA then the identfication of the capabilities of the remote UAS has been lost. If they reflect the capabilities of the remote UA then they falsely identify that the B2BUA contact address has the capabilities of the remote UA. While some have advocated that a B2BUA should only indicate the capabilities that it understands and supports in the Contact, in the opinion of the author this is not desirable behavior because the feature tags may indicate many kinds of capabilities which do not require the support of the intermediary. ... They may not require the active *support* of the intermediary. But they likely do still require that intermediaries don't impede them. And this does happen. Without rules on what intermediaries can do there is no way to know in a general way if an arbitrary feature will work in the presence of a particular intermediary. ISTM that if an intermediary imposes itself as a B2BUA in a dialog, and makes any claim to being "transparent" (like a proxy), then it is obligated to do whatever is necessary to make itself transparent. In many/most cases that will likely involve introducing its own Contact addresses. If an incoming Contact address is a gruu, then the surrogate contact address used by the intermediary should also have the gruu property. Feature tags can be "forwarded" to the extent that the intermediary knows that its presence won't break them. (If it *really* thinks it can be transparent to features it knows nothing about, then it can simply forward on unknown ones.) This does impose a maintenance burden on those that deploy such intermediaries, to ensure that they support everything needed by their endpoints. But that is the unavoidable cost of using such things. (You can make your life easier by using proxies rather than B2BUAs.) * next the draft says: ... In the opinion of the author the feature capability indicator mechanism defined in RFC 6809 [2] is the appropriate means for an intermediary to indicate the capabilities that it supports and will allow. While this is consistent with RFC 6809 I fail to see how it has anything to do with the the problem stated in *this* draft. Feature-Caps indicates features that are present somewhere along the path of the current dialog. It doesn't, by default, even indicate which intermediary provides the service. While some feature-tags may include a URI as part of their value, that URI doesn't necessarily refer to an entity that is on the path of the current dialog. * next: ... It also should be recognised that UAs may store Contact addresses especially if they are GRUUs for use later for originating sessions (e.g. stored in the address book) or for filtering incoming sessions (e.g. incoming sessions addressed to temporary GRUUs). So if the Contact address is overwritten then this information is lost or not valid as a contact outside the lifetime of the current dialog. Does anybody really put Contacts into address books? I'd be shocked if they were. I bet it is always To/From/P-A-ID that ends up in address books. * next: ... Additionally the mechanism defined in RFC 6665 [3] depends on the UA receiving a GRUU as the remote target in order to avoid dialog reuse, so overwriting the Contact Address breaks this mechanism. So when a B2BUA replaces the Contact, the replacement should have the gruu property. Why is this a problem for RFC 6665 compatibility? * IIUC, the intent is that when a UA is in a dialog, and wishes to send an out of dialog request that refers to that dialog, must take special steps to make that work: extract the special route from the dialog and incorporate it into the out of dialog request. What criterion does the UA use to decide when to do this? Is it the presence of certain header fields in the request? (Replaces, Join, Target-Dialog). Is that well defined and exhaustive? What about cases where the client referencing an existing dialog already in that dialog? For instance, a client using the dialog event package to discover an existing dialog and then sending a request to replace it. IDoes that client need to know about the intermediaries? If so, how would it learn, and what if it doesn't? Many clients, when sending out of dialog requests, already have a Route header to apply to that request. (E.g., via Service-Route.) How should the URIs of these interested intermediaries be sorted into that predefined route? Thanks, Paul On 2/17/15 10:39 PM, Andrew Allen wrote: > I have submitted a revised version of draft-allen-dispatch-routing-out-of-dialog-request. This document discusses the problems for out of dialog requests that are related to another dialog, caused by B2BUA intermediaries that modify SIP parameters or terminate dialogs and proposes some possible solutions. This draft is related to the recent work on RFC 6665 that deprecates dialog reuse when creating subscriptions using SUBSCRIBE and REFER. > > > > I would like to request discussion time during Dispatch at IETF#92. Earlier list discussion indicated that either sipcore or STRAW would be the appropriate place to work on solutions to this issue. > > > > The draft can be found at: > > > > http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-01.txt > > Please provide comments on the contents and on which WG would be an > appropriate for the work. > > Andrew > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Feb 19 14:48:35 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 4C77B1A0069 for ; Thu, 19 Feb 2015 14:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.732 X-Spam-Level: X-Spam-Status: No, score=-97.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 jzDGzKOXtRlX for ; Thu, 19 Feb 2015 14:48:32 -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 EDC051A0007 for ; Thu, 19 Feb 2015 14:48:30 -0800 (PST) Received: from [151.252.68.209] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 8492878; Fri, 20 Feb 2015 01:48:27 +0300 From: "Anton Tveretin" To: Mary Barnes , worley@ariadne.com Date: Fri, 20 Feb 2015 03:47:53 +0500 MIME-Version: 1.0 Message-ID: <54E66819.23243.6F0DAA2@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: Cc: dispatch@ietf.org Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-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: Thu, 19 Feb 2015 22:48:34 -0000 Mary, Dale, and all, Let me answer in a single post. Thank you for your replies. I tried to found an equivalent RFC about a year ago, on request by Paul. There are none. https://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 is closest, (and -03 version IIRC is more detailed) but it I was withdrawn by authors. So I think it is not binding for me or the IETF, and I do not consider it. Also, I warn that some memos use "call pick-up" to denote other services, as call parking or even call holding. I think they are irrelevant, as well. As of RFC 4235: I believe that controller makes a decision about incoming call (either to pick it up, or reject, or let alerting entity answer etc.) For this, it needs as much information as possible; it might need Subject, History, media types (e.g. to not intercept incoming faxes and files). So for XML we should add more and more elements and attributes. I believe that a SIP message is much better way to represent a SIP message than XML. (Not counting http://blog.codinghorror.com/xml-the-angle-bracket-tax/ ) Maybe this is not the ideal way though, as both parties have to parse the same message. As for REFER/Replaces: for me, this behaviour is not obvious, and does not follow from RFC 3515. Is it formally defined anywhere except https://tools.ietf.org/html/draft-worley-sipping-pickup-01? I think that url-encoding URIs into URIs and further into URI is an ill way to do things (like XML?) MBus drafts seemingly belong to a different level, more like API. Regards, Anton. From nobody Fri Feb 20 16:13: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 EE32B1A0266 for ; Fri, 20 Feb 2015 16:13:47 -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 zwML7jCZ4o0I for ; Fri, 20 Feb 2015 16:13:46 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id DBE091A0069 for ; Fri, 20 Feb 2015 16:13:45 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 20 Feb 2015 19:13:44 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Fri, 20 Feb 2015 19:13:44 -0500 From: Andrew Allen To: Brett Tate , "draft-allen-dispatch-routing-out-of-dialog-request@tools.ietf.org" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: comments and question Thread-Index: AdBLfruNr26iqRrfQrGfQ3dR2+6DqgBNoDHg Date: Sat, 21 Feb 2015 00:13:43 +0000 Message-ID: References: <701e6e928785d1de8fe18bab9a2f1306@mail.gmail.com> In-Reply-To: <701e6e928785d1de8fe18bab9a2f1306@mail.gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: comments and question 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: Sat, 21 Feb 2015 00:13:48 -0000 Brett Thanks for reviewing the draft. Responses inline Andrew -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Brett Tate Sent: Wednesday, February 18, 2015 8:28 AM To: draft-allen-dispatch-routing-out-of-dialog-request@tools.ietf.org; disp= atch@ietf.org Subject: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: = comments and question Hi, The following are a few initial comments concerning draft-allen-dispatch-ro= uting-out-of-dialog-request-01. Thanks, Brett ------ 1) RFC 3725 indicates the following. "Third party call control is possible using only the mechanisms specified w= ithin RFC 3261 [1]." This draft appears to currently prevent the above from occurring. Similarly how do you foresee this draft impacting 3PCC call setup such as t= hose depicted within RFC 3725? [AA] It's not my draft that prevents this. In fact my draft is intended to = address the problems that B2BUA intermediaries cause for REFER and SUBSCRIB= E with RFC 3515 and RFC 6665. So it addresses problems with extensions work= ing through B2BUAs not with RFC 3261. If the RFC 3725 procedures don't work= through B2BUAs then that isn't something caused by this draft. 2) Section 3.5 indicates the following. "One advantage of this approach is that there may be some backward compatibility with this mechanism because R= FC 3261 [5] compliant UAs should use the embedded Route header fields when = constructing a request addressed to this Contact URI." That sentence should potentially be adjusted since RFC 3261 section 19.1.5 = appears to indicate that the Route SHOULD NOT be honored. "An implementation SHOULD NOT honor any requested Route header field values= in order to not be used as an unwitting agent in malicious attacks." [AA] Good catch. This would seem to dispel the advantage of this idea which= was proposed on the list during the discussion of an earlier version of th= e draft. I will change the text related to this proposal and mention the RF= C 3261 text if there is a revision of this draft still advocating different= alternatives. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Feb 20 16:16: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 A4ACA1A0266 for ; Fri, 20 Feb 2015 16:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, T_RP_MATCHES_RCVD=-0.01] 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 N7fGzlTIpH9j for ; Fri, 20 Feb 2015 16:16:29 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id EE4011A03A8 for ; Fri, 20 Feb 2015 16:16:22 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 20 Feb 2015 19:13:36 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Fri, 20 Feb 2015 19:13:36 -0500 From: Andrew Allen To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request Thread-Index: AdBLK2suoEtZ1HUNSUmVHxR+2aVIDgAotqcAADeA/BA= Date: Sat, 21 Feb 2015 00:13:35 +0000 Message-ID: References: <54E4D28A.5000707@alum.mit.edu> In-Reply-To: <54E4D28A.5000707@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request 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: Sat, 21 Feb 2015 00:16:32 -0000 Paul Thanks for the review. Responses inline Andrew -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, February 18, 2015 12:58 PM To: dispatch@ietf.org Subject: Re: [dispatch] Revised version of draft-allen-dispatch-routing-out= -of-dialog-request Andrew, This draft proposes new mechanism(s) intended to mitigate problems caused b= y certain types of B2BUA intermediaries. My biggest problem with this draft is that it makes assumptions about how s= uch intermediaries function. Those assumptions are not well specified. The way sip deployments have evolved we now have a very complex ecosystem o= f components interconnected by SIP, with some of their behavior defined by = the various ietf SIP standards, and some of it defined by 3gpp specificatio= ns, and some by a multitude of proprietary mechanisms. Most of this is depe= ndent on "clever" manipulations by devices loosely described in ietf terms = as B2BUAs, but that in practice take license with the few standards governi= ng B2BUA, taking the view that they can break rules features when it suits = them. The result is a complex architecture that isn't written down anywhere I kno= w of. For awhile now we have been getting proposals for new features and extensio= ns to existing features to fix things that have been broken by that archite= cture. (RFC6809 is one, your draft is another.) Each of these propose a "pa= tch". But this seems to be just patching around the edges without any clear= understanding of how many (if any) problems are being addressed. I think you must be much more explicit about your assumptions. (E.g., I sus= pect you have 3gpp intermediaries in mind. Do those assumptions also apply = to business systems such as Cisco deploys, that also employ B2BUA intermediaries?) Those who aren't deeply steeped in 3gpp specs don't know w= hat those intermediaries do. [AA] The draft is not intended to solve all problems that SBCs or other int= ermediaries may cause. It is only intended to provide a tool to cause reque= sts to be routed via certain nodes that may need to receive them when previ= ously those nodes received them because of Record-Route and dialog reuse (w= hich has now been deprecated by RFC 6665). I can add some specific examples= of some of the behaviors in 3GPP land that have problems without dialog re= use. Now for some more specific points: * Are the intermediaries you are concerned with all B2BUAs? Or could proxie= s also have such needs? [AA] Potentially proxies also might want to force related requests (such as= REFER and SUBSCRIBE ) to also go by them - one reason might be charging. i= .e. the request would not be charged for separately if it is related to an = existing session. * I'm confused when you talk about these B2BUAs "even terminating the dialo= g for some mid session requests", as if that was extraordinary.=20 AFAIK a B2BUA by definition terminates *all* requests and dialogs that reac= h it. Else it isn't a UA. Of course it may, usually, originate a correspond= ing request or dialog on the other "side". (For some types of B2BUA it may = be unusual when it processes an incoming request in some way other than ori= ginating a corresponding request.) If you have a different view of this, th= en I think we are not talking about a true B2BUA, but rather something that= has no formal definition in SIP. [AA] My bad terminology. What I mean here is that the intermediary may act= as a UAS for the request and not forward it on (e.g. service the REFER on = behalf of the intended recipient such as perform the transfer). I will chan= ge this terminology in the next version. * In section 2 you say: One way B2BUAs have have addressed this problem is by acting as two UAs back-to-back with the Contact URI being overwritten to be the URI of the B2BUA. However this means that GRUU of the UA is overwritten by the B2BUA and the meaning of the Contact header field parameters becomes obscure. Do the Contact header field parameters reflect the capabilities of the Contact address (i.e the B2BUA) or do they reflect the capabilities of the remote UA? If they relect the capabilities of the B2BUA then the identfication of the capabilities of the remote UAS has been lost. If they reflect the capabilities of the remote UA then they falsely identify that the B2BUA contact address has the capabilities of the remote UA. While some have advocated that a B2BUA should only indicate the capabilities that it understands and supports in the Contact, in the opinion of the author this is not desirable behavior because the feature tags may indicate many kinds of capabilities which do not require the support of the intermediary. ... They may not require the active *support* of the intermediary. But they lik= ely do still require that intermediaries don't impede them. And this does h= appen. Without rules on what intermediaries can do there is no way to know = in a general way if an arbitrary feature will work in the presence of a par= ticular intermediary. [AA] If an intermediary does block a particular feature that it understands= then it is appropriate for it to indicate that it does not allow that feat= ure. However I would hope that most intermediaries don't block everything t= hey don't understand as that destroys the creation of new features and serv= ices. The feature capability indicator is IMHO a better mechanism for an in= termediary to indicate what features it supports / allows than monkeying wi= th the Contact. The Contact conveys important end to end information and in= formation that should be valid outside of that dialog or that session. Feat= ure tags like sip.automata, sip.class, sip.duplex, sip.mobility, sip.descri= ption, sip.priority, sip.actor and sip.isfocus are characteristics of the r= emote UA and an intermediary has no business changing those. B2BUAs changin= g the contact potentially breaks all that. ISTM that if an intermediary imposes itself as a B2BUA in a dialog, and mak= es any claim to being "transparent" (like a proxy), then it is obligated to= do whatever is necessary to make itself transparent. In many/most cases th= at will likely involve introducing its own Contact addresses. If an incomin= g Contact address is a gruu, then the surrogate contact address used by the= intermediary should also have the gruu property. Feature tags can be "forw= arded" to the extent that the intermediary knows that its presence won't br= eak them. (If it *really* thinks it can be transparent to features it knows= nothing about, then it can simply forward on unknown ones.) [AA] I disagree. I think its bad practice for intermediaries to change the = contact address and lose the contact information of the remote UA. This inf= ormation including the GRUU of the remote UA ought to be valid outside of t= his dialog or session. Having an intermediary mislead a UA into thinking th= at the intermediaries GRUU is the GRUU of the remote UA to me goes against = the basic openness principle as well as meaning the UA can never learn the = GRUU of the remote UA.=20 This does impose a maintenance burden on those that deploy such intermediar= ies, to ensure that they support everything needed by their endpoints. But = that is the unavoidable cost of using such things. (You can make your life = easier by using proxies rather than B2BUAs.) [AA] I don't like SBCs either but they do exist and we need to make sure th= at things work with them - at the very least things that used to work pre R= FC 6665 without losing the benefits or fixes that RFC 6665 was intended to = bring. * next the draft says: ... In the opinion of the author the feature capability indicator mechanism defined in RFC 6809 [2] is the appropriate means for an intermediary to indicate the capabilities that it supports and will allow. While this is consistent with RFC 6809 I fail to see how it has anything to= do with the the problem stated in *this* draft. Feature-Caps indicates fea= tures that are present somewhere along the path of the current dialog. It d= oesn't, by default, even indicate which intermediary provides the service. = While some feature-tags may include a URI as part of their value, that URI = doesn't necessarily refer to an entity that is on the path of the current d= ialog. [AA] What I am arguing is that intermediaries shouldn't change the contact = address and that there is another means to indicate what capabilities such = as media capabilities that may be required to be supported by intermediarie= s for certain sessions to succeed. * next: ... It also should be recognised that UAs may store Contact addresses especially if they are GRUUs for use later for originating sessions (e.g. stored in the address book) or for filtering incoming sessions (e.g. incoming sessions addressed to temporary GRUUs). So if the Contact address is overwritten then this information is lost or not valid as a contact outside the lifetime of the current dialog. Does anybody really put Contacts into address books? I'd be shocked if they= were. I bet it is always To/From/P-A-ID that ends up in address books. [AA] Since GRUU has not yet been widely deployed probably not currently. Bu= t if we get widespread deployment of GRUU then I think it is a perfectly re= asonable thing to do to store the GRUUs in an address book. Currently we ha= ve different URIs for different devices: Mobile, Work, Home, Fax, IM client= etc. In the future hopefully we can have a single URI for the user. Public= GRUUs can then identify each device for the times a user wants to reach a = user at a particular device. The "call me back in 5 minutes at this number"= isn't very helpful when all the devices of the user share the same URI. Sa= ving the Public GRUU is one way to reach the user at a particular device. A= lso temporary GRUUs can allow for a later call back but allow the user to d= ecide if they want to accept an anonymous call back to the temporary GRUU t= hey provided in an earlier anonymous call.i.e. they placed an anonymous cal= l to an merchant and now the merchant is calling them back (however they al= ready made the purchase from someone else so they don't want to accept the = call anymore). If intermediaries overwrite the Contact Address then all the= se capabilities are lost. * next: ... Additionally the mechanism defined in RFC 6665 [3] depends on the UA receiving a GRUU as the remote target in order to avoid dialog reuse, so overwriting the Contact Address breaks this mechanism. So when a B2BUA replaces the Contact, the replacement should have the gruu = property. Why is this a problem for RFC 6665 compatibility? [AA] I suspect that the SBCs are not replacing a GRUU with another GRUU. Ba= sed on a comment from Hadriel on an earlier version of the draft most SBCs = will likely replace the GRUU with a non GRUU especially now that dialog reu= se is deprecated for the case when the UA has received a GRUU as the remote= target. Without an alternative mechanism that makes it possible for interm= ediaries to indicate that REFER and SUBSCRIBE which previously visited them= through dialog reuse are still to be routed via them, then intermediaries = will continue to force dialog reuse by replacing GRUUs in the contact with = non GRUUs (at least not with the gr parameter. * IIUC, the intent is that when a UA is in a dialog, and wishes to send an = out of dialog request that refers to that dialog, must take special steps t= o make that work: extract the special route from the dialog and incorporate= it into the out of dialog request. [AA] In the case of REFER and SUBSCRIBE with RFC 6665 it's no longer wishes= to send out of dialog it is MUST send out of dialog if the remote target i= s a GRUU and a subscription could be created. What criterion does the UA use to decide when to do this? Is it the presenc= e of certain header fields in the request? (Replaces, Join, Target-Dialog).= Is that well defined and exhaustive? [AA] At least if it previously would have sent a REFER or SUBSCRIBE within = the dialog. Probably a good idea to do this for all session related REFER r= equests. What about cases where the client referencing an existing dialog already in= that dialog? For instance, a client using the dialog event package to disc= over an existing dialog and then sending a request to replace it.=20 IDoes that client need to know about the intermediaries? If so, how would i= t learn, and what if it doesn't? [AA] My intention isn't to solve all problems caused by SBCs and other B2BU= As. The primary goal is to make the out of dialog REFER and SUBSCRIBE as re= quired by RFC 6665 work (because they used to work in dialog). Other drafts= could be written to solve other issues. I suppose the dialog events packag= e could be extended to provide also the route set that established the dial= og (which would the contain the OOD route indicator as well and then the re= quest sent to replace it could be routed via those intermediaries. Many clients, when sending out of dialog requests, already have a Route hea= der to apply to that request. (E.g., via Service-Route.) How should the URI= s of these interested intermediaries be sorted into that predefined route? [AA] I agree any solutions draft will need to address this. Any intermediar= ies that need to be routed via are after the Service-Route (ones in the Se= rvice-Route don't need to indicate OOD as they are already in the Route set= . The Service Route ensures routing via intermediaries as far as the servin= g network of the UA the problem is intermediaries after the serving network= of the UA. =09 Thanks, Paul On 2/17/15 10:39 PM, Andrew Allen wrote: > I have submitted a revised version of draft-allen-dispatch-routing-out-of= -dialog-request. This document discusses the problems for out of dialog req= uests that are related to another dialog, caused by B2BUA intermediaries th= at modify SIP parameters or terminate dialogs and proposes some possible so= lutions. This draft is related to the recent work on RFC 6665 that deprecat= es dialog reuse when creating subscriptions using SUBSCRIBE and REFER. > > > > I would like to request discussion time during Dispatch at IETF#92. Earli= er list discussion indicated that either sipcore or STRAW would be the appr= opriate place to work on solutions to this issue. > > > > The draft can be found at: > > > > http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-requ > est-01.txt > > Please provide comments on the contents and on which WG would be an=20 > appropriate for the work. > > Andrew > > > > _______________________________________________ > 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 Mon Feb 23 06:23: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 AB46C1A1AD0 for ; Mon, 23 Feb 2015 06:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 Qq_5iu3pcqJ6 for ; Mon, 23 Feb 2015 06:23:26 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6265C1A1A57 for ; Mon, 23 Feb 2015 06:23:25 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id dc16so22148880qab.7 for ; Mon, 23 Feb 2015 06:23:25 -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=2H7+GzEe9jR59HDMQ3nPnnwA2Blach6YG6PJMAdoaoA=; b=eWGb5YOQj6MHKu2/GJqz3J0V5nEZEkzu89kR4UmAL5RrMl2TDfGm9Z2uHS1FGNSpQX 1nFhr+d6zkN9RCTsoN0Ehh5JE0SUygb+az1c2EIYr2UvsjA21qbO5pkVvxYYECHO/oXt a50i6r3sETvpOTvHMDFtYfIuId4SUmNm6wX0Zp1F3+NmfTS5+S1TnloVm5GGnpaPoK8z striR2d/f1LddqHaCTC1INImYMA/6iiaYvztP31C4Rkm8XJSOnKmQSudpaSqg27T3r4W oLLQ1wWMYHLDbVawEoxe0eRe6X3HU7yb6r5qcSYSTW9aulTMN8oZqunuysg8VgYUodHG e4NQ== X-Gm-Message-State: ALoCoQmjS680Yp4KnSCZNNJ9H1i9luE9ze4vGmgAsYm2B3kDD+etL+K4QMDCObe5uNCZ3vii+VMX X-Received: by 10.229.192.5 with SMTP id do5mr25896000qcb.12.1424701405146; Mon, 23 Feb 2015 06:23:25 -0800 (PST) From: Brett Tate References: <701e6e928785d1de8fe18bab9a2f1306@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDxESca/TrqW/JXSDiLBBWSLyepAFVHiWunQyUjnA= Date: Mon, 23 Feb 2015 09:23:24 -0500 Message-ID: <7e665caac04188f82658f5a52ceb4bea@mail.gmail.com> To: draft-allen-dispatch-routing-out-of-dialog-request@tools.ietf.org, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: comments and question 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, 23 Feb 2015 14:23:27 -0000 Hi, Thanks for the response; reply is inline. > 1) RFC 3725 indicates the following. > > "Third party call control is possible using only > the mechanisms specified within RFC 3261 [1]." > > This draft appears to currently prevent the above > from occurring. Similarly how do you foresee this > draft impacting 3PCC call setup such as those > depicted within RFC 3725? > > [AA] It's not my draft that prevents this. In fact > my draft is intended to address the problems that > B2BUA intermediaries cause for REFER and SUBSCRIBE > with RFC 3515 and RFC 6665. So it addresses problems > with extensions working through B2BUAs not with > RFC 3261. If the RFC 3725 procedures don't work > through B2BUAs then that isn't something caused by > this draft. I'm referring to 3PCC devices which are B2BUAs. The draft's current proposal is that the B2BUA not use its own Contact. One of the potential solutions should mention the potential for B2BUA to replace the Contact (with whatever you want to say concerning parameters). This is potentially the only option which can continue to work for RFC 3725 3PCC B2BUAs desiring to remain interoperable with basic RFC 3261 devices. Some of the use cases to consider when selecting/documenting a solution should be 3PCC as documented within RFC 3725 (such as 10.1 and 10.2). From nobody Tue Feb 24 04:33: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 1647D1A877F for ; Tue, 24 Feb 2015 04:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Dezpvo77z9TD for ; Tue, 24 Feb 2015 04:33:47 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629C11A877E for ; Tue, 24 Feb 2015 04:33:47 -0800 (PST) Received: by qcyl6 with SMTP id l6so16169303qcy.2 for ; Tue, 24 Feb 2015 04:33:46 -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=Fm/bqYxWDqPFcZERpMnX9CgvGcdbp86S8GxCBm5oeZ8=; b=DIvBVkdow04JWFpqTdHKB1At5A/OGyq/zzL0ZKSdvFXRndWnIay6NqqWK8um5fRj1B eYrEPYyzUhb26VCowr7Y16UqoPm3mlMAZZU3uFPbctbi/dBfif5FQDrGV0yHgIQ4LibK H9JASozYHRTG6Hto1aJt6GWvL/+EV6Jkmst04NV5wsPGph7bq60yo+/i9RxUEtoBdm2W IVyUc9Ju9Lpp42M0OKojYtZ1vk3xvJXQ6JfNS2fzjaaSIjCI1AGRrutZd7Vv1JKdRjlH WnfO2L/SB2hBCw6asfRl8HAjErv4/4G9MFKG/+748X5RZTbyIuAnUNaMspP028ukV3dQ Vz1g== X-Gm-Message-State: ALoCoQn+ZoXhhP9ZD+mOKLaJw4Wl5Qpqz1115LS8ARcmVamnMvrw9c3Pa/I3IBJk8WBBeOAn2W0I X-Received: by 10.140.21.48 with SMTP id 45mr34372093qgk.87.1424781226452; Tue, 24 Feb 2015 04:33:46 -0800 (PST) From: Brett Tate References: <54E4D28A.5000707@alum.mit.edu> <54EB60BC.1020401@alum.mit.edu> In-Reply-To: <54EB60BC.1020401@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGDXgFqfRwcQDKWpSpcyvgMOOgeVAKN/6a2AOAeVbkCS1TCc51rxgkg Date: Tue, 24 Feb 2015 07:33:45 -0500 Message-ID: <1aa7c8ad34833b27a09ca95309206f2f@mail.gmail.com> To: Paul Kyzivat , Andrew Allen , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request 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, 24 Feb 2015 12:33:49 -0000 > I expect it is probably no great burden for the address to > be globally routable. The fact that it doesn't contain 'gr' > is then a *policy* decision. > So you are arguing that currently they do this by policy to > force dialog reuse. I guess that is plausible. But if they > tagged their replacement contact as a gruu they would still > get the new requests, but out of dialog. If that is a problem > for them, it is just them being lazy, wanting to reuse old code. The following summary points from draft-kaplan-dispatch-gruu-problematic section 7 potentially indicate why some B2BUAs might not be supplying a gruu location (per configuration or otherwise). "In summary, the following points have been made: - Generating GRUUs which are not actually globally routable may cause more harm than not using GRUUs - A GRUU generator has no practical means of determining if the GRUU is globally routable, by every device which can receive it" Although some don't like B2BUAs or the concept of walled gardens, the B2BUAs may be deployed within walled gardens. Thus they potentially don't always have a globally reachable location to supply within the Contact (even though SIPCORE prefers to declare such a deployment as non-compliant). From nobody Tue Feb 24 15:35: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 D4C231A044D for ; Tue, 24 Feb 2015 15:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 v07s4OaHpjFt for ; Tue, 24 Feb 2015 15:35:54 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 2AB7A1A0404 for ; Tue, 24 Feb 2015 15:35:54 -0800 (PST) Received: (qmail 7153 invoked by uid 0); 24 Feb 2015 23:35:50 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 24 Feb 2015 23:35:50 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id wPbh1p00V1MNPNq01Pbkbh; Tue, 24 Feb 2015 16:35:50 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=yzGsJ_kaSJTH4ywiPr4A:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=T6OtXD6WGDFFu2m34D8A:9 a=UPUXymDLgta0xV5k:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=B8y54U98aW/byf2x55oxzVU6d3gQQg5AEVFmqj95r9I=; b=Am3IDQlcvUKFZ/hUz5cIYOoXUYrICLIrlyuuIq3nxPscHkIPhNA162/G3QCFs/q+lOf1vtf6nariQcjyly1TXLEb6tYDsvfrFgWGGXiEdG0wsfgrTl3Z7X/OWTfKbSb/; Received: from [108.56.131.201] (port=59696 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQP0u-0001N7-Od; Tue, 24 Feb 2015 16:35:41 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 24 Feb 2015 18:35:36 -0500 From: Richard Shockey To: "Holmes, David W [CTO]" , "Peterson, Jon" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] draft charter Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507647740_1709012" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] [Modern] draft charter 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, 24 Feb 2015 23:35:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507647740_1709012 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Excellent points David. My concern here is charter overreach. I really want to keep CNAM+/CNIT out of this. IMHO that is a very separate and highly focused effort to define both the modification of the SIP headers necessary to support some enhanced calling party identification and a very limited effort to define the object and or the STIR validation data. I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. If registries can be used fine but I certainly want to see how this can be accomplished in bi lateral agreements between consenting service providers and work with CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP. Certainly the relevance of CNAM+/CNIT in enterprise and residential access markets is important but we all know =B3Money is the answer what is the question ..=B2 I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and report o= n the JTF on NNI. As you well know we have made considerable progress. Last week I gave a talk on this to a panel that included many of our friend= s among the national regulators. http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Holmes, David W [CTO]" Date: Tuesday, February 24, 2015 at 5:06 PM To: "Peterson, Jon" , "modern@ietf.org" Subject: Re: [Modern] draft charter Jon,=20 =20 Thank you for the work in assembling this draft of the charter for MODERN. =20 We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out of context; i.e. the group product will be the protocols to support the allocation etc. activities, & it would not attempt to define the allocation processes. We also would like the charter to note the relevant work that has already been performed by both IETF & th= e ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG a= s appropriate. These changes/additions are have been added to your text inline below.=20 =20 We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to othe= r commitments that week. =20 Regards,=20 =20 David/Sprint=20 ___________________________________________________________________________= _ __ =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter =20 =20 At the Dallas IETF meeting in March, we'd like to get together and talk about what a working group for MODERN might look like. As an initial input to the discussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DISPATCH process, we feel thi= s is broader enough in scope to warrant its own BoF. =20 Comments are welcome, this is just a starting point. =20 ------ =20 Modern charter text: =20 The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment. Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible. The traditional model of a TN having an association to a single service provider and a single application is breaking down. Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. =20 The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes = a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the enrollment data and security of the resource will be primary considerations. =20 Additionally, the working group will deliver a protocol mechanism for resolving TNs which will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS. =20 The work of this group is limited to specifying a solution for TNs and covers any service that can be addressed using a TN. Expanding the work to other identifiers is out of scope. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies. =20 The work group will deliver the following: =20 - An architecture overview document that includes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment processes for existing and new TNs including any modifications to metadata related to those TNs - A document describing protocol mechanisms for accessing contact information associated with enrollments - A document describing protocol mechanisms for resolving information related to TNs =20 - =20 This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not th= e intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3507647740_1709012 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Excellent= points David.  

My concern here is charter ov= erreach. I really want to keep CNAM+/CNIT out of this.  IMHO that is a = very separate and highly focused effort to define both the modification of t= he SIP headers necessary to support some enhanced calling party identificati= on and a very limited effort to define the object and or the STIR validation= data.  

I’m violently opposed to “= ;end world hunger” WG’s. 

If regis= tries can be used fine but I certainly want to see how this can be accomplis= hed in bi lateral agreements between consenting service providers and work w= ith CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft i= n the context of a formal liaison with 3GPP.  Certainly the relevance o= f CNAM+/CNIT in enterprise and residential access markets is important but w= e all know “Money is the answer what is the  question ..” &= nbsp;

I’ve asked for time in Dispatch to look= at the CNAM/CNIT issue and report on the JTF on NNI. As you well know we ha= ve made considerable progress.

Last week I gave a t= alk on this to a panel that included many of our friends among the national = regulators.  




&#= 8212; 
Richard Shockey
Shockey Consulting LLC
=
Chairman of the Board SIP Forum
www.shockey.us
www.= sipforum.org
richard<at>shockey.us
Skype-Linkedin-= Facebook rshockey101
PSTN +1 703-593-2683


From: "Holmes, Da= vid W [CTO]" <David.Holmes@sprin= t.com>
Date: Tuesday, Febru= ary 24, 2015 at 5:06 PM
To: "Peter= son, Jon" <jon.peterson@neustar= .biz>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft charter

Jon,

 

Thank you for the wor= k in assembling this draft of the charter for MODERN.

 

We would like to suggest some minor clarifica= tions to the bullets describing the deliverables, to align them with the sta= tement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the allo= cation etc. activities, & it would not attempt to define the allocation = processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the M= ODERN WG as appropriate.  These changes/additions are have been added t= o your text inline below.

 

We are hoping that the MODERN session at IETF= #92 will have remote access, to allow participation by those of us that cann= ot attend in person due to other commitments that week.  

 

Regards,

 

David/Sprint

________________________________________________________________________= ______

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2= 015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

 

At the Dallas IETF meeting in March, we'= d like to get together and talk about what a working group for MODERN might = look like. As an initial input to the discussion, a few of us have put toget= her a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own B= oF.

 

Comments are welcome, this is just a starting p= oint.

 

------

 

<= p class=3D"MsoNormal">Modern charter text:

 =

The MODERN working= group will define a set of Internet-based mechanisms for the purposes of ma= naging and resolving telephone numbers (TNs) in an IP environment.  Exi= sting mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w applications for TNs become possible.  The traditional model of a TN = having an association to a single service provider and a single application = is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or a= n organization will remain for some time. Devices, applications, and network= tools increasingly need to manage TNs, including requesting and acquiring T= N delegations from authorities.

 

The working group will define a framework for the roles and f= unctions involved in managing and resolving TNs in an IP environment. This i= ncludes a protocol mechanism for acquiring TNs, which will provide an enroll= ment process for the individuals and entities that use and manage TNs. TNs may = either be managed in a hierarchical tree, or in a distributed peer-to-peer a= rchitecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 =

Additio= nally, the working group will deliver a protocol mechanism for resolving TNs= which will allow entities such as service providers, devices, and applicati= ons to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The = working group will take into consideration existing IETF work including ENUM= , SPEERMINT, STIR, and DRINKS.

 =

The wor= k of this group is limited to specifying a solution for TNs and covers any s= ervice that can be addressed using a TN.  Expanding the work to other i= dentifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The wor= k group will deliver the following:

 

-      =     An architecture overview document that inc= ludes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Foru= m JTF, that included:

o   Call routing architecture =

o   Inter-carrier NNI

o   Cryptographically-enabled Anti-spoofi= ng (STIR)

oEnhanced Calling Name (CNIT/CNAM)

-=           A document describing the protocols to support enrollment processes for existing and = new TNs including any modifications to metadata related to those TNs

-&= nbsp;         A document describing protocol mechanisms = for accessing contact information associated with enrollments

- &nbs= p;        A document describing protocol mechanisms for resolving information r= elated to TNs

 

-       = ;    


<= br> This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3507647740_1709012-- From nobody Tue Feb 24 18:03: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 3DD031A9077; Tue, 24 Feb 2015 18:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 xpmkT1eW7FnI; Tue, 24 Feb 2015 18:03:09 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E8D1A9073; Tue, 24 Feb 2015 18:03:08 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id a5d2de45.0.5269730.00-1965.14830243.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Feb 2015 02:03:09 +0000 (UTC) X-MXL-Hash: 54ed2d5d68c1b717-ccb1b3168eba8ca4cce064b800c926e7d063979c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1P235pM017826; Tue, 24 Feb 2015 21:03:06 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1P22tYM017752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Feb 2015 21:02:58 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 25 Feb 2015 02:02:41 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.167]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 21:02:41 -0500 From: "DOLLY, MARTIN C" To: Richard Shockey Thread-Topic: [dispatch] [Modern] draft charter Thread-Index: AQHQUJ8jttaE08TRjkylaRACfmlD9Q== Date: Wed, 25 Feb 2015 02:02:41 +0000 Message-ID: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4DA2FD252B324812A9FEE8649BED9989attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EtBlW1gA c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=doUQ] X-AnalysisOut: [ZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=izV7ms69AAA] X-AnalysisOut: [A:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=iy2iwTbxphpkVQNCo6] X-AnalysisOut: [MA:9 a=pILNOxqGKmIA:10 a=JpNyA6z_r-EA:10 a=ivbTfD_dPm4A:10] X-AnalysisOut: [ a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=QuLkP43yR8ib2NjKHewA:9 a=UiCQ7L4-1S4A:10 a=] X-AnalysisOut: [hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 02:03:13 -0000 --_000_4DA2FD252B324812A9FEE8649BED9989attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support Richard on this Martin Dolly Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey > wrote: Excellent points David. My concern here is charter overreach. I really want to keep CNAM+/CNIT out = of this. IMHO that is a very separate and highly focused effort to define = both the modification of the SIP headers necessary to support some enhanced= calling party identification and a very limited effort to define the objec= t and or the STIR validation data. I=92m violently opposed to =93end world hunger=94 WG=92s. If registries can be used fine but I certainly want to see how this can be = accomplished in bi lateral agreements between consenting service providers = and work with CUA vendors on how the data is displayed aka Apple, Samsung, = Microsoft in the context of a formal liaison with 3GPP. Certainly the rele= vance of CNAM+/CNIT in enterprise and residential access markets is importa= nt but we all know =93Money is the answer what is the question ..=94 I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on the JTF on NNI. As you well know we have made considerable progress. Last week I gave a talk on this to a panel that included many of our friend= s among the national regulators. http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM To: "Peterson, Jon" >, "modern@ietf.org" > Subject: Re: [Modern] draft charter Jon, Thank you for the work in assembling this draft of the charter for MODERN. We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility = to support the needs of different regulatory regimes, & thus to ensure that= if quoted alone they are not taken out of context; i.e. the group product = will be the protocols to support the allocation etc. activities, & it would= not attempt to define the allocation processes. We also would like the ch= arter to note the relevant work that has already been performed by both IET= F & the ATIS/SIP Forum JTF, & incorporate that into the output from the MOD= ERN WG as appropriate. These changes/additions are have been added to your= text inline below. We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to ot= her commitments that week. Regards, David/Sprint ___________________________________________________________________________= ___ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern charter text: The MODERN working group will define a set of Internet-based mechanisms for= the purposes of managing and resolving telephone numbers (TNs) in an IP en= vironment. Existing mechanisms for these purposes face obsolescence as the= voice communications infrastructure evolves to IP technology and new appli= cations for TNs become possible. The traditional model of a TN having an a= ssociation to a single service provider and a single application is breakin= g down. Its use as a network locator is going away, but its use as an iden= tifier for an individual or an organization will remain for some time. Devi= ces, applications, and network tools increasingly need to manage TNs, inclu= ding requesting and acquiring TN delegations from authorities. The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. TNs may either b= e managed in a hierarchical tree, or in a distributed peer-to-peer architec= ture. Privacy of the enrollment data and security of the resource will be = primary considerations. Additionally, the working group will deliver a protocol mechanism for resol= ving TNs which will allow entities such as service providers, devices, and = applications to access data related to TNs, possibly including caller name = data (CNAM). Maintaining reliability, real time application performance, s= ecurity and privacy are primary considerations. The working group will tak= e into consideration existing IETF work including ENUM, SPEERMINT, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. Solutions and mechanisms created by the wo= rking group will be flexible enough to accommodate different policies, e.g.= , by different regulatory agencies. The work group will deliver the following: - An architecture overview document that includes high level requi= rements and security/privacy considerationsbuilt on the work of IETF & the = ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment proces= ses for existing and new TNs including any modifications to metadata relate= d to those TNs - A document describing protocol mechanisms for accessing contact = information associated with enrollments - A document describing protocol mechanisms for resolving informat= ion related to TNs - ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/mode= rn _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_4DA2FD252B324812A9FEE8649BED9989attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I support Richard on this 

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and 
Industry Alliances
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  

My concern here is charter overreach. I really want to keep CNAM+/= CNIT out of this.  IMHO that is a very separate and highly focused eff= ort to define both the modification of the SIP headers necessary to support= some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I=92m violently opposed to =93end world hunger=94 WG=92s. 

If registries can be used fine but I certainly want to see how this ca= n be accomplished in bi lateral agreements between consenting service provi= ders and work with CUA vendors on how the data is displayed aka Apple, Sams= ung, Microsoft in the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNI= T in enterprise and residential access markets is important but we all know= =93Money is the answer what is the  question ..=94  

I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and r= eport on the JTF on NNI. As you well know we have made considerable progres= s.

Last week I gave a talk on this to a panel that included many of our f= riends among the national regulators.  




=97 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From: "Holmes, David W [CTO]&q= uot; <David.Holmes@sprint.com= >
Date: Tuesday, February 24, 2015 at= 5:06 PM
To: "Peterson, Jon" <<= a href=3D"mailto:jon.peterson@neustar.biz">jon.peterson@neustar.biz>= , "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft charter=

Jon, =

=  

Thank= you for the work in assembling this draft of the charter for MODERN.

=  

We wo= uld like to suggest some minor clarifications to the bullets describing the= deliverables, to align them with the statement regarding flexibility to su= pport the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the all= ocation etc. activities, & it would not attempt to define the allocatio= n processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the = MODERN WG as appropriate.  These changes/additions are have been added= to your text inline below.

=  

We ar= e hoping that the MODERN session at IETF#92 will have remote access, to all= ow participation by those of us that cannot attend in person due to other c= ommitments that week.  

=  

Regar= ds,

=  

David= /Sprint

_____= _________________________________________________________________________

=  

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

&n= bsp;

At the = Dallas IETF meeting in March, we'd like to get together and talk about what= a working group for MODERN might look like. As an initial input to the dis= cussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own = BoF.

&n= bsp;

Comment= s are welcome, this is just a starting point.

&n= bsp;

------<= o:p>

&n= bsp;

Modern charter text:

 =

The MODERN working group= will define a set of Internet-based mechanisms for the purposes of managin= g and resolving telephone numbers (TNs) in an IP environment.  Existin= g mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w applications for TNs become possible.  The traditional model of a TN= having an association to a single service provider and a single applicatio= n is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or a= n organization will remain for some time. Devices, applications, and networ= k tools increasingly need to manage TNs, including requesting and acquiring= TN delegations from authorities.

 =

The working group will d= efine a framework for the roles and functions involved in managing and reso= lving TNs in an IP environment. This includes a protocol mechanism for acqu= iring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may = either be managed in a hierarchical tree, or in a distributed peer-to-peer = architecture.  Privacy of the enrollment data and security of the reso= urce will be primary considerations.

 =

Additionally, the workin= g group will deliver a protocol mechanism for resolving TNs which will allo= w entities such as service providers, devices, and applications to access d= ata related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The= working group will take into consideration existing IETF work including EN= UM, SPEERMINT, STIR, and DRINKS.

 =

The work of this group i= s limited to specifying a solution for TNs and covers any service that can = be addressed using a TN.  Expanding the work to other identifiers is o= ut of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The work group will deli= ver the following:

 =

- = ;         An architecture overview document that i= ncludes high level requirements and security/privacy considerations<= span style=3D"color:#1F497D">built on the work of IETF & the ATIS/SI= P Forum JTF, that included:

o   Call routing architecture

o   Inter-carrier NNI=

o   Cryptographically-enabled Anti-spoo= fing (STIR)

o   Enhanced Calling Name (CNIT/CNAM)

-&nbs= p;         A document describing the protocols to support enrollment processes for existing an= d new TNs including any modifications to metadata related to those TNs=

-&nbs= p;         A document describing protocol mechanism= s for accessing contact information associated with enrollments<= /span>

- =          A document describing protocol mechanisms for resolving information= related to TNs

=  

- &n= bsp;         <= /o:p>



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_4DA2FD252B324812A9FEE8649BED9989attcom_-- From nobody Wed Feb 25 09:06:48 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 E1F171A90C4 for ; Wed, 25 Feb 2015 09:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 bOWAof1WnCx0 for ; Wed, 25 Feb 2015 09:06:41 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id D6A9C1A0193 for ; Wed, 25 Feb 2015 09:06:40 -0800 (PST) Received: (qmail 5483 invoked by uid 0); 25 Feb 2015 17:06:38 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 25 Feb 2015 17:06:38 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id wo5C1p00h1MNPNq01o5Fc6; Wed, 25 Feb 2015 17:05:24 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=0Or7jusycULVaPx2pgEA:9 a=rpj6ZxKFMDNLe-dQ:21 a=_AFRu06Vt3MRSuX4:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=hzi90bUycbL9tOCHrCUA:9 a=KhwY1BwdpY_w7US2:21 a=9qgP4eEyyhwikyru:21 a=mK_KfrpBNI_agG4o:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=XeIq556CbkeiZBxs1O5oyTHEdymKPuVHBEQk5lUDaJA=; b=XFb5vOovja5RB8KdLLfv01y8YqBFSL61Qxbzh//xR8xOnuQLxP4sf9SwfR/vGgBToDDCrOuY6KNNJKELY6/TUke8k3ySKua+2BGvrK0aP36ySq8y4Ny+YIJfUtGHogU5; Received: from [108.56.131.201] (port=55216 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQfOb-0003nB-PV; Wed, 25 Feb 2015 10:05:14 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 12:05:08 -0500 From: Richard Shockey To: "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [dispatch] draft charter Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507710713_441257" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: "Holmes, David W \[CTO\]" , cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 17:06:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507710713_441257 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks Martin .. This is my very raw first cut at a charter. Its hopefully simple and straight forward. Send me any edits etc. ***** CNIT Charter [Calling Name Identity Trust] WG Chairs TBD: Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters of information associated with a specific E.164 calling party number in the Public Switched Telephone Network [PSTN]. In the PSTN this data is sent by the originating network only at the specific request of the terminating network via a SS7 Transaction Application Part [TCAP] response message. In the Session Initiation Protocol [SIP] this information can be inserted into the FROM: part of the originating INVITE message or by other means. As with the originating source telephone number, this data can be altered i= n transit creating a variety of malicious abuses similar to the ones identified by the IETF STIR working group. The purpose of the CNIT working group will be to define a data structure, a new SIP header or repurpose an existing SIP header to carry an advanced for= m of CNAM as well as information from a STIR Validation Authority. The purpose of this work is to present to the SIP called party trusted information from the calling party in order that the called party make a more reasoned and informed judgment on whether to accept the INVITE or not. The working group will not invalidate any existing SIP mechanism for anonymous calling.=20 The working group will, to the best of its ability, reuse existing IETF protocols. Full Internationalization of the Calling Name Identity Trust data object(s) is a requirement. The working group will closely work with the IETF STIR working group The working group will immediately liaison with 3GPP SA-1 in order to coordinate efforts. The working group will coordinate with National Numbering Authorities and National Regulatory Authorities as needed. The working group will deliver the flowing. =80 A problem statement and requirements detailing the current deployment environment and situations that motivate work on Calling Name Identity Trust. =80 Define either a new SIP header or document a repurpose of an SIP existing header for Calling Name Identify Trust data =80 Define a data model for the Calling Name Identity Trust object (s) which may include various forms of multimedia data =80 Deliver an analysis of privacy implications of the proposed Calling Name Identity Trust mechanism. Milestones: =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "DOLLY, MARTIN C" Date: Tuesday, February 24, 2015 at 9:02 PM To: Richard Shockey Cc: "Holmes, David W [CTO]" , "dispatch@ietf.org" , "modern@ietf.org" , "Peterson, Jon" Subject: Re: [Modern] [dispatch] draft charter I support Richard on this Martin Dolly=20 Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and=20 Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey wrote: >=20 > Excellent points David. >=20 > My concern here is charter overreach. I really want to keep CNAM+/CNIT ou= t of > this. IMHO that is a very separate and highly focused effort to define b= oth > the modification of the SIP headers necessary to support some enhanced ca= lling > party identification and a very limited effort to define the object and o= r the > STIR validation data. >=20 > I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. >=20 > If registries can be used fine but I certainly want to see how this can b= e > accomplished in bi lateral agreements between consenting service provider= s and > work with CUA vendors on how the data is displayed aka Apple, Samsung, > Microsoft in the context of a formal liaison with 3GPP. Certainly the > relevance of CNAM+/CNIT in enterprise and residential access markets is > important but we all know =B3Money is the answer what is the question ..=B2 >=20 > I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on > the JTF on NNI. As you well know we have made considerable progress. >=20 > Last week I gave a talk on this to a panel that included many of our frie= nds > among the national regulators. >=20 > http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >=20 >=20 >=20 > From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM > To: "Peterson, Jon" , "modern@ietf.org" > > Subject: Re: [Modern] draft charter >=20 > Jon,=20 > =20 > Thank you for the work in assembling this draft of the charter for MODERN= . > =20 > We would like to suggest some minor clarifications to the bullets describ= ing > the deliverables, to align them with the statement regarding flexibility = to > support the needs of different regulatory regimes, & thus to ensure that = if > quoted alone they are not taken out of context; i.e. the group product wi= ll be > the protocols to support the allocation etc. activities, & it would not > attempt to define the allocation processes. We also would like the chart= er to > note the relevant work that has already been performed by both IETF & the > ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG= as > appropriate. These changes/additions are have been added to your text in= line > below.=20 > =20 > We are hoping that the MODERN session at IETF#92 will have remote access,= to > allow participation by those of us that cannot attend in person due to ot= her > commitments that week. > =20 > Regards,=20 > =20 > David/Sprint=20 > _________________________________________________________________________= _____ > =20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, February 11, 2015 9:19 AM > To: modern@ietf.org > Subject: [Modern] draft charter > =20 > =20 > At the Dallas IETF meeting in March, we'd like to get together and talk a= bout > what a working group for MODERN might look like. As an initial input to t= he > discussion, a few of us have put together a proposed charter. While the T= eRQ > work was positively evaluated in the DISPATCH process, we feel this is br= oader > enough in scope to warrant its own BoF. > =20 > Comments are welcome, this is just a starting point. > =20 > ------ > =20 > Modern charter text: > =20 > The MODERN working group will define a set of Internet-based mechanisms f= or > the purposes of managing and resolving telephone numbers (TNs) in an IP > environment. Existing mechanisms for these purposes face obsolescence as= the > voice communications infrastructure evolves to IP technology and new > applications for TNs become possible. The traditional model of a TN havi= ng an > association to a single service provider and a single application is brea= king > down. Its use as a network locator is going away, but its use as an > identifier for an individual or an organization will remain for some time= . > Devices, applications, and network tools increasingly need to manage TNs, > including requesting and acquiring TN delegations from authorities. > =20 > The working group will define a framework for the roles and functions inv= olved > in managing and resolving TNs in an IP environment. This includes a proto= col > mechanism for acquiring TNs, which will provide an enrollment process for= the > individuals and entities that use and manage TNs. TNs may either be manag= ed in > a hierarchical tree, or in a distributed peer-to-peer architecture. Priv= acy > of the enrollment data and security of the resource will be primary > considerations.=20 > =20 > Additionally, the working group will deliver a protocol mechanism for > resolving TNs which will allow entities such as service providers, device= s, > and applications to access data related to TNs, possibly including caller= name > data (CNAM). Maintaining reliability, real time application performance, > security and privacy are primary considerations. The working group will = take > into consideration existing IETF work including ENUM, SPEERMINT, STIR, an= d > DRINKS.=20 > =20 > The work of this group is limited to specifying a solution for TNs and co= vers > any service that can be addressed using a TN. Expanding the work to othe= r > identifiers is out of scope. Solutions and mechanisms created by the wor= king > group will be flexible enough to accommodate different policies, e.g., by > different regulatory agencies. > =20 > The work group will deliver the following: > =20 > - An architecture overview document that includes high level > requirements and security/privacy considerationsbuilt on the work of IETF= & > the ATIS/SIP Forum JTF, that included: >=20 > o Call routing architecture >=20 > o Inter-carrier NNI >=20 > o Cryptographically-enabled Anti-spoofing (STIR) >=20 > o Enhanced Calling Name (CNIT/CNAM) >=20 > - A document describing the protocols to support enrollment proce= sses > for existing and new TNs including any modifications to metadata related = to > those TNs >=20 > - A document describing protocol mechanisms for accessing contact > information associated with enrollments >=20 > - A document describing protocol mechanisms for resolving informa= tion > related to TNs >=20 > =20 >=20 > - =20 >=20 >=20 >=20 > This e-mail may contain Sprint proprietary information intended for the s= ole > use of the recipient(s). Any use by others is prohibited. If you are not = the > intended recipient, please contact the sender and delete all copies of th= e > message. > _______________________________________________ Modern mailing list > Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3507710713_441257 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

<= div style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size:= 14px;">Thanks Martin .. This is my very raw first cut at a charter. Its hop= efully simple and straight forward.

Send me= any edits etc.

*****

CNIT Charter [Calling Name Iden= tity Trust]

WG Chairs TBD:

Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters o= f information associated with a specific E.164 calling party number in the P= ublic Switched Telephone Network [PSTN].  In the PSTN this data is sent= by the originating network only at the specific request of the terminating = network via a SS7 Transaction Application Part [TCAP] response message. &nbs= p;In the Session Initiation Protocol [SIP] this information can be inserted = into the FROM: part of the originating INVITE message or by other means.

As with the originating source telephone number, thi= s data can be altered in transit creating a variety of malicious abuses simi= lar to the ones identified by the IETF STIR working group.
=
The purpose of the CNIT working group will be to define a data str= ucture, a new SIP header or repurpose an existing SIP header to carry an adv= anced form of CNAM as well as information from a STIR Validation Authority. =  The purpose of this work is to present to the SIP called party trusted= information from the calling party in order that the called party make a mo= re reasoned and informed judgment on whether to accept the INVITE or not.

The working group will not invalidate any existing = SIP mechanism for anonymous calling.  

The w= orking group will, to the best of its ability, reuse existing IETF protocols= .

Full Internationalization of the Calling Name I= dentity Trust data object(s) is a requirement.

Th= e working group will closely work with the IETF STIR working group

The working group will immediately liaison with 3GPP SA-1 = in order to coordinate efforts.

The working group= will coordinate with National Numbering Authorities and National Regulatory= Authorities as needed.
The working group will de= liver the flowing.

• A problem statement and requirements d= etailing the current deployment environment and situations that motivate wor= k on Calling Name Identity Trust.
• D= efine either a new SIP header or document a repurpose of an SIP existing hea= der for Calling Name Identify Trust data
• <= /span>Define a data model for the Calling Name Identity Trust object (s) whi= ch may include various forms of multimedia data
• Deliver an analysis of privacy implications of the proposed Cal= ling Name Identity Trust mechanism.


Milestones:


— 
Richa= rd Shockey
Shockey Consulting LLC
Chairman of the Board = SIP Forum
www.shockey.us
www.sipforum.org
rich= ard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
<= div>PSTN +1 703-593-2683


=
From: "DOLLY, MARTIN C" <md3135@att.com>
Date: Tuesday, February 24, 2015 at 9:02 PM
To: Richard Shockey <richard@shockey.us>
Cc= : "Holmes, David W [CTO]" <David.Holmes@sprint.com>, "disp= atch@ietf.org" <dispatch@ietf.org<= /a>>, "modern@ietf.org" <modern@ietf.org>, "Peterson, Jon" <jon.peterson@neustar.biz>
Subject: Re: [Modern] [dispatch] draft c= harter

I support Richard on = this 

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory S= tandards
AT&T Standards and 
Industry Alliances=
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  
=
My concern here is charter overreach. I really want to keep C= NAM+/CNIT out of this.  IMHO that is a very separate and highly focused= effort to define both the modification of the SIP headers necessary to supp= ort some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I’m violently opposed to “= end world hunger” WG’s. 

If regist= ries can be used fine but I certainly want to see how this can be accomplish= ed in bi lateral agreements between consenting service providers and work wi= th CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in= the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNIT in= enterprise and residential access markets is important but we all know R= 20;Money is the answer what is the  question ..”  

I’ve asked for time in Dispatch to look at the CNAM/CN= IT issue and report on the JTF on NNI. As you well know we have made conside= rable progress.

Last week I gave a talk on this to = a panel that included many of our friends among the national regulators. &nb= sp;


From: "Holmes, David W [CTO]" <David.Holmes@sprint.com>
Date: Tuesday, February 24, 2015 at 5:06 PM
To: "Peterson, Jon" <jon.peterson@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft = charter

Jon,

 

Thank you for the wor= k in assembling this draft of the charter for MODERN.

 

We would like to suggest some minor clarifica= tions to the bullets describing the deliverables, to align them with the sta= tement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the allo= cation etc. activities, & it would not attempt to define the allocation = processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the M= ODERN WG as appropriate.  These changes/additions are have been added t= o your text inline below.

 

We are hoping that the MODERN session at IETF= #92 will have remote access, to allow participation by those of us that cann= ot attend in person due to other commitments that week.  

 

Regards,

 

David/Sprint

________________________________________________________________________= ______

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2= 015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

 

At the Dallas IETF meeting in March, we'= d like to get together and talk about what a working group for MODERN might = look like. As an initial input to the discussion, a few of us have put toget= her a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own B= oF.

 

Comments are welcome, this is just a starting p= oint.

 

------

 

<= p class=3D"MsoNormal">Modern charter text:

 =

The MODERN working= group will define a set of Internet-based mechanisms for the purposes of ma= naging and resolving telephone numbers (TNs) in an IP environment.  Exi= sting mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w applications for TNs become possible.  The traditional model of a TN = having an association to a single service provider and a single application = is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or a= n organization will remain for some time. Devices, applications, and network= tools increasingly need to manage TNs, including requesting and acquiring T= N delegations from authorities.

 

The working group will define a framework for the roles and f= unctions involved in managing and resolving TNs in an IP environment. This i= ncludes a protocol mechanism for acquiring TNs, which will provide an enroll= ment process for the individuals and entities that use and manage TNs. TNs may = either be managed in a hierarchical tree, or in a distributed peer-to-peer a= rchitecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 =

Additio= nally, the working group will deliver a protocol mechanism for resolving TNs= which will allow entities such as service providers, devices, and applicati= ons to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The = working group will take into consideration existing IETF work including ENUM= , SPEERMINT, STIR, and DRINKS.

 =

The wor= k of this group is limited to specifying a solution for TNs and covers any s= ervice that can be addressed using a TN.  Expanding the work to other i= dentifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The wor= k group will deliver the following:

 

-      =     An architecture overview document that inc= ludes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Foru= m JTF, that included:

o   Call routing architecture =

o   Inter-carrier NNI

o   Cryptographically-enabled Anti-spoofi= ng (STIR)

oEnhanced Calling Name (CNIT/CNAM)

-=           A document describing the protocols to support enrollment processes for existing and = new TNs including any modifications to metadata related to those TNs

-&= nbsp;         A document describing protocol mechanisms = for accessing contact information associated with enrollments

- &nbs= p;        A document describing protocol mechanisms for resolving information r= elated to TNs

 

-       = ;    


<= br> This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org = https://www.ietf.org/mailman/listinfo/modern
___________________________________________= ____
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/d= ispatch
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3507710713_441257-- From nobody Wed Feb 25 09:32:06 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 A26691A1A13; Wed, 25 Feb 2015 09:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jMxEu1YnHgPR; Wed, 25 Feb 2015 09:32:02 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 23A611A1A0F; Wed, 25 Feb 2015 09:32:01 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 3C0276726DC7E; Wed, 25 Feb 2015 17:31:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t1PHVwtQ012327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 18:31:58 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 18:31:58 +0100 From: "DRAGE, Keith (Keith)" To: Richard Shockey , "DOLLY, MARTIN C" Thread-Topic: [dispatch] [Modern] draft charter Thread-Index: AQHQUR12wXN/MqmpnkuTg3mwcQ/taZ0BmYJA Date: Wed, 25 Feb 2015 17:31:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A10928E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 17:32:05 -0000 ITU-T Recommendation I.251.9 specifies: calling name: Information associated with a specific calling party number. = The maximum length is at least 15 characters and may be up to 50 characters= . The exact length, format and character set (e.g. T.51, T.52) of the calli= ng name to be delivered is a service provider option Therefore 15 would appear to be a deployment specific limitation. I believe QSIG defines 50 characters. The definition above also raises the question of character set. QSIG defines a number of different character sets. Regards Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Richard Shockey > Sent: 25 February 2015 17:05 > To: DOLLY, MARTIN C > Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=20 > modern@ietf.org > Subject: Re: [dispatch] [Modern] draft charter >=20 >=20 > Thanks Martin .. This is my very raw first cut at a charter.=20 > Its hopefully simple and straight forward. >=20 > Send me any edits etc. >=20 > ***** >=20 > CNIT Charter [Calling Name Identity Trust] >=20 >=20 > WG Chairs TBD: >=20 >=20 > Calling Name Delivery [CNAM] is a string of up to 15 ASCII=20 > Characters of information associated with a specific E.164=20 > calling party number in the Public Switched Telephone Network=20 > [PSTN]. In the PSTN this data is sent by the originating=20 > network only at the specific request of the terminating=20 > network via a SS7 Transaction Application Part [TCAP]=20 > response message. In the Session Initiation Protocol [SIP]=20 > this information can be inserted into the FROM: part of the=20 > originating INVITE message or by other means. >=20 >=20 > As with the originating source telephone number, this data=20 > can be altered in transit creating a variety of malicious=20 > abuses similar to the ones identified by the IETF STIR working group. >=20 >=20 > The purpose of the CNIT working group will be to define a=20 > data structure, a new SIP header or repurpose an existing SIP=20 > header to carry an advanced form of CNAM as well as=20 > information from a STIR Validation Authority. The purpose of=20 > this work is to present to the SIP called party trusted=20 > information from the calling party in order that the called=20 > party make a more reasoned and informed judgment on whether=20 > to accept the INVITE or not. >=20 >=20 > The working group will not invalidate any existing SIP=20 > mechanism for anonymous calling. =20 >=20 >=20 > The working group will, to the best of its ability, reuse=20 > existing IETF protocols. >=20 >=20 > Full Internationalization of the Calling Name Identity Trust=20 > data object(s) is a requirement. >=20 >=20 > The working group will closely work with the IETF STIR working group >=20 >=20 > The working group will immediately liaison with 3GPP SA-1 in=20 > order to coordinate efforts. >=20 >=20 > The working group will coordinate with National Numbering=20 > Authorities and National Regulatory Authorities as needed. >=20 >=20 > The working group will deliver the flowing. >=20 >=20 > * A problem statement and requirements detailing the current=20 > deployment environment and situations that motivate work on=20 > Calling Name Identity Trust. > * Define either a new SIP header or document a repurpose of=20 > an SIP existing header for Calling Name Identify Trust data *=20 > Define a data model for the Calling Name Identity Trust=20 > object (s) which may include various forms of multimedia data=20 > * Deliver an analysis of privacy implications of the proposed=20 > Calling Name Identity Trust mechanism. >=20 >=20 >=20 >=20 > Milestones: >=20 >=20 > - > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "DOLLY, MARTIN C" > Date: Tuesday, February 24, 2015 at 9:02 PM > To: Richard Shockey > Cc: "Holmes, David W [CTO]" ,=20 > "dispatch@ietf.org" , "modern@ietf.org"=20 > , "Peterson, Jon" > Subject: Re: [Modern] [dispatch] draft charter >=20 >=20 > I support Richard on this=20 >=20 > Martin Dolly=20 > Lead Member of Technical Staff > Core & Gov't/Regulatory Standards > AT&T Standards and=20 > Industry Alliances > +1-609-903-3390 >=20 > Sent from my iPhone >=20 > On Feb 24, 2015, at 6:36 PM, Richard Shockey=20 > wrote: >=20 >=20 >=20 >=20 > Excellent points David. =20 >=20 > My concern here is charter overreach. I really want to=20 > keep CNAM+/CNIT out of this. IMHO that is a very separate=20 > and highly focused effort to define both the modification of=20 > the SIP headers necessary to support some enhanced calling=20 > party identification and a very limited effort to define the=20 > object and or the STIR validation data. =20 >=20 > I'm violently opposed to "end world hunger" WG's.=20 >=20 > If registries can be used fine but I certainly want to=20 > see how this can be accomplished in bi lateral agreements=20 > between consenting service providers and work with CUA=20 > vendors on how the data is displayed aka Apple, Samsung,=20 > Microsoft in the context of a formal liaison with 3GPP. =20 > Certainly the relevance of CNAM+/CNIT in enterprise and=20 > residential access markets is important but we all know=20 > "Money is the answer what is the question .." =20 >=20 > I've asked for time in Dispatch to look at the=20 > CNAM/CNIT issue and report on the JTF on NNI. As you well=20 > know we have made considerable progress. >=20 > Last week I gave a talk on this to a panel that=20 > included many of our friends among the national regulators. =20 >=20 > http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >=20 >=20 >=20 > =09 > From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM > To: "Peterson, Jon" ,=20 > "modern@ietf.org" > Subject: Re: [Modern] draft charter > =09 >=20 >=20 > Jon,=20 >=20 > =20 >=20 > Thank you for the work in assembling this draft of the=20 > charter for MODERN.=20 >=20 > =20 >=20 > We would like to suggest some minor clarifications to=20 > the bullets describing the deliverables, to align them with=20 > the statement regarding flexibility to support the needs of=20 > different regulatory regimes, & thus to ensure that if quoted=20 > alone they are not taken out of context; i.e. the group=20 > product will be the protocols to support the allocation etc.=20 > activities, & it would not attempt to define the allocation=20 > processes. We also would like the charter to note the=20 > relevant work that has already been performed by both IETF &=20 > the ATIS/SIP Forum JTF, & incorporate that into the output=20 > from the MODERN WG as appropriate. These changes/additions=20 > are have been added to your text inline below.=20 >=20 > =20 >=20 > We are hoping that the MODERN session at IETF#92 will=20 > have remote access, to allow participation by those of us=20 > that cannot attend in person due to other commitments that week. =20 >=20 > =20 >=20 > Regards,=20 >=20 > =20 >=20 > David/Sprint=20 >=20 > =09 > ______________________________________________________________ > ________________ >=20 > =20 >=20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf=20 > Of Peterson, Jon > Sent: Wednesday, February 11, 2015 9:19 AM > To: modern@ietf.org > Subject: [Modern] draft charter >=20 > =20 >=20 > =20 >=20 > At the Dallas IETF meeting in March, we'd like to get=20 > together and talk about what a working group for MODERN might=20 > look like. As an initial input to the discussion, a few of us=20 > have put together a proposed charter. While the TeRQ work was=20 > positively evaluated in the DISPATCH process, we feel this is=20 > broader enough in scope to warrant its own BoF. >=20 > =20 >=20 > Comments are welcome, this is just a starting point. >=20 > =20 >=20 > ------ >=20 > =20 >=20 > Modern charter text: >=20 > =20 >=20 > The MODERN working group will define a set of=20 > Internet-based mechanisms for the purposes of managing and=20 > resolving telephone numbers (TNs) in an IP environment. =20 > Existing mechanisms for these purposes face obsolescence as=20 > the voice communications infrastructure evolves to IP=20 > technology and new applications for TNs become possible. The=20 > traditional model of a TN having an association to a single=20 > service provider and a single application is breaking down. =20 > Its use as a network locator is going away, but its use as an=20 > identifier for an individual or an organization will remain=20 > for some time. Devices, applications, and network tools=20 > increasingly need to manage TNs, including requesting and=20 > acquiring TN delegations from authorities. >=20 > =20 >=20 > The working group will define a framework for the roles=20 > and functions involved in managing and resolving TNs in an IP=20 > environment. This includes a protocol mechanism for acquiring=20 > TNs, which will provide an enrollment process for the=20 > individuals and entities that use and manage TNs. TNs may=20 > either be managed in a hierarchical tree, or in a distributed=20 > peer-to-peer architecture. Privacy of the enrollment data=20 > and security of the resource will be primary considerations.=20 >=20 > =20 >=20 > Additionally, the working group will deliver a protocol=20 > mechanism for resolving TNs which will allow entities such as=20 > service providers, devices, and applications to access data=20 > related to TNs, possibly including caller name data (CNAM). =20 > Maintaining reliability, real time application performance,=20 > security and privacy are primary considerations. The working=20 > group will take into consideration existing IETF work=20 > including ENUM, SPEERMINT, STIR, and DRINKS.=20 >=20 > =20 >=20 > The work of this group is limited to specifying a=20 > solution for TNs and covers any service that can be addressed=20 > using a TN. Expanding the work to other identifiers is out=20 > of scope. Solutions and mechanisms created by the working=20 > group will be flexible enough to accommodate different=20 > policies, e.g., by different regulatory agencies.=20 >=20 > =20 >=20 > The work group will deliver the following: >=20 > =20 >=20 > - An architecture overview document that=20 > includes high level requirements and security/privacy=20 > considerationsbuilt on the work of IETF & the ATIS/SIP Forum=20 > JTF, that included:=20 >=20 > o Call routing architecture=20 >=20 > o Inter-carrier NNI >=20 > o Cryptographically-enabled Anti-spoofing (STIR) >=20 > o Enhanced Calling Name (CNIT/CNAM) >=20 > - A document describing the protocols to=20 > support enrollment processes for existing and new TNs=20 > including any modifications to metadata related to those TNs >=20 > - A document describing protocol mechanisms=20 > for accessing contact information associated with enrollments >=20 > - A document describing protocol mechanisms=20 > for resolving information related to TNs >=20 > =20 >=20 > - =20 >=20 >=20 > ________________________________ >=20 > =09 > This e-mail may contain Sprint proprietary information=20 > intended for the sole use of the recipient(s). Any use by=20 > others is prohibited. If you are not the intended recipient,=20 > please contact the sender and delete all copies of the message. > =09 > _______________________________________________ Modern=20 > mailing list Modern@ietf.org =20 > https://www.ietf.org/mailman/listinfo/modern >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =09 >=20 > _______________________________________________ Modern=20 > mailing list Modern@ietf.org=20 > https://www.ietf.org/mailman/listinfo/modern=20 > = From nobody Wed Feb 25 10:14:43 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 D672C1A00D0; Wed, 25 Feb 2015 10:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 FAvV16KRN3h2; Wed, 25 Feb 2015 10:14:37 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 1FC251A0016; Wed, 25 Feb 2015 10:14:37 -0800 (PST) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t1PIDrvW003550; Wed, 25 Feb 2015 13:14:27 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1sskb580kg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2015 13:14:26 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.67]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 13:14:25 -0500 From: "Peterson, Jon" To: "DOLLY, MARTIN C" , Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUJ876Ub0AVjuokK2O8uJqxpi6J0BejeA Date: Wed, 25 Feb 2015 18:14:25 +0000 Message-ID: References: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> In-Reply-To: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.189] Content-Type: multipart/alternative; boundary="_000_D1134C4014B0A7jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7723 signatures=670627 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=7.7937656328686e-14 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502250189 Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 18:14:41 -0000 --_000_D1134C4014B0A7jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think the potential for a CNAM-like function enters into MODERN from the = WHOIS/WEIRDS sorts of requirements we imagine are associated with moving th= e number registration process to the Internet. As you enroll in the system = to get numbers, obviously some information about assignees is going to chan= ge hands, and somewhere there will have to be control and accountability fo= r who owns what numbers, and a secure (privacy-protecting) way to query for= that data. But more broadly, since MODERN follows on TeRQ, any TeRQ-like p= rotocol is going to be able to ask about arbitrary data associated with num= bers including names - but crucially, TeRQ queries can and will be launched= at a time no call from that number is in progress. So I'm not sure MODERN would conflict or even overlap, necessarily, with ef= forts to define a header or other place to carry that naming information in= SIP as in the proposed CNIT charter. MODERN isn't going to define a SIP he= ader to carry CNAM data, and CNIT isn't going to define a way to query for = CNAM-like data outside of a SIP session in progress, from my reading of the= draft charter. If that sounds reasonable, we could build language into bot= h proposed charters that makes the distinction clear. Jon Peterson Neustar, Inc. From: , MARTIN C > Date: Tuesday, February 24, 2015 at 6:02 PM To: Richard Shockey > Cc: "Holmes, David W [CTO]" >, "dispatch@ietf.org" >, "modern@ietf.org" >, Jon Peterson > Subject: Re: [Modern] [dispatch] draft charter I support Richard on this Martin Dolly Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey > wrote: Excellent points David. My concern here is charter overreach. I really want to keep CNAM+/CNIT out = of this. IMHO that is a very separate and highly focused effort to define = both the modification of the SIP headers necessary to support some enhanced= calling party identification and a very limited effort to define the objec= t and or the STIR validation data. I=92m violently opposed to =93end world hunger=94 WG=92s. If registries can be used fine but I certainly want to see how this can be = accomplished in bi lateral agreements between consenting service providers = and work with CUA vendors on how the data is displayed aka Apple, Samsung, = Microsoft in the context of a formal liaison with 3GPP. Certainly the rele= vance of CNAM+/CNIT in enterprise and residential access markets is importa= nt but we all know =93Money is the answer what is the question ..=94 I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on the JTF on NNI. As you well know we have made considerable progress. Last week I gave a talk on this to a panel that included many of our friend= s among the national regulators. http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM To: "Peterson, Jon" >, "modern@ietf.org" > Subject: Re: [Modern] draft charter Jon, Thank you for the work in assembling this draft of the charter for MODERN. We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility = to support the needs of different regulatory regimes, & thus to ensure that= if quoted alone they are not taken out of context; i.e. the group product = will be the protocols to support the allocation etc. activities, & it would= not attempt to define the allocation processes. We also would like the ch= arter to note the relevant work that has already been performed by both IET= F & the ATIS/SIP Forum JTF, & incorporate that into the output from the MOD= ERN WG as appropriate. These changes/additions are have been added to your= text inline below. We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to ot= her commitments that week. Regards, David/Sprint ___________________________________________________________________________= ___ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern charter text: The MODERN working group will define a set of Internet-based mechanisms for= the purposes of managing and resolving telephone numbers (TNs) in an IP en= vironment. Existing mechanisms for these purposes face obsolescence as the= voice communications infrastructure evolves to IP technology and new appli= cations for TNs become possible. The traditional model of a TN having an a= ssociation to a single service provider and a single application is breakin= g down. Its use as a network locator is going away, but its use as an iden= tifier for an individual or an organization will remain for some time. Devi= ces, applications, and network tools increasingly need to manage TNs, inclu= ding requesting and acquiring TN delegations from authorities. The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. TNs may either b= e managed in a hierarchical tree, or in a distributed peer-to-peer architec= ture. Privacy of the enrollment data and security of the resource will be = primary considerations. Additionally, the working group will deliver a protocol mechanism for resol= ving TNs which will allow entities such as service providers, devices, and = applications to access data related to TNs, possibly including caller name = data (CNAM). Maintaining reliability, real time application performance, s= ecurity and privacy are primary considerations. The working group will tak= e into consideration existing IETF work including ENUM, SPEERMINT, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. Solutions and mechanisms created by the wo= rking group will be flexible enough to accommodate different policies, e.g.= , by different regulatory agencies. The work group will deliver the following: - An architecture overview document that includes high level requi= rements and security/privacy considerationsbuilt on the work of IETF & the = ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment proces= ses for existing and new TNs including any modifications to metadata relate= d to those TNs - A document describing protocol mechanisms for accessing contact = information associated with enrollments - A document describing protocol mechanisms for resolving informat= ion related to TNs - ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/mode= rn _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_D1134C4014B0A7jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I think the potential for a CNAM-like function enters into MODERN from= the WHOIS/WEIRDS sorts of requirements we imagine are associated with movi= ng the number registration process to the Internet. As you enroll in the sy= stem to get numbers, obviously some information about assignees is going to change hands, and somewhere there = will have to be control and accountability for who owns what numbers, and a= secure (privacy-protecting) way to query for that data. But more broadly, = since MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associa= ted with numbers including names - but crucially, TeRQ queries can and will= be launched at a time no call from that number is in progress.

So I'm not sure MODERN would conflict or even overlap, necessarily, wi= th efforts to define a header or other place to carry that naming informati= on in SIP as in the proposed CNIT charter. MODERN isn't going to define a S= IP header to carry CNAM data, and CNIT isn't going to define a way to query for CNAM-like data outside of a = SIP session in progress, from my reading of the draft charter. If that soun= ds reasonable, we could build language into both proposed charters that mak= es the distinction clear.

Jon Peterson
Neustar, Inc.

From: <DOLLY>, MARTIN C <<= a href=3D"mailto:md3135@att.com">md3135@att.com>
Date: Tuesday, February 24, 2015 at= 6:02 PM
To: Richard Shockey <richard@shockey.us>
Cc: "Holmes, David W [CTO]&quo= t; <David.Holmes@sprint.com>, "dispatch@ietf.org&qu= ot; <dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>, Jon Peterson <<= a href=3D"mailto:jon.peterson@neustar.biz">jon.peterson@neustar.biz>=
Subject: Re: [Modern] [dispatch] dr= aft charter

I support Richard on this 

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and 
Industry Alliances
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  

My concern here is charter overreach. I really want to keep CNAM+/= CNIT out of this.  IMHO that is a very separate and highly focused eff= ort to define both the modification of the SIP headers necessary to support= some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I=92m violently opposed to =93end world hunger=94 WG=92s. 

If registries can be used fine but I certainly want to see how this ca= n be accomplished in bi lateral agreements between consenting service provi= ders and work with CUA vendors on how the data is displayed aka Apple, Sams= ung, Microsoft in the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNI= T in enterprise and residential access markets is important but we all know= =93Money is the answer what is the  question ..=94  

I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and r= eport on the JTF on NNI. As you well know we have made considerable progres= s.

Last week I gave a talk on this to a panel that included many of our f= riends among the national regulators.  




=97 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From: "Holmes, David W [CTO]&q= uot; <David.Holmes@sprint.com= >
Date: Tuesday, February 24, 2015 at= 5:06 PM
To: "Peterson, Jon" <<= a href=3D"mailto:jon.peterson@neustar.biz">jon.peterson@neustar.biz>= , "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft charter=

Jon, =

=  

Thank= you for the work in assembling this draft of the charter for MODERN.

=  

We wo= uld like to suggest some minor clarifications to the bullets describing the= deliverables, to align them with the statement regarding flexibility to su= pport the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the all= ocation etc. activities, & it would not attempt to define the allocatio= n processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the = MODERN WG as appropriate.  These changes/additions are have been added= to your text inline below.

=  

We ar= e hoping that the MODERN session at IETF#92 will have remote access, to all= ow participation by those of us that cannot attend in person due to other c= ommitments that week.  

=  

Regar= ds,

=  

David= /Sprint

_____= _________________________________________________________________________

=  

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

&n= bsp;

At the = Dallas IETF meeting in March, we'd like to get together and talk about what= a working group for MODERN might look like. As an initial input to the dis= cussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own = BoF.

&n= bsp;

Comment= s are welcome, this is just a starting point.

&n= bsp;

------<= o:p>

&n= bsp;

Modern charter text:

 =

The MODERN working group= will define a set of Internet-based mechanisms for the purposes of managin= g and resolving telephone numbers (TNs) in an IP environment.  Existin= g mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w applications for TNs become possible.  The traditional model of a TN= having an association to a single service provider and a single applicatio= n is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or a= n organization will remain for some time. Devices, applications, and networ= k tools increasingly need to manage TNs, including requesting and acquiring= TN delegations from authorities.

 =

The working group will d= efine a framework for the roles and functions involved in managing and reso= lving TNs in an IP environment. This includes a protocol mechanism for acqu= iring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may = either be managed in a hierarchical tree, or in a distributed peer-to-peer = architecture.  Privacy of the enrollment data and security of the reso= urce will be primary considerations.

 =

Additionally, the workin= g group will deliver a protocol mechanism for resolving TNs which will allo= w entities such as service providers, devices, and applications to access d= ata related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The= working group will take into consideration existing IETF work including EN= UM, SPEERMINT, STIR, and DRINKS.

 =

The work of this group i= s limited to specifying a solution for TNs and covers any service that can = be addressed using a TN.  Expanding the work to other identifiers is o= ut of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The work group will deli= ver the following:

 =

- = ;         An architecture overview document that i= ncludes high level requirements and security/privacy considerations<= span style=3D"color:#1F497D">built on the work of IETF & the ATIS/SI= P Forum JTF, that included:

o   Call routing architecture

o   Inter-carrier NNI=

o   Cryptographically-enabled Anti-spoo= fing (STIR)

o   Enhanced Calling Name (CNIT/CNAM)

-&nbs= p;         A document describing the protocols to support enrollment processes for existing an= d new TNs including any modifications to metadata related to those TNs=

-&nbs= p;         A document describing protocol mechanism= s for accessing contact information associated with enrollments<= /span>

- =          A document describing protocol mechanisms for resolving information= related to TNs

=  

- &n= bsp;         <= /o:p>



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
 --_000_D1134C4014B0A7jonpetersonneustarbiz_-- From nobody Wed Feb 25 10:55:34 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 E6FF31A1B87 for ; Wed, 25 Feb 2015 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ZhBgMJouMnjY for ; Wed, 25 Feb 2015 10:55:22 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id DCBD01A038A for ; Wed, 25 Feb 2015 10:55:19 -0800 (PST) Received: (qmail 6200 invoked by uid 0); 25 Feb 2015 18:55:16 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 25 Feb 2015 18:55:16 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id wiuL1p00t1MNPNq01iuPo4; Wed, 25 Feb 2015 11:54:23 -0700 X-Authority-Analysis: v=2.1 cv=bJKFfpOZ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=gxZvrgisAAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=sjzYArKkxSwgTGd0bBcA:9 a=Yb7oC6_DpRCdxxZ3:21 a=tp1Sofds9zBsTQDX:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=Nu0VJE94YPTvWADy+NS92iUXwwW1pQ9uxtL6ZOtbA4c=; b=nFm+nVoyQ0Vpm9aZezLmwDVz91hxPO2XCFBD92vBX6PPJPfEknpMCrCCLbnNu5eVOEdUTitNPEOD1+58hOfhoBX9UFFA4pNlgGPaZo+BUjfuj2/pgBPeiYJH2EFhtx9o; Received: from [108.56.131.201] (port=57241 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQh6D-0003TY-0s; Wed, 25 Feb 2015 11:54:21 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 13:54:14 -0500 From: Richard Shockey To: "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [dispatch] draft charter Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 18:55:26 -0000 Humm.. Thanks. I=B9m not sure anyone has actually deployed a 50 character service. Does anyone know? =20 On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" wrote: >ITU-T Recommendation I.251.9 specifies: > >calling name: Information associated with a specific calling party >number. The maximum length is at least 15 characters and may be up to 50 >characters. The exact length, format and character set (e.g. T.51, T.52) >of the calling name to be delivered is a service provider option > >Therefore 15 would appear to be a deployment specific limitation. > >I believe QSIG defines 50 characters. > >The definition above also raises the question of character set. > >QSIG defines a number of different character sets. > > > >Regards > >Keith=20 > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Richard Shockey >> Sent: 25 February 2015 17:05 >> To: DOLLY, MARTIN C >> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org; >> modern@ietf.org >> Subject: Re: [dispatch] [Modern] draft charter >>=20 >>=20 >> Thanks Martin .. This is my very raw first cut at a charter. >> Its hopefully simple and straight forward. >>=20 >> Send me any edits etc. >>=20 >> ***** >>=20 >> CNIT Charter [Calling Name Identity Trust] >>=20 >>=20 >> WG Chairs TBD: >>=20 >>=20 >> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >> Characters of information associated with a specific E.164 >> calling party number in the Public Switched Telephone Network >> [PSTN]. In the PSTN this data is sent by the originating >> network only at the specific request of the terminating >> network via a SS7 Transaction Application Part [TCAP] >> response message. In the Session Initiation Protocol [SIP] >> this information can be inserted into the FROM: part of the >> originating INVITE message or by other means. >>=20 >>=20 >> As with the originating source telephone number, this data >> can be altered in transit creating a variety of malicious >> abuses similar to the ones identified by the IETF STIR working group. >>=20 >>=20 >> The purpose of the CNIT working group will be to define a >> data structure, a new SIP header or repurpose an existing SIP >> header to carry an advanced form of CNAM as well as >> information from a STIR Validation Authority. The purpose of >> this work is to present to the SIP called party trusted >> information from the calling party in order that the called >> party make a more reasoned and informed judgment on whether >> to accept the INVITE or not. >>=20 >>=20 >> The working group will not invalidate any existing SIP >> mechanism for anonymous calling. >>=20 >>=20 >> The working group will, to the best of its ability, reuse >> existing IETF protocols. >>=20 >>=20 >> Full Internationalization of the Calling Name Identity Trust >> data object(s) is a requirement. >>=20 >>=20 >> The working group will closely work with the IETF STIR working group >>=20 >>=20 >> The working group will immediately liaison with 3GPP SA-1 in >> order to coordinate efforts. >>=20 >>=20 >> The working group will coordinate with National Numbering >> Authorities and National Regulatory Authorities as needed. >>=20 >>=20 >> The working group will deliver the flowing. >>=20 >>=20 >> * A problem statement and requirements detailing the current >> deployment environment and situations that motivate work on >> Calling Name Identity Trust. >> * Define either a new SIP header or document a repurpose of >> an SIP existing header for Calling Name Identify Trust data * >> Define a data model for the Calling Name Identity Trust >> object (s) which may include various forms of multimedia data >> * Deliver an analysis of privacy implications of the proposed >> Calling Name Identity Trust mechanism. >>=20 >>=20 >>=20 >>=20 >> Milestones: >>=20 >>=20 >> - >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >> From: "DOLLY, MARTIN C" >> Date: Tuesday, February 24, 2015 at 9:02 PM >> To: Richard Shockey >> Cc: "Holmes, David W [CTO]" , >> "dispatch@ietf.org" , "modern@ietf.org" >> , "Peterson, Jon" >> Subject: Re: [Modern] [dispatch] draft charter >>=20 >>=20 >> I support Richard on this >>=20 >> Martin Dolly=20 >> Lead Member of Technical Staff >> Core & Gov't/Regulatory Standards >> AT&T Standards and >> Industry Alliances >> +1-609-903-3390 >>=20 >> Sent from my iPhone >>=20 >> On Feb 24, 2015, at 6:36 PM, Richard Shockey >> wrote: >>=20 >>=20 >>=20 >>=20 >> Excellent points David. >>=20 >> My concern here is charter overreach. I really want to >> keep CNAM+/CNIT out of this. IMHO that is a very separate >> and highly focused effort to define both the modification of >> the SIP headers necessary to support some enhanced calling >> party identification and a very limited effort to define the >> object and or the STIR validation data. >>=20 >> I'm violently opposed to "end world hunger" WG's. >>=20 >> If registries can be used fine but I certainly want to >> see how this can be accomplished in bi lateral agreements >> between consenting service providers and work with CUA >> vendors on how the data is displayed aka Apple, Samsung, >> Microsoft in the context of a formal liaison with 3GPP. >> Certainly the relevance of CNAM+/CNIT in enterprise and >> residential access markets is important but we all know >> "Money is the answer what is the question .." >>=20 >> I've asked for time in Dispatch to look at the >> CNAM/CNIT issue and report on the JTF on NNI. As you well >> know we have made considerable progress. >>=20 >> Last week I gave a talk on this to a panel that >> included many of our friends among the national regulators. >>=20 >> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>=20 >>=20 >>=20 >> >> From: "Holmes, David W [CTO]" >> Date: Tuesday, February 24, 2015 at 5:06 PM >> To: "Peterson, Jon" , >> "modern@ietf.org" >> Subject: Re: [Modern] draft charter >> >>=20 >>=20 >> Jon,=20 >>=20 >> =20 >>=20 >> Thank you for the work in assembling this draft of the >> charter for MODERN. >>=20 >> =20 >>=20 >> We would like to suggest some minor clarifications to >> the bullets describing the deliverables, to align them with >> the statement regarding flexibility to support the needs of >> different regulatory regimes, & thus to ensure that if quoted >> alone they are not taken out of context; i.e. the group >> product will be the protocols to support the allocation etc. >> activities, & it would not attempt to define the allocation >> processes. We also would like the charter to note the >> relevant work that has already been performed by both IETF & >> the ATIS/SIP Forum JTF, & incorporate that into the output >> from the MODERN WG as appropriate. These changes/additions >> are have been added to your text inline below. >>=20 >> =20 >>=20 >> We are hoping that the MODERN session at IETF#92 will >> have remote access, to allow participation by those of us >> that cannot attend in person due to other commitments that week. >>=20 >> =20 >>=20 >> Regards,=20 >>=20 >> =20 >>=20 >> David/Sprint=20 >>=20 >> >> ______________________________________________________________ >> ________________ >>=20 >> =20 >>=20 >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >> Of Peterson, Jon >> Sent: Wednesday, February 11, 2015 9:19 AM >> To: modern@ietf.org >> Subject: [Modern] draft charter >>=20 >> =20 >>=20 >> =20 >>=20 >> At the Dallas IETF meeting in March, we'd like to get >> together and talk about what a working group for MODERN might >> look like. As an initial input to the discussion, a few of us >> have put together a proposed charter. While the TeRQ work was >> positively evaluated in the DISPATCH process, we feel this is >> broader enough in scope to warrant its own BoF. >>=20 >> =20 >>=20 >> Comments are welcome, this is just a starting point. >>=20 >> =20 >>=20 >> ------ >>=20 >> =20 >>=20 >> Modern charter text: >>=20 >> =20 >>=20 >> The MODERN working group will define a set of >> Internet-based mechanisms for the purposes of managing and >> resolving telephone numbers (TNs) in an IP environment. >> Existing mechanisms for these purposes face obsolescence as >> the voice communications infrastructure evolves to IP >> technology and new applications for TNs become possible. The >> traditional model of a TN having an association to a single >> service provider and a single application is breaking down. >> Its use as a network locator is going away, but its use as an >> identifier for an individual or an organization will remain >> for some time. Devices, applications, and network tools >> increasingly need to manage TNs, including requesting and >> acquiring TN delegations from authorities. >>=20 >> =20 >>=20 >> The working group will define a framework for the roles >> and functions involved in managing and resolving TNs in an IP >> environment. This includes a protocol mechanism for acquiring >> TNs, which will provide an enrollment process for the >> individuals and entities that use and manage TNs. TNs may >> either be managed in a hierarchical tree, or in a distributed >> peer-to-peer architecture. Privacy of the enrollment data >> and security of the resource will be primary considerations. >>=20 >> =20 >>=20 >> Additionally, the working group will deliver a protocol >> mechanism for resolving TNs which will allow entities such as >> service providers, devices, and applications to access data >> related to TNs, possibly including caller name data (CNAM). >> Maintaining reliability, real time application performance, >> security and privacy are primary considerations. The working >> group will take into consideration existing IETF work >> including ENUM, SPEERMINT, STIR, and DRINKS. >>=20 >> =20 >>=20 >> The work of this group is limited to specifying a >> solution for TNs and covers any service that can be addressed >> using a TN. Expanding the work to other identifiers is out >> of scope. Solutions and mechanisms created by the working >> group will be flexible enough to accommodate different >> policies, e.g., by different regulatory agencies. >>=20 >> =20 >>=20 >> The work group will deliver the following: >>=20 >> =20 >>=20 >> - An architecture overview document that >> includes high level requirements and security/privacy >> considerationsbuilt on the work of IETF & the ATIS/SIP Forum >> JTF, that included: >>=20 >> o Call routing architecture >>=20 >> o Inter-carrier NNI >>=20 >> o Cryptographically-enabled Anti-spoofing (STIR) >>=20 >> o Enhanced Calling Name (CNIT/CNAM) >>=20 >> - A document describing the protocols to >> support enrollment processes for existing and new TNs >> including any modifications to metadata related to those TNs >>=20 >> - A document describing protocol mechanisms >> for accessing contact information associated with enrollments >>=20 >> - A document describing protocol mechanisms >> for resolving information related to TNs >>=20 >> =20 >>=20 >> - =20 >>=20 >>=20 >> ________________________________ >>=20 >> >> This e-mail may contain Sprint proprietary information >> intended for the sole use of the recipient(s). Any use by >> others is prohibited. If you are not the intended recipient, >> please contact the sender and delete all copies of the message. >> >> _______________________________________________ Modern >> mailing list Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >>=20 >> _______________________________________________ Modern >> mailing list Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Feb 25 11:16: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 220E51A870F for ; Wed, 25 Feb 2015 11:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] 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 ACW449dNOkvI for ; Wed, 25 Feb 2015 11:16:32 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 5850B1A6F7B for ; Wed, 25 Feb 2015 11:16:22 -0800 (PST) Received: (qmail 24578 invoked by uid 0); 25 Feb 2015 19:16:22 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 25 Feb 2015 19:16:22 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id wps71p00N1MNPNq01psARL; Wed, 25 Feb 2015 18:52:21 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=hGBaWAWWAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=doUQZJtgAAAA:8 a=0Or7jusycULVaPx2pgEA:9 a=BhnP0eqWb-lopdWh:21 a=0NtdEuhFNy3hOqwa:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=6c8eWjDizDoA:10 a=NWVoK91CQyQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=hzi90bUycbL9tOCHrCUA:9 a=q_Qj5BrfrNCEuXYA:21 a=vm2NJDszbNg87r3L:21 a=ZamLWs1pq4GIX3x8:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=Byx/u0bs8RpuJQ+Wac5EmqwaQWgq9aSJFLuT9dqsixU=; b=i2YVBoug5cnhQ67/d6PqtpwiVQKt6Qq2mO8JCTfJnCiZcL1OeaMIh4WWkv4lvKms77Z1AHkm+aieDWij0+f18FEIjqPiLD9jY674HQr0gMlAmkzb3hUM3hzjdX7Nlr0g; Received: from [108.56.131.201] (port=57240 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQh44-0001fY-Ll; Wed, 25 Feb 2015 11:52:09 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 13:52:02 -0500 From: Richard Shockey To: "Peterson, Jon" , "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [dispatch] draft charter References: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507717128_833412" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 19:16:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507717128_833412 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Excellent points. I agree. I don=B9t see a conflict here in the various Goals and Requirements between MODERN and CNIT. My concern was to make sure we could make some immediate progress by properly separating the work into digestible functions. I=B9m not concerned at this point on how CNIT / STIR validation data is acquired, much less authenticated during session establishment or by which SIP/IMS functional element, only what is the structure of that data and where in the SIP headers it resides. There is ample evidence this is getting attention in other SDO=B9s so the first order of business is making sure RAI defines what goes where properly= . =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Peterson, Jon" Date: Wednesday, February 25, 2015 at 1:14 PM To: "DOLLY, MARTIN C" , Richard Shockey Cc: "Holmes, David W [CTO]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [Modern] [dispatch] draft charter I think the potential for a CNAM-like function enters into MODERN from the WHOIS/WEIRDS sorts of requirements we imagine are associated with moving th= e number registration process to the Internet. As you enroll in the system to get numbers, obviously some information about assignees is going to change hands, and somewhere there will have to be control and accountability for who owns what numbers, and a secure (privacy-protecting) way to query for that data. But more broadly, since MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associated with numbers including names - but crucially, TeRQ queries can and will be launched at a time no call from that number is in progress. So I'm not sure MODERN would conflict or even overlap, necessarily, with efforts to define a header or other place to carry that naming information in SIP as in the proposed CNIT charter. MODERN isn't going to define a SIP header to carry CNAM data, and CNIT isn't going to define a way to query fo= r CNAM-like data outside of a SIP session in progress, from my reading of the draft charter. If that sounds reasonable, we could build language into both proposed charters that makes the distinction clear. Jon Peterson Neustar, Inc. From: , MARTIN C Date: Tuesday, February 24, 2015 at 6:02 PM To: Richard Shockey Cc: "Holmes, David W [CTO]" , "dispatch@ietf.org" , "modern@ietf.org" , Jon Peterson Subject: Re: [Modern] [dispatch] draft charter I support Richard on this Martin Dolly=20 Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and=20 Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey wrote: >=20 > Excellent points David. >=20 > My concern here is charter overreach. I really want to keep CNAM+/CNIT ou= t of > this. IMHO that is a very separate and highly focused effort to define b= oth > the modification of the SIP headers necessary to support some enhanced ca= lling > party identification and a very limited effort to define the object and o= r the > STIR validation data. >=20 > I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. >=20 > If registries can be used fine but I certainly want to see how this can b= e > accomplished in bi lateral agreements between consenting service provider= s and > work with CUA vendors on how the data is displayed aka Apple, Samsung, > Microsoft in the context of a formal liaison with 3GPP. Certainly the > relevance of CNAM+/CNIT in enterprise and residential access markets is > important but we all know =B3Money is the answer what is the question ..=B2 >=20 > I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on > the JTF on NNI. As you well know we have made considerable progress. >=20 > Last week I gave a talk on this to a panel that included many of our frie= nds > among the national regulators. >=20 > http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >=20 >=20 >=20 > =8B=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM > To: "Peterson, Jon" , "modern@ietf.org" > > Subject: Re: [Modern] draft charter >=20 > Jon,=20 > =20 > Thank you for the work in assembling this draft of the charter for MODERN= . > =20 > We would like to suggest some minor clarifications to the bullets describ= ing > the deliverables, to align them with the statement regarding flexibility = to > support the needs of different regulatory regimes, & thus to ensure that = if > quoted alone they are not taken out of context; i.e. the group product wi= ll be > the protocols to support the allocation etc. activities, & it would not > attempt to define the allocation processes. We also would like the chart= er to > note the relevant work that has already been performed by both IETF & the > ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG= as > appropriate. These changes/additions are have been added to your text in= line > below.=20 > =20 > We are hoping that the MODERN session at IETF#92 will have remote access,= to > allow participation by those of us that cannot attend in person due to ot= her > commitments that week. > =20 > Regards,=20 > =20 > David/Sprint=20 > _________________________________________________________________________= _____ > =20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, February 11, 2015 9:19 AM > To: modern@ietf.org > Subject: [Modern] draft charter > =20 > =20 > At the Dallas IETF meeting in March, we'd like to get together and talk a= bout > what a working group for MODERN might look like. As an initial input to t= he > discussion, a few of us have put together a proposed charter. While the T= eRQ > work was positively evaluated in the DISPATCH process, we feel this is br= oader > enough in scope to warrant its own BoF. > =20 > Comments are welcome, this is just a starting point. > =20 > ------ > =20 > Modern charter text: > =20 > The MODERN working group will define a set of Internet-based mechanisms f= or > the purposes of managing and resolving telephone numbers (TNs) in an IP > environment. Existing mechanisms for these purposes face obsolescence as= the > voice communications infrastructure evolves to IP technology and new > applications for TNs become possible. The traditional model of a TN havi= ng an > association to a single service provider and a single application is brea= king > down. Its use as a network locator is going away, but its use as an > identifier for an individual or an organization will remain for some time= . > Devices, applications, and network tools increasingly need to manage TNs, > including requesting and acquiring TN delegations from authorities. > =20 > The working group will define a framework for the roles and functions inv= olved > in managing and resolving TNs in an IP environment. This includes a proto= col > mechanism for acquiring TNs, which will provide an enrollment process for= the > individuals and entities that use and manage TNs. TNs may either be manag= ed in > a hierarchical tree, or in a distributed peer-to-peer architecture. Priv= acy > of the enrollment data and security of the resource will be primary > considerations.=20 > =20 > Additionally, the working group will deliver a protocol mechanism for > resolving TNs which will allow entities such as service providers, device= s, > and applications to access data related to TNs, possibly including caller= name > data (CNAM). Maintaining reliability, real time application performance, > security and privacy are primary considerations. The working group will = take > into consideration existing IETF work including ENUM, SPEERMINT, STIR, an= d > DRINKS.=20 > =20 > The work of this group is limited to specifying a solution for TNs and co= vers > any service that can be addressed using a TN. Expanding the work to othe= r > identifiers is out of scope. Solutions and mechanisms created by the wor= king > group will be flexible enough to accommodate different policies, e.g., by > different regulatory agencies. > =20 > The work group will deliver the following: > =20 > - An architecture overview document that includes high level > requirements and security/privacy considerationsbuilt on the work of IETF= & > the ATIS/SIP Forum JTF, that included: >=20 > o Call routing architecture >=20 > o Inter-carrier NNI >=20 > o Cryptographically-enabled Anti-spoofing (STIR) >=20 > o Enhanced Calling Name (CNIT/CNAM) >=20 > - A document describing the protocols to support enrollment proce= sses > for existing and new TNs including any modifications to metadata related = to > those TNs >=20 > - A document describing protocol mechanisms for accessing contact > information associated with enrollments >=20 > - A document describing protocol mechanisms for resolving informa= tion > related to TNs >=20 > =20 >=20 > - =20 >=20 >=20 >=20 > This e-mail may contain Sprint proprietary information intended for the s= ole > use of the recipient(s). Any use by others is prohibited. If you are not = the > intended recipient, please contact the sender and delete all copies of th= e > message. > _______________________________________________ Modern mailing list > Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3507717128_833412 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Excellent= points.  I agree.

I don’t see a conflic= t here in the various Goals and Requirements between MODERN and CNIT.
<= div>
My concern was to make sure we could make some immediate = progress by properly separating the work into digestible functions.  I&= #8217;m not concerned at this point on how CNIT / STIR validation data is ac= quired, much less authenticated during session establishment or by which SIP= /IMS functional element, only what is the structure of that data and where i= n the SIP headers it resides. 

There is ample = evidence this is getting attention in other SDO’s so the first order o= f business is making sure RAI defines what goes where properly.
— 
Richard Shockey
Shockey = Consulting LLC
Chairman of the Board SIP Forum
www.shock= ey.us
www.sipforum.org
richard<at>shockey.us
=
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


<= div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:black= ; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in;= PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDE= R-RIGHT: medium none; PADDING-TOP: 3pt">From:= "Peterson, Jon" <jon.p= eterson@neustar.biz>
Date: = Wednesday, February 25, 2015 at 1:14 PM
To= : "DOLLY, MARTIN C" <md3135@att.c= om>, Richard Shockey <richard@= shockey.us>
Cc: "Holmes, Da= vid W [CTO]" <David.Holmes@sprin= t.com>, "dispatch@ietf.org" &l= t;dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] [dispatch] draft charter


I think the potential for a CNAM-like func= tion enters into MODERN from the WHOIS/WEIRDS sorts of requirements we imagi= ne are associated with moving the number registration process to the Interne= t. As you enroll in the system to get numbers, obviously some information about assignees is going to change hands, and somewhere there = will have to be control and accountability for who owns what numbers, and a = secure (privacy-protecting) way to query for that data. But more broadly, si= nce MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associa= ted with numbers including names - but crucially, TeRQ queries can and will = be launched at a time no call from that number is in progress.
So I'm not sure MODERN would conflict or even overlap, necessari= ly, with efforts to define a header or other place to carry that naming info= rmation in SIP as in the proposed CNIT charter. MODERN isn't going to define= a SIP header to carry CNAM data, and CNIT isn't going to define a way to query for CNAM-like data outside of a = SIP session in progress, from my reading of the draft charter. If that sound= s reasonable, we could build language into both proposed charters that makes= the distinction clear.

Jon Peterson
Neus= tar, Inc.

From: <D= OLLY>, MARTIN C <md3135@att.com>= ;
Date: Tuesday, February 24, 2015 = at 6:02 PM
To: Richard Shockey <= richard@shockey.us>
Cc: "Holmes, David W [CTO]" <David.Holmes@sprint.com>, "dispatch@ietf.org" <dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>
Subject: Re: [Modern] [dispatch] draft charter

I support Richard on this =

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory S= tandards
AT&T Standards and 
Industry Alliances=
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  
=
My concern here is charter overreach. I really want to keep C= NAM+/CNIT out of this.  IMHO that is a very separate and highly focused= effort to define both the modification of the SIP headers necessary to supp= ort some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I’m violently opposed to “= end world hunger” WG’s. 

If regist= ries can be used fine but I certainly want to see how this can be accomplish= ed in bi lateral agreements between consenting service providers and work wi= th CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in= the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNIT in= enterprise and residential access markets is important but we all know R= 20;Money is the answer what is the  question ..”  

I’ve asked for time in Dispatch to look at the CNAM/CN= IT issue and report on the JTF on NNI. As you well know we have made conside= rable progress.

Last week I gave a talk on this to = a panel that included many of our friends among the national regulators. &nb= sp;

http://apps.fcc.gov/ecfs/document/view?id=3D60001033217



— 
Richard Shockey
Shockey Consulting LLC
Chairman o= f the Board SIP Forum
www.sipforum.org
richard<at>shockey.us
= Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From: "Holmes, David W [CTO]" <Davi= d.Holmes@sprint.com>
Date: T= uesday, February 24, 2015 at 5:06 PM
To: <= /span>"Peterson, Jon" <jon.pete= rson@neustar.biz>, "modern@ietf.org<= /a>" <modern@ietf.org>
Subject: Re: [Modern] draft charter
=

Jon,

 

Thank you for the wor= k in assembling this draft of the charter for MODERN.

 

We would like to suggest some minor clarifica= tions to the bullets describing the deliverables, to align them with the sta= tement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the allo= cation etc. activities, & it would not attempt to define the allocation = processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the M= ODERN WG as appropriate.  These changes/additions are have been added t= o your text inline below.

 

We are hoping that the MODERN session at IETF= #92 will have remote access, to allow participation by those of us that cann= ot attend in person due to other commitments that week.  

 

Regards,

 

David/Sprint

________________________________________________________________________= ______

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2= 015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

 

At the Dallas IETF meeting in March, we'= d like to get together and talk about what a working group for MODERN might = look like. As an initial input to the discussion, a few of us have put toget= her a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own B= oF.

 

Comments are welcome, this is just a starting p= oint.

 

------

 

<= p class=3D"MsoNormal">Modern charter text:

 =

The MODERN working= group will define a set of Internet-based mechanisms for the purposes of ma= naging and resolving telephone numbers (TNs) in an IP environment.  Exi= sting mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w applications for TNs become possible.  The traditional model of a TN = having an association to a single service provider and a single application = is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or a= n organization will remain for some time. Devices, applications, and network= tools increasingly need to manage TNs, including requesting and acquiring T= N delegations from authorities.

 

The working group will define a framework for the roles and f= unctions involved in managing and resolving TNs in an IP environment. This i= ncludes a protocol mechanism for acquiring TNs, which will provide an enroll= ment process for the individuals and entities that use and manage TNs. TNs may = either be managed in a hierarchical tree, or in a distributed peer-to-peer a= rchitecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 =

Additio= nally, the working group will deliver a protocol mechanism for resolving TNs= which will allow entities such as service providers, devices, and applicati= ons to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The = working group will take into consideration existing IETF work including ENUM= , SPEERMINT, STIR, and DRINKS.

 =

The wor= k of this group is limited to specifying a solution for TNs and covers any s= ervice that can be addressed using a TN.  Expanding the work to other i= dentifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The wor= k group will deliver the following:

 

-      =     An architecture overview document that inc= ludes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Foru= m JTF, that included:

o   Call routing architecture =

o   Inter-carrier NNI

o   Cryptographically-enabled Anti-spoofi= ng (STIR)

oEnhanced Calling Name (CNIT/CNAM)

-=           A document describing the protocols to support enrollment processes for existing and = new TNs including any modifications to metadata related to those TNs

-&= nbsp;         A document describing protocol mechanisms = for accessing contact information associated with enrollments

- &nbs= p;        A document describing protocol mechanisms for resolving information r= elated to TNs

 

-       = ;    


<= br> This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org = https://www.ietf.org/mailman/listinfo/modern
___________________________________________= ____
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/d= ispatch
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3507717128_833412-- From nobody Wed Feb 25 11:40:54 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 835C01A8760; Wed, 25 Feb 2015 11:40:50 -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_28=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 YsKmhoxXX_0D; Wed, 25 Feb 2015 11:40:46 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC071A1B74; Wed, 25 Feb 2015 11:40:44 -0800 (PST) Message-ID: From: Henning Schulzrinne To: Hala Mowafy , Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUSyiwl3dyMGXLUa6M1mHs23DAJ0CENYA//+xAOk= Date: Wed, 25 Feb 2015 19:40:41 +0000 References: , <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> In-Reply-To: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 19:40:50 -0000 I wonder if we're just talking about an unstructured string, or rather some= thing more structured, e.g., to be able to distinguish the name of the call= er from the organization, such as=0A= =0A= name=3DHala Mowafy / ou=3DEricsson=0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Hala Mowafy [hala.mowafy@er= icsson.com]=0A= Sent: Wednesday, February 25, 2015 2:17 PM=0A= To: Richard Shockey=0A= Cc: Holmes, David W [CTO]; dispatch@ietf.org; cnit@ietf.org; DRAGE, Keith (= Keith); modern@ietf.org; DOLLY, MARTIN C=0A= Subject: Re: [cnit] [Modern] [dispatch] draft charter=0A= =0A= Not to my knowledge in North America.=0A= Keith, I believe you are referencing an ISDN PBX standard so it may have be= en just within a business group - not inter-network?? Correct me if I'm wro= ng.=0A= =0A= In our discussions at ATIS last year for CNAM in SIP headers someone brough= t up limitations on network elements handling more than 35 characters and t= hat is what we are planning to support with an objective of 60 ch in the fu= ture.=0A= I think 35 is more than enough even for some of the longest, hyphenated nam= es.=0A= =0A= Hala Mowafy=0A= ERICSSON=0A= =0A= > On Feb 25, 2015, at 1:55 PM, Richard Shockey wrote:= =0A= >=0A= >=0A= > Humm.. Thanks.=0A= >=0A= > I=B9m not sure anyone has actually deployed a 50 character service. Does= =0A= > anyone know?=0A= >=0A= >=0A= >=0A= > On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)"=0A= > wrote:=0A= >=0A= >> ITU-T Recommendation I.251.9 specifies:=0A= >>=0A= >> calling name: Information associated with a specific calling party=0A= >> number. The maximum length is at least 15 characters and may be up to 50= =0A= >> characters. The exact length, format and character set (e.g. T.51, T.52)= =0A= >> of the calling name to be delivered is a service provider option=0A= >>=0A= >> Therefore 15 would appear to be a deployment specific limitation.=0A= >>=0A= >> I believe QSIG defines 50 characters.=0A= >>=0A= >> The definition above also raises the question of character set.=0A= >>=0A= >> QSIG defines a number of different character sets.=0A= >>=0A= >>=0A= >>=0A= >> Regards=0A= >>=0A= >> Keith=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=0A= >>> Of Richard Shockey=0A= >>> Sent: 25 February 2015 17:05=0A= >>> To: DOLLY, MARTIN C=0A= >>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=0A= >>> modern@ietf.org=0A= >>> Subject: Re: [dispatch] [Modern] draft charter=0A= >>>=0A= >>>=0A= >>> Thanks Martin .. This is my very raw first cut at a charter.=0A= >>> Its hopefully simple and straight forward.=0A= >>>=0A= >>> Send me any edits etc.=0A= >>>=0A= >>> *****=0A= >>>=0A= >>> CNIT Charter [Calling Name Identity Trust]=0A= >>>=0A= >>>=0A= >>> WG Chairs TBD:=0A= >>>=0A= >>>=0A= >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII=0A= >>> Characters of information associated with a specific E.164=0A= >>> calling party number in the Public Switched Telephone Network=0A= >>> [PSTN]. In the PSTN this data is sent by the originating=0A= >>> network only at the specific request of the terminating=0A= >>> network via a SS7 Transaction Application Part [TCAP]=0A= >>> response message. In the Session Initiation Protocol [SIP]=0A= >>> this information can be inserted into the FROM: part of the=0A= >>> originating INVITE message or by other means.=0A= >>>=0A= >>>=0A= >>> As with the originating source telephone number, this data=0A= >>> can be altered in transit creating a variety of malicious=0A= >>> abuses similar to the ones identified by the IETF STIR working group.= =0A= >>>=0A= >>>=0A= >>> The purpose of the CNIT working group will be to define a=0A= >>> data structure, a new SIP header or repurpose an existing SIP=0A= >>> header to carry an advanced form of CNAM as well as=0A= >>> information from a STIR Validation Authority. The purpose of=0A= >>> this work is to present to the SIP called party trusted=0A= >>> information from the calling party in order that the called=0A= >>> party make a more reasoned and informed judgment on whether=0A= >>> to accept the INVITE or not.=0A= >>>=0A= >>>=0A= >>> The working group will not invalidate any existing SIP=0A= >>> mechanism for anonymous calling.=0A= >>>=0A= >>>=0A= >>> The working group will, to the best of its ability, reuse=0A= >>> existing IETF protocols.=0A= >>>=0A= >>>=0A= >>> Full Internationalization of the Calling Name Identity Trust=0A= >>> data object(s) is a requirement.=0A= >>>=0A= >>>=0A= >>> The working group will closely work with the IETF STIR working group=0A= >>>=0A= >>>=0A= >>> The working group will immediately liaison with 3GPP SA-1 in=0A= >>> order to coordinate efforts.=0A= >>>=0A= >>>=0A= >>> The working group will coordinate with National Numbering=0A= >>> Authorities and National Regulatory Authorities as needed.=0A= >>>=0A= >>>=0A= >>> The working group will deliver the flowing.=0A= >>>=0A= >>>=0A= >>> * A problem statement and requirements detailing the current=0A= >>> deployment environment and situations that motivate work on=0A= >>> Calling Name Identity Trust.=0A= >>> * Define either a new SIP header or document a repurpose of=0A= >>> an SIP existing header for Calling Name Identify Trust data *=0A= >>> Define a data model for the Calling Name Identity Trust=0A= >>> object (s) which may include various forms of multimedia data=0A= >>> * Deliver an analysis of privacy implications of the proposed=0A= >>> Calling Name Identity Trust mechanism.=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> Milestones:=0A= >>>=0A= >>>=0A= >>> -=0A= >>> Richard Shockey=0A= >>> Shockey Consulting LLC=0A= >>> Chairman of the Board SIP Forum=0A= >>> www.shockey.us=0A= >>> www.sipforum.org=0A= >>> richardshockey.us=0A= >>> Skype-Linkedin-Facebook rshockey101=0A= >>> PSTN +1 703-593-2683=0A= >>>=0A= >>>=0A= >>> From: "DOLLY, MARTIN C" =0A= >>> Date: Tuesday, February 24, 2015 at 9:02 PM=0A= >>> To: Richard Shockey =0A= >>> Cc: "Holmes, David W [CTO]" ,=0A= >>> "dispatch@ietf.org" , "modern@ietf.org"=0A= >>> , "Peterson, Jon" =0A= >>> Subject: Re: [Modern] [dispatch] draft charter=0A= >>>=0A= >>>=0A= >>> I support Richard on this=0A= >>>=0A= >>> Martin Dolly=0A= >>> Lead Member of Technical Staff=0A= >>> Core & Gov't/Regulatory Standards=0A= >>> AT&T Standards and=0A= >>> Industry Alliances=0A= >>> +1-609-903-3390=0A= >>>=0A= >>> Sent from my iPhone=0A= >>>=0A= >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey=0A= >>> wrote:=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> Excellent points David.=0A= >>>=0A= >>> My concern here is charter overreach. I really want to=0A= >>> keep CNAM+/CNIT out of this. IMHO that is a very separate=0A= >>> and highly focused effort to define both the modification of=0A= >>> the SIP headers necessary to support some enhanced calling=0A= >>> party identification and a very limited effort to define the=0A= >>> object and or the STIR validation data.=0A= >>>=0A= >>> I'm violently opposed to "end world hunger" WG's.=0A= >>>=0A= >>> If registries can be used fine but I certainly want to=0A= >>> see how this can be accomplished in bi lateral agreements=0A= >>> between consenting service providers and work with CUA=0A= >>> vendors on how the data is displayed aka Apple, Samsung,=0A= >>> Microsoft in the context of a formal liaison with 3GPP.=0A= >>> Certainly the relevance of CNAM+/CNIT in enterprise and=0A= >>> residential access markets is important but we all know=0A= >>> "Money is the answer what is the question .."=0A= >>>=0A= >>> I've asked for time in Dispatch to look at the=0A= >>> CNAM/CNIT issue and report on the JTF on NNI. As you well=0A= >>> know we have made considerable progress.=0A= >>>=0A= >>> Last week I gave a talk on this to a panel that=0A= >>> included many of our friends among the national regulators.=0A= >>>=0A= >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> From: "Holmes, David W [CTO]" =0A= >>> Date: Tuesday, February 24, 2015 at 5:06 PM=0A= >>> To: "Peterson, Jon" ,=0A= >>> "modern@ietf.org" =0A= >>> Subject: Re: [Modern] draft charter=0A= >>>=0A= >>>=0A= >>>=0A= >>> Jon,=0A= >>>=0A= >>>=0A= >>>=0A= >>> Thank you for the work in assembling this draft of the=0A= >>> charter for MODERN.=0A= >>>=0A= >>>=0A= >>>=0A= >>> We would like to suggest some minor clarifications to=0A= >>> the bullets describing the deliverables, to align them with=0A= >>> the statement regarding flexibility to support the needs of=0A= >>> different regulatory regimes, & thus to ensure that if quoted=0A= >>> alone they are not taken out of context; i.e. the group=0A= >>> product will be the protocols to support the allocation etc.=0A= >>> activities, & it would not attempt to define the allocation=0A= >>> processes. We also would like the charter to note the=0A= >>> relevant work that has already been performed by both IETF &=0A= >>> the ATIS/SIP Forum JTF, & incorporate that into the output=0A= >>> from the MODERN WG as appropriate. These changes/additions=0A= >>> are have been added to your text inline below.=0A= >>>=0A= >>>=0A= >>>=0A= >>> We are hoping that the MODERN session at IETF#92 will=0A= >>> have remote access, to allow participation by those of us=0A= >>> that cannot attend in person due to other commitments that week.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Regards,=0A= >>>=0A= >>>=0A= >>>=0A= >>> David/Sprint=0A= >>>=0A= >>>=0A= >>> ______________________________________________________________=0A= >>> ________________=0A= >>>=0A= >>>=0A= >>>=0A= >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf=0A= >>> Of Peterson, Jon=0A= >>> Sent: Wednesday, February 11, 2015 9:19 AM=0A= >>> To: modern@ietf.org=0A= >>> Subject: [Modern] draft charter=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> At the Dallas IETF meeting in March, we'd like to get=0A= >>> together and talk about what a working group for MODERN might=0A= >>> look like. As an initial input to the discussion, a few of us=0A= >>> have put together a proposed charter. While the TeRQ work was=0A= >>> positively evaluated in the DISPATCH process, we feel this is=0A= >>> broader enough in scope to warrant its own BoF.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Comments are welcome, this is just a starting point.=0A= >>>=0A= >>>=0A= >>>=0A= >>> ------=0A= >>>=0A= >>>=0A= >>>=0A= >>> Modern charter text:=0A= >>>=0A= >>>=0A= >>>=0A= >>> The MODERN working group will define a set of=0A= >>> Internet-based mechanisms for the purposes of managing and=0A= >>> resolving telephone numbers (TNs) in an IP environment.=0A= >>> Existing mechanisms for these purposes face obsolescence as=0A= >>> the voice communications infrastructure evolves to IP=0A= >>> technology and new applications for TNs become possible. The=0A= >>> traditional model of a TN having an association to a single=0A= >>> service provider and a single application is breaking down.=0A= >>> Its use as a network locator is going away, but its use as an=0A= >>> identifier for an individual or an organization will remain=0A= >>> for some time. Devices, applications, and network tools=0A= >>> increasingly need to manage TNs, including requesting and=0A= >>> acquiring TN delegations from authorities.=0A= >>>=0A= >>>=0A= >>>=0A= >>> The working group will define a framework for the roles=0A= >>> and functions involved in managing and resolving TNs in an IP=0A= >>> environment. This includes a protocol mechanism for acquiring=0A= >>> TNs, which will provide an enrollment process for the=0A= >>> individuals and entities that use and manage TNs. TNs may=0A= >>> either be managed in a hierarchical tree, or in a distributed=0A= >>> peer-to-peer architecture. Privacy of the enrollment data=0A= >>> and security of the resource will be primary considerations.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Additionally, the working group will deliver a protocol=0A= >>> mechanism for resolving TNs which will allow entities such as=0A= >>> service providers, devices, and applications to access data=0A= >>> related to TNs, possibly including caller name data (CNAM).=0A= >>> Maintaining reliability, real time application performance,=0A= >>> security and privacy are primary considerations. The working=0A= >>> group will take into consideration existing IETF work=0A= >>> including ENUM, SPEERMINT, STIR, and DRINKS.=0A= >>>=0A= >>>=0A= >>>=0A= >>> The work of this group is limited to specifying a=0A= >>> solution for TNs and covers any service that can be addressed=0A= >>> using a TN. Expanding the work to other identifiers is out=0A= >>> of scope. Solutions and mechanisms created by the working=0A= >>> group will be flexible enough to accommodate different=0A= >>> policies, e.g., by different regulatory agencies.=0A= >>>=0A= >>>=0A= >>>=0A= >>> The work group will deliver the following:=0A= >>>=0A= >>>=0A= >>>=0A= >>> - An architecture overview document that=0A= >>> includes high level requirements and security/privacy=0A= >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum=0A= >>> JTF, that included:=0A= >>>=0A= >>> o Call routing architecture=0A= >>>=0A= >>> o Inter-carrier NNI=0A= >>>=0A= >>> o Cryptographically-enabled Anti-spoofing (STIR)=0A= >>>=0A= >>> o Enhanced Calling Name (CNIT/CNAM)=0A= >>>=0A= >>> - A document describing the protocols to=0A= >>> support enrollment processes for existing and new TNs=0A= >>> including any modifications to metadata related to those TNs=0A= >>>=0A= >>> - A document describing protocol mechanisms=0A= >>> for accessing contact information associated with enrollments=0A= >>>=0A= >>> - A document describing protocol mechanisms=0A= >>> for resolving information related to TNs=0A= >>>=0A= >>>=0A= >>>=0A= >>> -=0A= >>>=0A= >>>=0A= >>> ________________________________=0A= >>>=0A= >>>=0A= >>> This e-mail may contain Sprint proprietary information=0A= >>> intended for the sole use of the recipient(s). Any use by=0A= >>> others is prohibited. If you are not the intended recipient,=0A= >>> please contact the sender and delete all copies of the message.=0A= >>>=0A= >>> _______________________________________________ Modern=0A= >>> mailing list Modern@ietf.org =0A= >>> https://www.ietf.org/mailman/listinfo/modern=0A= >>>=0A= >>> _______________________________________________=0A= >>> dispatch mailing list=0A= >>> dispatch@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>>=0A= >>>=0A= >>> _______________________________________________ Modern=0A= >>> mailing list Modern@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/modern=0A= >> _______________________________________________=0A= >> Modern mailing list=0A= >> Modern@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/modern=0A= >=0A= >=0A= > _______________________________________________=0A= > Modern mailing list=0A= > Modern@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/modern=0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= From nobody Wed Feb 25 11:54:01 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 7F5081A701A; Wed, 25 Feb 2015 11:18:00 -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 PR_5EfPd7Ht8; Wed, 25 Feb 2015 11:17:57 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642BF1A700E; Wed, 25 Feb 2015 11:17:26 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-7e-54edcb6b2d46 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.8F.03307.B6BCDE45; Wed, 25 Feb 2015 14:17:31 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 25 Feb 2015 14:17:25 -0500 From: Hala Mowafy To: Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUSxyUNMhknct5ESAEGnIVCPAoZ0BvQVY Date: Wed, 25 Feb 2015 19:17:24 +0000 Message-ID: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPiG726bchBh8uy1pcnb2P0eL7hwVM FksnLWC1eNp4ltHi0IOn7BaX9jNZzPhh4MDu0fpsL6vHy/45jB5Llvxk8pj48QyzR9ul3cwB rFFcNimpOZllqUX6dglcGb2fZ7EVnMireHb3IGsD44uILkZODgkBE4mu87sYIWwxiQv31rN1 MXJxCAkcYZTo330FylnOKHH84zF2kCo2AR2JOX8/MoPYIgIaEi37ulhAipgF2pkkzk9ewgKS EBYwlHja/5kJoshIYuOkB8ww9ultS8FqWARUJfqnzmcFsXkF7CVOPZwGVM8BtE1f4uoDARCT U8BAYvNbsOMYgY77fmoN2ERmAXGJW0/mM0EcLSCxZM95ZghbVOLl43+sEDV6EjemTmGDsLUl li18zQyxSVDi5MwnLBMYRWchGTULScssJC2zkLQsYGRZxchRWpxalptuZLCJERhZxyTYdHcw 7nlpeYhRgINRiYfX4OXrECHWxLLiytxDjNIcLErivIseHAwREkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwNii+unRGc0uvfexT9Z8K9J7+v+lkVX28nJnlXk7V8i2GKatuNvoXbZXNNWTLWbx scxff0UK5q/vOVV3KW5DcULXyapN3FMrlotq8THVFpQuuD9VoSNQqPGQXUDw3F1r5efu4vLK 2j934au98w9Lzw9nPbPihaAZEz9/cHhCsl781mC55tlJfkosxRmJhlrMRcWJAIb53P6NAgAA Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 11:53:59 -0800 Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 19:18:00 -0000 Not to my knowledge in North America.=20 Keith, I believe you are referencing an ISDN PBX standard so it may have be= en just within a business group - not inter-network?? Correct me if I'm wro= ng.=20 In our discussions at ATIS last year for CNAM in SIP headers someone brough= t up limitations on network elements handling more than 35 characters and t= hat is what we are planning to support with an objective of 60 ch in the fu= ture.=20 I think 35 is more than enough even for some of the longest, hyphenated nam= es.=20 Hala Mowafy ERICSSON=20 > On Feb 25, 2015, at 1:55 PM, Richard Shockey wrote: >=20 >=20 > Humm.. Thanks. >=20 > I=B9m not sure anyone has actually deployed a 50 character service. Does > anyone know? =20 >=20 >=20 >=20 > On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" > wrote: >=20 >> ITU-T Recommendation I.251.9 specifies: >>=20 >> calling name: Information associated with a specific calling party >> number. The maximum length is at least 15 characters and may be up to 50 >> characters. The exact length, format and character set (e.g. T.51, T.52) >> of the calling name to be delivered is a service provider option >>=20 >> Therefore 15 would appear to be a deployment specific limitation. >>=20 >> I believe QSIG defines 50 characters. >>=20 >> The definition above also raises the question of character set. >>=20 >> QSIG defines a number of different character sets. >>=20 >>=20 >>=20 >> Regards >>=20 >> Keith=20 >>=20 >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >>> Of Richard Shockey >>> Sent: 25 February 2015 17:05 >>> To: DOLLY, MARTIN C >>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org; >>> modern@ietf.org >>> Subject: Re: [dispatch] [Modern] draft charter >>>=20 >>>=20 >>> Thanks Martin .. This is my very raw first cut at a charter. >>> Its hopefully simple and straight forward. >>>=20 >>> Send me any edits etc. >>>=20 >>> ***** >>>=20 >>> CNIT Charter [Calling Name Identity Trust] >>>=20 >>>=20 >>> WG Chairs TBD: >>>=20 >>>=20 >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >>> Characters of information associated with a specific E.164 >>> calling party number in the Public Switched Telephone Network >>> [PSTN]. In the PSTN this data is sent by the originating >>> network only at the specific request of the terminating >>> network via a SS7 Transaction Application Part [TCAP] >>> response message. In the Session Initiation Protocol [SIP] >>> this information can be inserted into the FROM: part of the >>> originating INVITE message or by other means. >>>=20 >>>=20 >>> As with the originating source telephone number, this data >>> can be altered in transit creating a variety of malicious >>> abuses similar to the ones identified by the IETF STIR working group. >>>=20 >>>=20 >>> The purpose of the CNIT working group will be to define a >>> data structure, a new SIP header or repurpose an existing SIP >>> header to carry an advanced form of CNAM as well as >>> information from a STIR Validation Authority. The purpose of >>> this work is to present to the SIP called party trusted >>> information from the calling party in order that the called >>> party make a more reasoned and informed judgment on whether >>> to accept the INVITE or not. >>>=20 >>>=20 >>> The working group will not invalidate any existing SIP >>> mechanism for anonymous calling. >>>=20 >>>=20 >>> The working group will, to the best of its ability, reuse >>> existing IETF protocols. >>>=20 >>>=20 >>> Full Internationalization of the Calling Name Identity Trust >>> data object(s) is a requirement. >>>=20 >>>=20 >>> The working group will closely work with the IETF STIR working group >>>=20 >>>=20 >>> The working group will immediately liaison with 3GPP SA-1 in >>> order to coordinate efforts. >>>=20 >>>=20 >>> The working group will coordinate with National Numbering >>> Authorities and National Regulatory Authorities as needed. >>>=20 >>>=20 >>> The working group will deliver the flowing. >>>=20 >>>=20 >>> * A problem statement and requirements detailing the current >>> deployment environment and situations that motivate work on >>> Calling Name Identity Trust. >>> * Define either a new SIP header or document a repurpose of >>> an SIP existing header for Calling Name Identify Trust data * >>> Define a data model for the Calling Name Identity Trust >>> object (s) which may include various forms of multimedia data >>> * Deliver an analysis of privacy implications of the proposed >>> Calling Name Identity Trust mechanism. >>>=20 >>>=20 >>>=20 >>>=20 >>> Milestones: >>>=20 >>>=20 >>> - >>> Richard Shockey >>> Shockey Consulting LLC >>> Chairman of the Board SIP Forum >>> www.shockey.us >>> www.sipforum.org >>> richardshockey.us >>> Skype-Linkedin-Facebook rshockey101 >>> PSTN +1 703-593-2683 >>>=20 >>>=20 >>> From: "DOLLY, MARTIN C" >>> Date: Tuesday, February 24, 2015 at 9:02 PM >>> To: Richard Shockey >>> Cc: "Holmes, David W [CTO]" , >>> "dispatch@ietf.org" , "modern@ietf.org" >>> , "Peterson, Jon" >>> Subject: Re: [Modern] [dispatch] draft charter >>>=20 >>>=20 >>> I support Richard on this >>>=20 >>> Martin Dolly=20 >>> Lead Member of Technical Staff >>> Core & Gov't/Regulatory Standards >>> AT&T Standards and >>> Industry Alliances >>> +1-609-903-3390 >>>=20 >>> Sent from my iPhone >>>=20 >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>> wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> Excellent points David. >>>=20 >>> My concern here is charter overreach. I really want to >>> keep CNAM+/CNIT out of this. IMHO that is a very separate >>> and highly focused effort to define both the modification of >>> the SIP headers necessary to support some enhanced calling >>> party identification and a very limited effort to define the >>> object and or the STIR validation data. >>>=20 >>> I'm violently opposed to "end world hunger" WG's. >>>=20 >>> If registries can be used fine but I certainly want to >>> see how this can be accomplished in bi lateral agreements >>> between consenting service providers and work with CUA >>> vendors on how the data is displayed aka Apple, Samsung, >>> Microsoft in the context of a formal liaison with 3GPP. >>> Certainly the relevance of CNAM+/CNIT in enterprise and >>> residential access markets is important but we all know >>> "Money is the answer what is the question .." >>>=20 >>> I've asked for time in Dispatch to look at the >>> CNAM/CNIT issue and report on the JTF on NNI. As you well >>> know we have made considerable progress. >>>=20 >>> Last week I gave a talk on this to a panel that >>> included many of our friends among the national regulators. >>>=20 >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>=20 >>>=20 >>>=20 >>> =20 >>> From: "Holmes, David W [CTO]" >>> Date: Tuesday, February 24, 2015 at 5:06 PM >>> To: "Peterson, Jon" , >>> "modern@ietf.org" >>> Subject: Re: [Modern] draft charter >>> =20 >>>=20 >>>=20 >>> Jon,=20 >>>=20 >>> =20 >>>=20 >>> Thank you for the work in assembling this draft of the >>> charter for MODERN. >>>=20 >>> =20 >>>=20 >>> We would like to suggest some minor clarifications to >>> the bullets describing the deliverables, to align them with >>> the statement regarding flexibility to support the needs of >>> different regulatory regimes, & thus to ensure that if quoted >>> alone they are not taken out of context; i.e. the group >>> product will be the protocols to support the allocation etc. >>> activities, & it would not attempt to define the allocation >>> processes. We also would like the charter to note the >>> relevant work that has already been performed by both IETF & >>> the ATIS/SIP Forum JTF, & incorporate that into the output >>> from the MODERN WG as appropriate. These changes/additions >>> are have been added to your text inline below. >>>=20 >>> =20 >>>=20 >>> We are hoping that the MODERN session at IETF#92 will >>> have remote access, to allow participation by those of us >>> that cannot attend in person due to other commitments that week. >>>=20 >>> =20 >>>=20 >>> Regards,=20 >>>=20 >>> =20 >>>=20 >>> David/Sprint=20 >>>=20 >>> =20 >>> ______________________________________________________________ >>> ________________ >>>=20 >>> =20 >>>=20 >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>> Of Peterson, Jon >>> Sent: Wednesday, February 11, 2015 9:19 AM >>> To: modern@ietf.org >>> Subject: [Modern] draft charter >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> At the Dallas IETF meeting in March, we'd like to get >>> together and talk about what a working group for MODERN might >>> look like. As an initial input to the discussion, a few of us >>> have put together a proposed charter. While the TeRQ work was >>> positively evaluated in the DISPATCH process, we feel this is >>> broader enough in scope to warrant its own BoF. >>>=20 >>> =20 >>>=20 >>> Comments are welcome, this is just a starting point. >>>=20 >>> =20 >>>=20 >>> ------ >>>=20 >>> =20 >>>=20 >>> Modern charter text: >>>=20 >>> =20 >>>=20 >>> The MODERN working group will define a set of >>> Internet-based mechanisms for the purposes of managing and >>> resolving telephone numbers (TNs) in an IP environment. >>> Existing mechanisms for these purposes face obsolescence as >>> the voice communications infrastructure evolves to IP >>> technology and new applications for TNs become possible. The >>> traditional model of a TN having an association to a single >>> service provider and a single application is breaking down. >>> Its use as a network locator is going away, but its use as an >>> identifier for an individual or an organization will remain >>> for some time. Devices, applications, and network tools >>> increasingly need to manage TNs, including requesting and >>> acquiring TN delegations from authorities. >>>=20 >>> =20 >>>=20 >>> The working group will define a framework for the roles >>> and functions involved in managing and resolving TNs in an IP >>> environment. This includes a protocol mechanism for acquiring >>> TNs, which will provide an enrollment process for the >>> individuals and entities that use and manage TNs. TNs may >>> either be managed in a hierarchical tree, or in a distributed >>> peer-to-peer architecture. Privacy of the enrollment data >>> and security of the resource will be primary considerations. >>>=20 >>> =20 >>>=20 >>> Additionally, the working group will deliver a protocol >>> mechanism for resolving TNs which will allow entities such as >>> service providers, devices, and applications to access data >>> related to TNs, possibly including caller name data (CNAM). >>> Maintaining reliability, real time application performance, >>> security and privacy are primary considerations. The working >>> group will take into consideration existing IETF work >>> including ENUM, SPEERMINT, STIR, and DRINKS. >>>=20 >>> =20 >>>=20 >>> The work of this group is limited to specifying a >>> solution for TNs and covers any service that can be addressed >>> using a TN. Expanding the work to other identifiers is out >>> of scope. Solutions and mechanisms created by the working >>> group will be flexible enough to accommodate different >>> policies, e.g., by different regulatory agencies. >>>=20 >>> =20 >>>=20 >>> The work group will deliver the following: >>>=20 >>> =20 >>>=20 >>> - An architecture overview document that >>> includes high level requirements and security/privacy >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum >>> JTF, that included: >>>=20 >>> o Call routing architecture >>>=20 >>> o Inter-carrier NNI >>>=20 >>> o Cryptographically-enabled Anti-spoofing (STIR) >>>=20 >>> o Enhanced Calling Name (CNIT/CNAM) >>>=20 >>> - A document describing the protocols to >>> support enrollment processes for existing and new TNs >>> including any modifications to metadata related to those TNs >>>=20 >>> - A document describing protocol mechanisms >>> for accessing contact information associated with enrollments >>>=20 >>> - A document describing protocol mechanisms >>> for resolving information related to TNs >>>=20 >>> =20 >>>=20 >>> - =20 >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> =20 >>> This e-mail may contain Sprint proprietary information >>> intended for the sole use of the recipient(s). Any use by >>> others is prohibited. If you are not the intended recipient, >>> please contact the sender and delete all copies of the message. >>> =20 >>> _______________________________________________ Modern >>> mailing list Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> =20 >>>=20 >>> _______________________________________________ Modern >>> mailing list Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Wed Feb 25 11:59:48 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 77A911A87AF for ; Wed, 25 Feb 2015 11:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.383 X-Spam-Level: * X-Spam-Status: No, score=1.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_28=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 F8li5aFZd4Pi for ; Wed, 25 Feb 2015 11:59:33 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id B165B1A8790 for ; Wed, 25 Feb 2015 11:59:33 -0800 (PST) Received: (qmail 2453 invoked by uid 0); 25 Feb 2015 19:59:27 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 25 Feb 2015 19:59:27 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id wqxK1p00h1MNPNq01qyRCF; Wed, 25 Feb 2015 19:58:26 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=XW0vzNQbW2AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=gxZvrgisAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=cMayxExP5pIt7mkmhfUA:9 a=uswajqyHEnEVjzuM:21 a=5zZdin1h4iD8l6pQ:21 a=Spabb166XhwA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=Kyd+iYNhB7Zsk2l+Ew7Yd9qqlZ7KcLkHsitC3EmFup0=; b=FJt1Q9oNba2UN5iJXDersm0jJAiL+2LW2+jofo5Zd9pe0rW4ldIBfBbRAPOIAarrRqN6ChX9FiM34EQwTvwHH81SFQvFmYSA77HNzhU06lldWGcwJ+4ZkZV78KEr1as7; Received: from [108.56.131.201] (port=58463 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQi5r-00037x-P3; Wed, 25 Feb 2015 12:58:03 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 14:57:57 -0500 From: Richard Shockey To: Henning Schulzrinne , Hala Mowafy Message-ID: Thread-Topic: [Modern] [dispatch] draft charter References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 19:59:36 -0000 Structured. IMHO the easiest path to success would be repurpose the CALL-INFO header with a RFC 7095 (json vcard) object. The terminating CSCF would also insert the STIR validation data (what ever that was) CUA=A1=AFs could then have customized settings like we have ring tones =A1=AEWARNING WARNING WILL ROBINSON=A1=AF =A1=AEDIVE DIVE DIVE=A1=AF Klaxon, Sirens etc. We might be able to get this ready before iOS 12. On 2/25/15, 2:40 PM, "Henning Schulzrinne" wrote: >I wonder if we're just talking about an unstructured string, or rather >something more structured, e.g., to be able to distinguish the name of >the caller from the organization, such as > >name=3DHala Mowafy / ou=3DEricsson > >________________________________________ >From: cnit [cnit-bounces@ietf.org] on behalf of Hala Mowafy >[hala.mowafy@ericsson.com] >Sent: Wednesday, February 25, 2015 2:17 PM >To: Richard Shockey >Cc: Holmes, David W [CTO]; dispatch@ietf.org; cnit@ietf.org; DRAGE, Keith >(Keith); modern@ietf.org; DOLLY, MARTIN C >Subject: Re: [cnit] [Modern] [dispatch] draft charter > >Not to my knowledge in North America. >Keith, I believe you are referencing an ISDN PBX standard so it may have >been just within a business group - not inter-network?? Correct me if I'm >wrong. > >In our discussions at ATIS last year for CNAM in SIP headers someone >brought up limitations on network elements handling more than 35 >characters and that is what we are planning to support with an objective >of 60 ch in the future. >I think 35 is more than enough even for some of the longest, hyphenated >names. > >Hala Mowafy >ERICSSON > >> On Feb 25, 2015, at 1:55 PM, Richard Shockey wrote: >> >> >> Humm.. Thanks. >> >> I=A9=F6m not sure anyone has actually deployed a 50 character service. Does >> anyone know? >> >> >> >> On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" >> wrote: >> >>> ITU-T Recommendation I.251.9 specifies: >>> >>> calling name: Information associated with a specific calling party >>> number. The maximum length is at least 15 characters and may be up to >>>50 >>> characters. The exact length, format and character set (e.g. T.51, >>>T.52) >>> of the calling name to be delivered is a service provider option >>> >>> Therefore 15 would appear to be a deployment specific limitation. >>> >>> I believe QSIG defines 50 characters. >>> >>> The definition above also raises the question of character set. >>> >>> QSIG defines a number of different character sets. >>> >>> >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >>>> Of Richard Shockey >>>> Sent: 25 February 2015 17:05 >>>> To: DOLLY, MARTIN C >>>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org; >>>> modern@ietf.org >>>> Subject: Re: [dispatch] [Modern] draft charter >>>> >>>> >>>> Thanks Martin .. This is my very raw first cut at a charter. >>>> Its hopefully simple and straight forward. >>>> >>>> Send me any edits etc. >>>> >>>> ***** >>>> >>>> CNIT Charter [Calling Name Identity Trust] >>>> >>>> >>>> WG Chairs TBD: >>>> >>>> >>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >>>> Characters of information associated with a specific E.164 >>>> calling party number in the Public Switched Telephone Network >>>> [PSTN]. In the PSTN this data is sent by the originating >>>> network only at the specific request of the terminating >>>> network via a SS7 Transaction Application Part [TCAP] >>>> response message. In the Session Initiation Protocol [SIP] >>>> this information can be inserted into the FROM: part of the >>>> originating INVITE message or by other means. >>>> >>>> >>>> As with the originating source telephone number, this data >>>> can be altered in transit creating a variety of malicious >>>> abuses similar to the ones identified by the IETF STIR working group. >>>> >>>> >>>> The purpose of the CNIT working group will be to define a >>>> data structure, a new SIP header or repurpose an existing SIP >>>> header to carry an advanced form of CNAM as well as >>>> information from a STIR Validation Authority. The purpose of >>>> this work is to present to the SIP called party trusted >>>> information from the calling party in order that the called >>>> party make a more reasoned and informed judgment on whether >>>> to accept the INVITE or not. >>>> >>>> >>>> The working group will not invalidate any existing SIP >>>> mechanism for anonymous calling. >>>> >>>> >>>> The working group will, to the best of its ability, reuse >>>> existing IETF protocols. >>>> >>>> >>>> Full Internationalization of the Calling Name Identity Trust >>>> data object(s) is a requirement. >>>> >>>> >>>> The working group will closely work with the IETF STIR working group >>>> >>>> >>>> The working group will immediately liaison with 3GPP SA-1 in >>>> order to coordinate efforts. >>>> >>>> >>>> The working group will coordinate with National Numbering >>>> Authorities and National Regulatory Authorities as needed. >>>> >>>> >>>> The working group will deliver the flowing. >>>> >>>> >>>> * A problem statement and requirements detailing the current >>>> deployment environment and situations that motivate work on >>>> Calling Name Identity Trust. >>>> * Define either a new SIP header or document a repurpose of >>>> an SIP existing header for Calling Name Identify Trust data * >>>> Define a data model for the Calling Name Identity Trust >>>> object (s) which may include various forms of multimedia data >>>> * Deliver an analysis of privacy implications of the proposed >>>> Calling Name Identity Trust mechanism. >>>> >>>> >>>> >>>> >>>> Milestones: >>>> >>>> >>>> - >>>> Richard Shockey >>>> Shockey Consulting LLC >>>> Chairman of the Board SIP Forum >>>> www.shockey.us >>>> www.sipforum.org >>>> richardshockey.us >>>> Skype-Linkedin-Facebook rshockey101 >>>> PSTN +1 703-593-2683 >>>> >>>> >>>> From: "DOLLY, MARTIN C" >>>> Date: Tuesday, February 24, 2015 at 9:02 PM >>>> To: Richard Shockey >>>> Cc: "Holmes, David W [CTO]" , >>>> "dispatch@ietf.org" , "modern@ietf.org" >>>> , "Peterson, Jon" >>>> Subject: Re: [Modern] [dispatch] draft charter >>>> >>>> >>>> I support Richard on this >>>> >>>> Martin Dolly >>>> Lead Member of Technical Staff >>>> Core & Gov't/Regulatory Standards >>>> AT&T Standards and >>>> Industry Alliances >>>> +1-609-903-3390 >>>> >>>> Sent from my iPhone >>>> >>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>>> wrote: >>>> >>>> >>>> >>>> >>>> Excellent points David. >>>> >>>> My concern here is charter overreach. I really want to >>>> keep CNAM+/CNIT out of this. IMHO that is a very separate >>>> and highly focused effort to define both the modification of >>>> the SIP headers necessary to support some enhanced calling >>>> party identification and a very limited effort to define the >>>> object and or the STIR validation data. >>>> >>>> I'm violently opposed to "end world hunger" WG's. >>>> >>>> If registries can be used fine but I certainly want to >>>> see how this can be accomplished in bi lateral agreements >>>> between consenting service providers and work with CUA >>>> vendors on how the data is displayed aka Apple, Samsung, >>>> Microsoft in the context of a formal liaison with 3GPP. >>>> Certainly the relevance of CNAM+/CNIT in enterprise and >>>> residential access markets is important but we all know >>>> "Money is the answer what is the question .." >>>> >>>> I've asked for time in Dispatch to look at the >>>> CNAM/CNIT issue and report on the JTF on NNI. As you well >>>> know we have made considerable progress. >>>> >>>> Last week I gave a talk on this to a panel that >>>> included many of our friends among the national regulators. >>>> >>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>> >>>> >>>> >>>> >>>> From: "Holmes, David W [CTO]" >>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>> To: "Peterson, Jon" , >>>> "modern@ietf.org" >>>> Subject: Re: [Modern] draft charter >>>> >>>> >>>> >>>> Jon, >>>> >>>> >>>> >>>> Thank you for the work in assembling this draft of the >>>> charter for MODERN. >>>> >>>> >>>> >>>> We would like to suggest some minor clarifications to >>>> the bullets describing the deliverables, to align them with >>>> the statement regarding flexibility to support the needs of >>>> different regulatory regimes, & thus to ensure that if quoted >>>> alone they are not taken out of context; i.e. the group >>>> product will be the protocols to support the allocation etc. >>>> activities, & it would not attempt to define the allocation >>>> processes. We also would like the charter to note the >>>> relevant work that has already been performed by both IETF & >>>> the ATIS/SIP Forum JTF, & incorporate that into the output >>>> from the MODERN WG as appropriate. These changes/additions >>>> are have been added to your text inline below. >>>> >>>> >>>> >>>> We are hoping that the MODERN session at IETF#92 will >>>> have remote access, to allow participation by those of us >>>> that cannot attend in person due to other commitments that week. >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> David/Sprint >>>> >>>> >>>> ______________________________________________________________ >>>> ________________ >>>> >>>> >>>> >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>> Of Peterson, Jon >>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>> To: modern@ietf.org >>>> Subject: [Modern] draft charter >>>> >>>> >>>> >>>> >>>> >>>> At the Dallas IETF meeting in March, we'd like to get >>>> together and talk about what a working group for MODERN might >>>> look like. As an initial input to the discussion, a few of us >>>> have put together a proposed charter. While the TeRQ work was >>>> positively evaluated in the DISPATCH process, we feel this is >>>> broader enough in scope to warrant its own BoF. >>>> >>>> >>>> >>>> Comments are welcome, this is just a starting point. >>>> >>>> >>>> >>>> ------ >>>> >>>> >>>> >>>> Modern charter text: >>>> >>>> >>>> >>>> The MODERN working group will define a set of >>>> Internet-based mechanisms for the purposes of managing and >>>> resolving telephone numbers (TNs) in an IP environment. >>>> Existing mechanisms for these purposes face obsolescence as >>>> the voice communications infrastructure evolves to IP >>>> technology and new applications for TNs become possible. The >>>> traditional model of a TN having an association to a single >>>> service provider and a single application is breaking down. >>>> Its use as a network locator is going away, but its use as an >>>> identifier for an individual or an organization will remain >>>> for some time. Devices, applications, and network tools >>>> increasingly need to manage TNs, including requesting and >>>> acquiring TN delegations from authorities. >>>> >>>> >>>> >>>> The working group will define a framework for the roles >>>> and functions involved in managing and resolving TNs in an IP >>>> environment. This includes a protocol mechanism for acquiring >>>> TNs, which will provide an enrollment process for the >>>> individuals and entities that use and manage TNs. TNs may >>>> either be managed in a hierarchical tree, or in a distributed >>>> peer-to-peer architecture. Privacy of the enrollment data >>>> and security of the resource will be primary considerations. >>>> >>>> >>>> >>>> Additionally, the working group will deliver a protocol >>>> mechanism for resolving TNs which will allow entities such as >>>> service providers, devices, and applications to access data >>>> related to TNs, possibly including caller name data (CNAM). >>>> Maintaining reliability, real time application performance, >>>> security and privacy are primary considerations. The working >>>> group will take into consideration existing IETF work >>>> including ENUM, SPEERMINT, STIR, and DRINKS. >>>> >>>> >>>> >>>> The work of this group is limited to specifying a >>>> solution for TNs and covers any service that can be addressed >>>> using a TN. Expanding the work to other identifiers is out >>>> of scope. Solutions and mechanisms created by the working >>>> group will be flexible enough to accommodate different >>>> policies, e.g., by different regulatory agencies. >>>> >>>> >>>> >>>> The work group will deliver the following: >>>> >>>> >>>> >>>> - An architecture overview document that >>>> includes high level requirements and security/privacy >>>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum >>>> JTF, that included: >>>> >>>> o Call routing architecture >>>> >>>> o Inter-carrier NNI >>>> >>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>> >>>> o Enhanced Calling Name (CNIT/CNAM) >>>> >>>> - A document describing the protocols to >>>> support enrollment processes for existing and new TNs >>>> including any modifications to metadata related to those TNs >>>> >>>> - A document describing protocol mechanisms >>>> for accessing contact information associated with enrollments >>>> >>>> - A document describing protocol mechanisms >>>> for resolving information related to TNs >>>> >>>> >>>> >>>> - >>>> >>>> >>>> ________________________________ >>>> >>>> >>>> This e-mail may contain Sprint proprietary information >>>> intended for the sole use of the recipient(s). Any use by >>>> others is prohibited. If you are not the intended recipient, >>>> please contact the sender and delete all copies of the message. >>>> >>>> _______________________________________________ Modern >>>> mailing list Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> _______________________________________________ Modern >>>> mailing list Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit > From nobody Wed Feb 25 14:28:05 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 A22151A9142; Wed, 25 Feb 2015 14:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 SIGxMkU-bfob; Wed, 25 Feb 2015 14:27:59 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 3F7EB1A913F; Wed, 25 Feb 2015 14:27:59 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 2DEF7E52C01FB; Wed, 25 Feb 2015 22:27:53 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t1PMRu0p026803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 23:27:56 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 23:27:56 +0100 From: "DRAGE, Keith (Keith)" To: Hala Mowafy , Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUSydknc63+KxOU+TFO6SzsKOM50BrEEAgABCBJA= Date: Wed, 25 Feb 2015 22:27:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> In-Reply-To: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 25 Feb 2015 22:28:03 -0000 There were two ISDN standards directions for calling name.=20 1) The public network standards. The service definition is the ITU-T Recomm= endation I.251.9 reference. As far as I aware, ITU-T did not proceed to pro= duce the related protocol standards (DSS1 and ISUP) but I could be wrong on= this. 2) The private (or business network standards) defined in ECMA internationa= l, ETSI and ISO (the same document in all groups). These did result in a pr= otocol definition for QSIG. Both sets of documents quote 50 octets maximum length, and both specify tha= t different character sets are possible. And both are defined for internetw= ork operation as well as internal operation. I would suggest that if you think some other value is appropriate, then tha= t alternative figure is the one that should be justified, given that the en= tire charter is ISDN centric! In regards to assessing length of names in general use, please give source = references for what you think is reasonable. I am aware that this will vary= from country to country, and deployment to deployment, based on style of n= aming, language, formal or informal address, title or professional qualific= ations and so on. I would prefer not to work beginning from statements that= start "I think..." http://www.historyrundown.com/top-5-people-with-the-longest-names/ Regards Keith Regards Keith > -----Original Message----- > From: Hala Mowafy [mailto:hala.mowafy@ericsson.com]=20 > Sent: 25 February 2015 19:17 > To: Richard Shockey > Cc: DRAGE, Keith (Keith); DOLLY, MARTIN C; Holmes, David W=20 > [CTO]; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org > Subject: Re: [Modern] [dispatch] draft charter >=20 > Not to my knowledge in North America.=20 > Keith, I believe you are referencing an ISDN PBX standard so=20 > it may have been just within a business group - not=20 > inter-network?? Correct me if I'm wrong.=20 >=20 > In our discussions at ATIS last year for CNAM in SIP headers=20 > someone brought up limitations on network elements handling=20 > more than 35 characters and that is what we are planning to=20 > support with an objective of 60 ch in the future.=20 > I think 35 is more than enough even for some of the longest,=20 > hyphenated names.=20 >=20 > Hala Mowafy > ERICSSON=20 >=20 > > On Feb 25, 2015, at 1:55 PM, Richard Shockey=20 > wrote: > >=20 > >=20 > > Humm.. Thanks. > >=20 > > I=B9m not sure anyone has actually deployed a 50 character=20 > service. Does=20 > > anyone know? > >=20 > >=20 > >=20 > > On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" > > wrote: > >=20 > >> ITU-T Recommendation I.251.9 specifies: > >>=20 > >> calling name: Information associated with a specific calling party=20 > >> number. The maximum length is at least 15 characters and=20 > may be up to=20 > >> 50 characters. The exact length, format and character set=20 > (e.g. T.51,=20 > >> T.52) of the calling name to be delivered is a service provider=20 > >> option > >>=20 > >> Therefore 15 would appear to be a deployment specific limitation. > >>=20 > >> I believe QSIG defines 50 characters. > >>=20 > >> The definition above also raises the question of character set. > >>=20 > >> QSIG defines a number of different character sets. > >>=20 > >>=20 > >>=20 > >> Regards > >>=20 > >> Keith > >>=20 > >>> -----Original Message----- > >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > >>> Richard Shockey > >>> Sent: 25 February 2015 17:05 > >>> To: DOLLY, MARTIN C > >>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=20 > >>> modern@ietf.org > >>> Subject: Re: [dispatch] [Modern] draft charter > >>>=20 > >>>=20 > >>> Thanks Martin .. This is my very raw first cut at a charter. > >>> Its hopefully simple and straight forward. > >>>=20 > >>> Send me any edits etc. > >>>=20 > >>> ***** > >>>=20 > >>> CNIT Charter [Calling Name Identity Trust] > >>>=20 > >>>=20 > >>> WG Chairs TBD: > >>>=20 > >>>=20 > >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII=20 > >>> Characters of information associated with a specific=20 > E.164 calling=20 > >>> party number in the Public Switched Telephone Network [PSTN]. In=20 > >>> the PSTN this data is sent by the originating network only at the=20 > >>> specific request of the terminating network via a SS7 Transaction=20 > >>> Application Part [TCAP] response message. In the Session=20 > Initiation=20 > >>> Protocol [SIP] this information can be inserted into the=20 > FROM: part=20 > >>> of the originating INVITE message or by other means. > >>>=20 > >>>=20 > >>> As with the originating source telephone number, this data can be=20 > >>> altered in transit creating a variety of malicious abuses=20 > similar to=20 > >>> the ones identified by the IETF STIR working group. > >>>=20 > >>>=20 > >>> The purpose of the CNIT working group will be to define a data=20 > >>> structure, a new SIP header or repurpose an existing SIP=20 > header to=20 > >>> carry an advanced form of CNAM as well as information from a STIR=20 > >>> Validation Authority. The purpose of this work is to=20 > present to the=20 > >>> SIP called party trusted information from the calling=20 > party in order=20 > >>> that the called party make a more reasoned and informed=20 > judgment on=20 > >>> whether to accept the INVITE or not. > >>>=20 > >>>=20 > >>> The working group will not invalidate any existing SIP=20 > mechanism for=20 > >>> anonymous calling. > >>>=20 > >>>=20 > >>> The working group will, to the best of its ability, reuse=20 > existing=20 > >>> IETF protocols. > >>>=20 > >>>=20 > >>> Full Internationalization of the Calling Name Identity Trust data=20 > >>> object(s) is a requirement. > >>>=20 > >>>=20 > >>> The working group will closely work with the IETF STIR=20 > working group > >>>=20 > >>>=20 > >>> The working group will immediately liaison with 3GPP SA-1=20 > in order=20 > >>> to coordinate efforts. > >>>=20 > >>>=20 > >>> The working group will coordinate with National Numbering=20 > >>> Authorities and National Regulatory Authorities as needed. > >>>=20 > >>>=20 > >>> The working group will deliver the flowing. > >>>=20 > >>>=20 > >>> * A problem statement and requirements detailing the current=20 > >>> deployment environment and situations that motivate work=20 > on Calling=20 > >>> Name Identity Trust. > >>> * Define either a new SIP header or document a repurpose=20 > of an SIP=20 > >>> existing header for Calling Name Identify Trust data *=20 > Define a data=20 > >>> model for the Calling Name Identity Trust object (s) which may=20 > >>> include various forms of multimedia data > >>> * Deliver an analysis of privacy implications of the proposed=20 > >>> Calling Name Identity Trust mechanism. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Milestones: > >>>=20 > >>>=20 > >>> - > >>> Richard Shockey > >>> Shockey Consulting LLC > >>> Chairman of the Board SIP Forum > >>> www.shockey.us > >>> www.sipforum.org > >>> richardshockey.us > >>> Skype-Linkedin-Facebook rshockey101 > >>> PSTN +1 703-593-2683 > >>>=20 > >>>=20 > >>> From: "DOLLY, MARTIN C" > >>> Date: Tuesday, February 24, 2015 at 9:02 PM > >>> To: Richard Shockey > >>> Cc: "Holmes, David W [CTO]" ,=20 > >>> "dispatch@ietf.org" , "modern@ietf.org" > >>> , "Peterson, Jon" > >>> Subject: Re: [Modern] [dispatch] draft charter > >>>=20 > >>>=20 > >>> I support Richard on this > >>>=20 > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core & Gov't/Regulatory Standards > >>> AT&T Standards and > >>> Industry Alliances > >>> +1-609-903-3390 > >>>=20 > >>> Sent from my iPhone > >>>=20 > >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey =20 > >>> wrote: > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Excellent points David. > >>>=20 > >>> My concern here is charter overreach. I really want to keep=20 > >>> CNAM+/CNIT out of this. IMHO that is a very separate and highly=20 > >>> focused effort to define both the modification of the SIP headers=20 > >>> necessary to support some enhanced calling party=20 > identification and=20 > >>> a very limited effort to define the object and or the STIR=20 > >>> validation data. > >>>=20 > >>> I'm violently opposed to "end world hunger" WG's. > >>>=20 > >>> If registries can be used fine but I certainly want to see how=20 > >>> this can be accomplished in bi lateral agreements between=20 > consenting=20 > >>> service providers and work with CUA vendors on how the data is=20 > >>> displayed aka Apple, Samsung, Microsoft in the context of=20 > a formal=20 > >>> liaison with 3GPP. > >>> Certainly the relevance of CNAM+/CNIT in enterprise and=20 > residential=20 > >>> access markets is important but we all know "Money is the answer=20 > >>> what is the question .." > >>>=20 > >>> I've asked for time in Dispatch to look at the CNAM/CNIT issue=20 > >>> and report on the JTF on NNI. As you well know we have made=20 > >>> considerable progress. > >>>=20 > >>> Last week I gave a talk on this to a panel that=20 > included many of=20 > >>> our friends among the national regulators. > >>>=20 > >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 > >>>=20 > >>>=20 > >>>=20 > >>> =20 > >>> From: "Holmes, David W [CTO]" > >>> Date: Tuesday, February 24, 2015 at 5:06 PM > >>> To: "Peterson, Jon" ,=20 > "modern@ietf.org"=20 > >>> > >>> Subject: Re: [Modern] draft charter > >>> =20 > >>>=20 > >>>=20 > >>> Jon, > >>>=20 > >>> =20 > >>>=20 > >>> Thank you for the work in assembling this draft of the charter=20 > >>> for MODERN. > >>>=20 > >>> =20 > >>>=20 > >>> We would like to suggest some minor clarifications to=20 > the bullets=20 > >>> describing the deliverables, to align them with the statement=20 > >>> regarding flexibility to support the needs of different=20 > regulatory=20 > >>> regimes, & thus to ensure that if quoted alone they are not taken=20 > >>> out of context; i.e. the group product will be the protocols to=20 > >>> support the allocation etc. > >>> activities, & it would not attempt to define the allocation=20 > >>> processes. We also would like the charter to note the=20 > relevant work=20 > >>> that has already been performed by both IETF & the ATIS/SIP Forum=20 > >>> JTF, & incorporate that into the output from the MODERN WG as=20 > >>> appropriate. These changes/additions are have been added to your=20 > >>> text inline below. > >>>=20 > >>> =20 > >>>=20 > >>> We are hoping that the MODERN session at IETF#92 will=20 > have remote=20 > >>> access, to allow participation by those of us that cannot=20 > attend in=20 > >>> person due to other commitments that week. > >>>=20 > >>> =20 > >>>=20 > >>> Regards, > >>>=20 > >>> =20 > >>>=20 > >>> David/Sprint > >>>=20 > >>> =20 > >>> ______________________________________________________________ > >>> ________________ > >>>=20 > >>> =20 > >>>=20 > >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > >>> Peterson, Jon > >>> Sent: Wednesday, February 11, 2015 9:19 AM > >>> To: modern@ietf.org > >>> Subject: [Modern] draft charter > >>>=20 > >>> =20 > >>>=20 > >>> =20 > >>>=20 > >>> At the Dallas IETF meeting in March, we'd like to get together=20 > >>> and talk about what a working group for MODERN might look=20 > like. As=20 > >>> an initial input to the discussion, a few of us have put=20 > together a=20 > >>> proposed charter. While the TeRQ work was positively evaluated in=20 > >>> the DISPATCH process, we feel this is broader enough in scope to=20 > >>> warrant its own BoF. > >>>=20 > >>> =20 > >>>=20 > >>> Comments are welcome, this is just a starting point. > >>>=20 > >>> =20 > >>>=20 > >>> ------ > >>>=20 > >>> =20 > >>>=20 > >>> Modern charter text: > >>>=20 > >>> =20 > >>>=20 > >>> The MODERN working group will define a set of Internet-based=20 > >>> mechanisms for the purposes of managing and resolving telephone=20 > >>> numbers (TNs) in an IP environment. > >>> Existing mechanisms for these purposes face obsolescence as the=20 > >>> voice communications infrastructure evolves to IP=20 > technology and new=20 > >>> applications for TNs become possible. The traditional=20 > model of a TN=20 > >>> having an association to a single service provider and a single=20 > >>> application is breaking down. > >>> Its use as a network locator is going away, but its use as an=20 > >>> identifier for an individual or an organization will=20 > remain for some=20 > >>> time. Devices, applications, and network tools=20 > increasingly need to=20 > >>> manage TNs, including requesting and acquiring TN=20 > delegations from=20 > >>> authorities. > >>>=20 > >>> =20 > >>>=20 > >>> The working group will define a framework for the roles and=20 > >>> functions involved in managing and resolving TNs in an IP=20 > >>> environment. This includes a protocol mechanism for=20 > acquiring TNs,=20 > >>> which will provide an enrollment process for the individuals and=20 > >>> entities that use and manage TNs. TNs may either be managed in a=20 > >>> hierarchical tree, or in a distributed peer-to-peer=20 > architecture. =20 > >>> Privacy of the enrollment data and security of the=20 > resource will be=20 > >>> primary considerations. > >>>=20 > >>> =20 > >>>=20 > >>> Additionally, the working group will deliver a=20 > protocol mechanism=20 > >>> for resolving TNs which will allow entities such as service=20 > >>> providers, devices, and applications to access data=20 > related to TNs,=20 > >>> possibly including caller name data (CNAM). > >>> Maintaining reliability, real time application=20 > performance, security=20 > >>> and privacy are primary considerations. The working=20 > group will take=20 > >>> into consideration existing IETF work including ENUM, SPEERMINT,=20 > >>> STIR, and DRINKS. > >>>=20 > >>> =20 > >>>=20 > >>> The work of this group is limited to specifying a solution for=20 > >>> TNs and covers any service that can be addressed using a TN. =20 > >>> Expanding the work to other identifiers is out of scope. =20 > Solutions=20 > >>> and mechanisms created by the working group will be=20 > flexible enough=20 > >>> to accommodate different policies, e.g., by different regulatory=20 > >>> agencies. > >>>=20 > >>> =20 > >>>=20 > >>> The work group will deliver the following: > >>>=20 > >>> =20 > >>>=20 > >>> - An architecture overview document that > >>> includes high level requirements and security/privacy=20 > >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF,=20 > >>> that included: > >>>=20 > >>> o Call routing architecture > >>>=20 > >>> o Inter-carrier NNI > >>>=20 > >>> o Cryptographically-enabled Anti-spoofing (STIR) > >>>=20 > >>> o Enhanced Calling Name (CNIT/CNAM) > >>>=20 > >>> - A document describing the protocols to > >>> support enrollment processes for existing and new TNs=20 > including any=20 > >>> modifications to metadata related to those TNs > >>>=20 > >>> - A document describing protocol mechanisms > >>> for accessing contact information associated with enrollments > >>>=20 > >>> - A document describing protocol mechanisms > >>> for resolving information related to TNs > >>>=20 > >>> =20 > >>>=20 > >>> - =20 > >>>=20 > >>>=20 > >>> ________________________________ > >>>=20 > >>> =20 > >>> This e-mail may contain Sprint proprietary information=20 > intended=20 > >>> for the sole use of the recipient(s). Any use by others is=20 > >>> prohibited. If you are not the intended recipient, please contact=20 > >>> the sender and delete all copies of the message. > >>> =20 > >>> _______________________________________________ Modern mailing=20 > >>> list Modern@ietf.org =20 > >>> https://www.ietf.org/mailman/listinfo/modern > >>>=20 > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> =20 > >>>=20 > >>> _______________________________________________ Modern=20 > mailing list=20 > >>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern > >> _______________________________________________ > >> Modern mailing list > >> Modern@ietf.org > >> https://www.ietf.org/mailman/listinfo/modern > >=20 > >=20 > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > = From nobody Thu Feb 26 01:31: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 950601A1BE3 for ; Thu, 26 Feb 2015 01:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e260_yf7W3z1 for ; Thu, 26 Feb 2015 01:31:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BBF1A1BDF for ; Thu, 26 Feb 2015 01:31:36 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A46D018C48D; Thu, 26 Feb 2015 10:31:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 53FD24C14E; Thu, 26 Feb 2015 10:31:34 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 10:31:34 +0100 From: To: "dispatch@ietf.org" Thread-Topic: PCP for SIP Deployments Thread-Index: AdBRpv5w7XTmu/weRVKc3+vCrIJ62g== Date: Thu, 26 Feb 2015 09:31:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300491577EOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.26.62419 Archived-At: Subject: [dispatch] PCP for SIP Deployments 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, 26 Feb 2015 09:31:38 -0000 --_000_787AE7BB302AE849A7480A190F8B93300491577EOPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to share with this group a short document that explains how PC= P can be of great use in the context SIP-based services: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 As indicated in the I-D, the main benefits include (but not limited to): o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in intermediate middleboxes. o Work without requiring symmetric RTP/RTCP [RFC4961]. o Not require symmetric SIP to work (i.e., rport [RFC3581]). o Easily support unidirectional sessions. When this document was first presented in the PCP WG, I was suggested that = it is better to publish it in RAI with a review from the PCP WG. Hence, thi= s message to the list. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300491577EOPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I would like to share with this group a sho= rt document that explains how PCP can be of great use in the context SIP-ba= sed services:

http://tools.ietf.org/html/draft-boucadair-pcp-= sip-ipv6-03

 

As indicated in the I-D, the main benefits = include (but not limited to):

 

   o  Avoid embedding an ALG in th=
e middleboxes.  Note, ALGs are not
      recommended since =
the evolution of the service would depend on the
      ALG mainten=
ance.
   o  Not require any Hosted NAT T=
raversal function (e.g., [RFC7362]) to
      be embedded in the=
 SIP server.  Intermediate NATs and firewalls
      are transparent to=
 the SIP service platform.
   o  Avoid overloading the networ=
k with keepalive message to maintain
      the mapping in int=
ermediate middleboxes.
   o  Work without requiring symme=
tric RTP/RTCP [RFC4961].
   o  Not require symmetric SIP to=
 work (i.e., rport [RFC3581]).
   o  Easily support unidirectiona=
l sessions.

 

When this document was first presented in t= he PCP WG, I was suggested that it is better to publish it in RAI with a re= view from the PCP WG. Hence, this message to the list.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300491577EOPEXCLILM23corp_-- From nobody Thu Feb 26 10:04:47 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 CF9F11A90BD; Thu, 26 Feb 2015 10:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.515 X-Spam-Level: ** X-Spam-Status: No, score=2.515 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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-F0O5BxMyvE; Thu, 26 Feb 2015 10:03:49 -0800 (PST) Received: from mia.egh.com (50-79-181-89-static.hfc.comcastbusiness.net [50.79.181.89]) (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 455E81A90AD; Thu, 26 Feb 2015 10:03:48 -0800 (PST) Received: from vpna164.egh.com (vpna164.egh.com [198.179.132.164]) by mia.egh.com (8.14.5/8.14.5/SuSE Linux 0.8) with ESMTP id t1QI3ah9015157; Thu, 26 Feb 2015 13:03:37 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Cronin In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 26 Feb 2015 13:03:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D3A9FA5-5703-4562-86AE-D537C4C407A2@egh.com> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.2070.6) Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 10:04:46 -0800 Cc: "Holmes, David W \[CTO\]" , Ken Pogran , Hala Mowafy , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [cnit] [Modern] draft charter 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, 26 Feb 2015 18:03:51 -0000 > On Feb 25, 2015, at 5:27 PM, DRAGE, Keith (Keith) = wrote: > In regards to assessing length of names in general use, please give = source references for what you think is reasonable. I am aware that this = will vary from country to country, and deployment to deployment, based = on style of naming, language, formal or informal address, title or = professional qualifications and so on. I would prefer not to work = beginning from statements that start "I think=85=94 We=92ve been compressing caller names down to 15 octets for caller-name = for a quarter-century or so. We store a long name of 40 octets used to = create the short name. I believe that at some point in the past that was = the length limit on listed name for Bell System standard service orders. = Just a reference point. There are cases other than single personal names that will benefit from = longer caller name: 1) Businesses, particularly professional firms (e.g Smith, Jones and = McGarrity)=20 2) Couples (e.g Donald & Millicent Scanlin)=20 3) Couples with different surnames: (John Doe and Mary Roe) (I know this from complaints. :)) (from different mail from Keith Drage) >=20 > The definition above also raises the question of character set. >=20 > QSIG defines a number of different character sets. I would use UTF-8 and be done with it. Other thoughts: I=92m not familiar (yet :)) with the ITU recommendation but what with = the wide variety terminating equipment intelligence, I don=92t think one = size fits all anymore. I think a network caller-name/caller-id database = should store rich data (like the JSON vcards, I think Richard Shockey = suggested?) The terminating equipment (or intermediate system) can query for as much = data as it can use, or just say =93I can display n chars, send me that=94.= =20 Jonathan Jonathan Cronin jcronin@egh.com 781 861 0670 EGH, Inc. 55 Waltham Street Lexington, MA 02421 From nobody Thu Feb 26 11:35:58 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 71B551A6FBC; Thu, 26 Feb 2015 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 G3-J5mjX_eq5; Thu, 26 Feb 2015 11:35:52 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id E95A51AC3F5; Thu, 26 Feb 2015 11:35:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1AAA5710E23; Thu, 26 Feb 2015 19:35:35 +0000 (GMT) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KBlEY774RZT; Thu, 26 Feb 2015 19:35:33 +0000 (GMT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id DEB0C710E1C; Thu, 26 Feb 2015 19:35:33 +0000 (GMT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 26 Feb 2015 19:35:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7D8D2ED4-2DFF-46B8-B401-F45CD522351D@insensate.co.uk> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "Holmes, David W \[CTO\]" , Hala Mowafy , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] draft charter 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, 26 Feb 2015 19:35:56 -0000 Hi Keith, folks, of historical interest only perhaps, but in the UK almost all fixed line = TEs were connected via analogue termination service. Thus, for the non-ISDN expected capabilities of TEs using this stuff ... BT's specs for Caller Display Service (their brand of CLID service) are = at Annex A (page 27 et seq) of: and in detail within: Tech. specs of the analogue line itself are spelt out in = In SIN242 a maximum message size of 64 octets is specified for Caller ID = messages. The underlying datalink from SIN227 allows an absolute maximum of 255 = octets per (basic mode) message. Thus, whilst decidedly -not- NNI, nor ISDN (and not QSIG/DPNSS...) UNI, = there's the spec and length limits for CDS in the UK. [The equivalent Telcordia CLASS docs spell out the service used "over = there" and no doubt set their own limits] We now return you to your previous channel. all the best, Lawrence On 25 Feb 2015, at 22:27, DRAGE, Keith (Keith) = wrote: > There were two ISDN standards directions for calling name.=20 >=20 > 1) The public network standards. The service definition is the = ITU-T Recommendation I.251.9 reference. As far as I aware, ITU-T did not = proceed to produce the related protocol standards (DSS1 and ISUP) but I = could be wrong on this. >=20 > 2) The private (or business network standards) defined in ECMA = international, ETSI and ISO (the same document in all groups). These did = result in a protocol definition for QSIG. >=20 > Both sets of documents quote 50 octets maximum length, and both = specify that different character sets are possible. And both are defined = for internetwork operation as well as internal operation. >=20 > I would suggest that if you think some other value is appropriate, = then that alternative figure is the one that should be justified, given = that the entire charter is ISDN centric! >=20 > In regards to assessing length of names in general use, please give = source references for what you think is reasonable. I am aware that this = will vary from country to country, and deployment to deployment, based = on style of naming, language, formal or informal address, title or = professional qualifications and so on. I would prefer not to work = beginning from statements that start "I think..." >=20 > http://www.historyrundown.com/top-5-people-with-the-longest-names/ >=20 > Regards >=20 > Keith >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: Hala Mowafy [mailto:hala.mowafy@ericsson.com]=20 >> Sent: 25 February 2015 19:17 >> To: Richard Shockey >> Cc: DRAGE, Keith (Keith); DOLLY, MARTIN C; Holmes, David W=20 >> [CTO]; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org >> Subject: Re: [Modern] [dispatch] draft charter >>=20 >> Not to my knowledge in North America.=20 >> Keith, I believe you are referencing an ISDN PBX standard so=20 >> it may have been just within a business group - not=20 >> inter-network?? Correct me if I'm wrong.=20 >>=20 >> In our discussions at ATIS last year for CNAM in SIP headers=20 >> someone brought up limitations on network elements handling=20 >> more than 35 characters and that is what we are planning to=20 >> support with an objective of 60 ch in the future.=20 >> I think 35 is more than enough even for some of the longest,=20 >> hyphenated names.=20 >>=20 >> Hala Mowafy >> ERICSSON=20 >>=20 >>> On Feb 25, 2015, at 1:55 PM, Richard Shockey=20 >> wrote: >>>=20 >>>=20 >>> Humm.. Thanks. >>>=20 >>> I=B9m not sure anyone has actually deployed a 50 character=20 >> service. Does=20 >>> anyone know? >>>=20 >>>=20 >>>=20 >>> On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" >>> wrote: >>>=20 >>>> ITU-T Recommendation I.251.9 specifies: >>>>=20 >>>> calling name: Information associated with a specific calling party=20= >>>> number. The maximum length is at least 15 characters and=20 >> may be up to=20 >>>> 50 characters. The exact length, format and character set=20 >> (e.g. T.51,=20 >>>> T.52) of the calling name to be delivered is a service provider=20 >>>> option >>>>=20 >>>> Therefore 15 would appear to be a deployment specific limitation. >>>>=20 >>>> I believe QSIG defines 50 characters. >>>>=20 >>>> The definition above also raises the question of character set. >>>>=20 >>>> QSIG defines a number of different character sets. >>>>=20 >>>>=20 >>>>=20 >>>> Regards >>>>=20 >>>> Keith >>>>=20 >>>>> -----Original Message----- >>>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 >>>>> Richard Shockey >>>>> Sent: 25 February 2015 17:05 >>>>> To: DOLLY, MARTIN C >>>>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=20 >>>>> modern@ietf.org >>>>> Subject: Re: [dispatch] [Modern] draft charter >>>>>=20 >>>>>=20 >>>>> Thanks Martin .. This is my very raw first cut at a charter. >>>>> Its hopefully simple and straight forward. >>>>>=20 >>>>> Send me any edits etc. >>>>>=20 >>>>> ***** >>>>>=20 >>>>> CNIT Charter [Calling Name Identity Trust] >>>>>=20 >>>>>=20 >>>>> WG Chairs TBD: >>>>>=20 >>>>>=20 >>>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII=20 >>>>> Characters of information associated with a specific=20 >> E.164 calling=20 >>>>> party number in the Public Switched Telephone Network [PSTN]. In=20= >>>>> the PSTN this data is sent by the originating network only at the=20= >>>>> specific request of the terminating network via a SS7 Transaction=20= >>>>> Application Part [TCAP] response message. In the Session=20 >> Initiation=20 >>>>> Protocol [SIP] this information can be inserted into the=20 >> FROM: part=20 >>>>> of the originating INVITE message or by other means. >>>>>=20 >>>>>=20 >>>>> As with the originating source telephone number, this data can be=20= >>>>> altered in transit creating a variety of malicious abuses=20 >> similar to=20 >>>>> the ones identified by the IETF STIR working group. >>>>>=20 >>>>>=20 >>>>> The purpose of the CNIT working group will be to define a data=20 >>>>> structure, a new SIP header or repurpose an existing SIP=20 >> header to=20 >>>>> carry an advanced form of CNAM as well as information from a STIR=20= >>>>> Validation Authority. The purpose of this work is to=20 >> present to the=20 >>>>> SIP called party trusted information from the calling=20 >> party in order=20 >>>>> that the called party make a more reasoned and informed=20 >> judgment on=20 >>>>> whether to accept the INVITE or not. >>>>>=20 >>>>>=20 >>>>> The working group will not invalidate any existing SIP=20 >> mechanism for=20 >>>>> anonymous calling. >>>>>=20 >>>>>=20 >>>>> The working group will, to the best of its ability, reuse=20 >> existing=20 >>>>> IETF protocols. >>>>>=20 >>>>>=20 >>>>> Full Internationalization of the Calling Name Identity Trust data=20= >>>>> object(s) is a requirement. >>>>>=20 >>>>>=20 >>>>> The working group will closely work with the IETF STIR=20 >> working group >>>>>=20 >>>>>=20 >>>>> The working group will immediately liaison with 3GPP SA-1=20 >> in order=20 >>>>> to coordinate efforts. >>>>>=20 >>>>>=20 >>>>> The working group will coordinate with National Numbering=20 >>>>> Authorities and National Regulatory Authorities as needed. >>>>>=20 >>>>>=20 >>>>> The working group will deliver the flowing. >>>>>=20 >>>>>=20 >>>>> * A problem statement and requirements detailing the current=20 >>>>> deployment environment and situations that motivate work=20 >> on Calling=20 >>>>> Name Identity Trust. >>>>> * Define either a new SIP header or document a repurpose=20 >> of an SIP=20 >>>>> existing header for Calling Name Identify Trust data *=20 >> Define a data=20 >>>>> model for the Calling Name Identity Trust object (s) which may=20 >>>>> include various forms of multimedia data >>>>> * Deliver an analysis of privacy implications of the proposed=20 >>>>> Calling Name Identity Trust mechanism. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Milestones: >>>>>=20 >>>>>=20 >>>>> - >>>>> Richard Shockey >>>>> Shockey Consulting LLC >>>>> Chairman of the Board SIP Forum >>>>> www.shockey.us >>>>> www.sipforum.org >>>>> richardshockey.us >>>>> Skype-Linkedin-Facebook rshockey101 >>>>> PSTN +1 703-593-2683 >>>>>=20 >>>>>=20 >>>>> From: "DOLLY, MARTIN C" >>>>> Date: Tuesday, February 24, 2015 at 9:02 PM >>>>> To: Richard Shockey >>>>> Cc: "Holmes, David W [CTO]" ,=20 >>>>> "dispatch@ietf.org" , "modern@ietf.org" >>>>> , "Peterson, Jon" >>>>> Subject: Re: [Modern] [dispatch] draft charter >>>>>=20 >>>>>=20 >>>>> I support Richard on this >>>>>=20 >>>>> Martin Dolly >>>>> Lead Member of Technical Staff >>>>> Core & Gov't/Regulatory Standards >>>>> AT&T Standards and >>>>> Industry Alliances >>>>> +1-609-903-3390 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey =20= >>>>> wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Excellent points David. >>>>>=20 >>>>> My concern here is charter overreach. I really want to keep=20 >>>>> CNAM+/CNIT out of this. IMHO that is a very separate and highly=20= >>>>> focused effort to define both the modification of the SIP headers=20= >>>>> necessary to support some enhanced calling party=20 >> identification and=20 >>>>> a very limited effort to define the object and or the STIR=20 >>>>> validation data. >>>>>=20 >>>>> I'm violently opposed to "end world hunger" WG's. >>>>>=20 >>>>> If registries can be used fine but I certainly want to see how=20 >>>>> this can be accomplished in bi lateral agreements between=20 >> consenting=20 >>>>> service providers and work with CUA vendors on how the data is=20 >>>>> displayed aka Apple, Samsung, Microsoft in the context of=20 >> a formal=20 >>>>> liaison with 3GPP. >>>>> Certainly the relevance of CNAM+/CNIT in enterprise and=20 >> residential=20 >>>>> access markets is important but we all know "Money is the answer=20= >>>>> what is the question .." >>>>>=20 >>>>> I've asked for time in Dispatch to look at the CNAM/CNIT issue=20 >>>>> and report on the JTF on NNI. As you well know we have made=20 >>>>> considerable progress. >>>>>=20 >>>>> Last week I gave a talk on this to a panel that=20 >> included many of=20 >>>>> our friends among the national regulators. >>>>>=20 >>>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: "Holmes, David W [CTO]" >>>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>>> To: "Peterson, Jon" ,=20 >> "modern@ietf.org"=20 >>>>> >>>>> Subject: Re: [Modern] draft charter >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Jon, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Thank you for the work in assembling this draft of the charter=20 >>>>> for MODERN. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> We would like to suggest some minor clarifications to=20 >> the bullets=20 >>>>> describing the deliverables, to align them with the statement=20 >>>>> regarding flexibility to support the needs of different=20 >> regulatory=20 >>>>> regimes, & thus to ensure that if quoted alone they are not taken=20= >>>>> out of context; i.e. the group product will be the protocols to=20 >>>>> support the allocation etc. >>>>> activities, & it would not attempt to define the allocation=20 >>>>> processes. We also would like the charter to note the=20 >> relevant work=20 >>>>> that has already been performed by both IETF & the ATIS/SIP Forum=20= >>>>> JTF, & incorporate that into the output from the MODERN WG as=20 >>>>> appropriate. These changes/additions are have been added to your=20= >>>>> text inline below. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> We are hoping that the MODERN session at IETF#92 will=20 >> have remote=20 >>>>> access, to allow participation by those of us that cannot=20 >> attend in=20 >>>>> person due to other commitments that week. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> David/Sprint >>>>>=20 >>>>>=20 >>>>> ______________________________________________________________ >>>>> ________________ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 >>>>> Peterson, Jon >>>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>>> To: modern@ietf.org >>>>> Subject: [Modern] draft charter >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> At the Dallas IETF meeting in March, we'd like to get together=20 >>>>> and talk about what a working group for MODERN might look=20 >> like. As=20 >>>>> an initial input to the discussion, a few of us have put=20 >> together a=20 >>>>> proposed charter. While the TeRQ work was positively evaluated in=20= >>>>> the DISPATCH process, we feel this is broader enough in scope to=20= >>>>> warrant its own BoF. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Comments are welcome, this is just a starting point. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ------ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Modern charter text: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The MODERN working group will define a set of Internet-based=20 >>>>> mechanisms for the purposes of managing and resolving telephone=20 >>>>> numbers (TNs) in an IP environment. >>>>> Existing mechanisms for these purposes face obsolescence as the=20 >>>>> voice communications infrastructure evolves to IP=20 >> technology and new=20 >>>>> applications for TNs become possible. The traditional=20 >> model of a TN=20 >>>>> having an association to a single service provider and a single=20 >>>>> application is breaking down. >>>>> Its use as a network locator is going away, but its use as an=20 >>>>> identifier for an individual or an organization will=20 >> remain for some=20 >>>>> time. Devices, applications, and network tools=20 >> increasingly need to=20 >>>>> manage TNs, including requesting and acquiring TN=20 >> delegations from=20 >>>>> authorities. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The working group will define a framework for the roles and=20 >>>>> functions involved in managing and resolving TNs in an IP=20 >>>>> environment. This includes a protocol mechanism for=20 >> acquiring TNs,=20 >>>>> which will provide an enrollment process for the individuals and=20= >>>>> entities that use and manage TNs. TNs may either be managed in a=20= >>>>> hierarchical tree, or in a distributed peer-to-peer=20 >> architecture. =20 >>>>> Privacy of the enrollment data and security of the=20 >> resource will be=20 >>>>> primary considerations. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Additionally, the working group will deliver a=20 >> protocol mechanism=20 >>>>> for resolving TNs which will allow entities such as service=20 >>>>> providers, devices, and applications to access data=20 >> related to TNs,=20 >>>>> possibly including caller name data (CNAM). >>>>> Maintaining reliability, real time application=20 >> performance, security=20 >>>>> and privacy are primary considerations. The working=20 >> group will take=20 >>>>> into consideration existing IETF work including ENUM, SPEERMINT,=20= >>>>> STIR, and DRINKS. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The work of this group is limited to specifying a solution for=20 >>>>> TNs and covers any service that can be addressed using a TN. =20 >>>>> Expanding the work to other identifiers is out of scope. =20 >> Solutions=20 >>>>> and mechanisms created by the working group will be=20 >> flexible enough=20 >>>>> to accommodate different policies, e.g., by different regulatory=20= >>>>> agencies. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The work group will deliver the following: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - An architecture overview document that >>>>> includes high level requirements and security/privacy=20 >>>>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF,=20= >>>>> that included: >>>>>=20 >>>>> o Call routing architecture >>>>>=20 >>>>> o Inter-carrier NNI >>>>>=20 >>>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>>>=20 >>>>> o Enhanced Calling Name (CNIT/CNAM) >>>>>=20 >>>>> - A document describing the protocols to >>>>> support enrollment processes for existing and new TNs=20 >> including any=20 >>>>> modifications to metadata related to those TNs >>>>>=20 >>>>> - A document describing protocol mechanisms >>>>> for accessing contact information associated with enrollments >>>>>=20 >>>>> - A document describing protocol mechanisms >>>>> for resolving information related to TNs >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - =20 >>>>>=20 >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>>=20 >>>>> This e-mail may contain Sprint proprietary information=20 >> intended=20 >>>>> for the sole use of the recipient(s). Any use by others is=20 >>>>> prohibited. If you are not the intended recipient, please contact=20= >>>>> the sender and delete all copies of the message. >>>>>=20 >>>>> _______________________________________________ Modern mailing=20 >>>>> list Modern@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/modern >>>>>=20 >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>=20 >>>>>=20 >>>>> _______________________________________________ Modern=20 >> mailing list=20 >>>>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>=20 >>>=20 >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Feb 26 11:48:16 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 3179A1A1B0E for ; Thu, 26 Feb 2015 11:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 aKzdoy9qEnXa for ; Thu, 26 Feb 2015 11:48:12 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id CD32C1A1BB8 for ; Thu, 26 Feb 2015 11:48:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id A62E7710FA6; Thu, 26 Feb 2015 19:47:59 +0000 (GMT) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+1XeJs-h3nm; Thu, 26 Feb 2015 19:47:59 +0000 (GMT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 5932B710F9F; Thu, 26 Feb 2015 19:47:59 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: <0D3A9FA5-5703-4562-86AE-D537C4C407A2@egh.com> Date: Thu, 26 Feb 2015 19:47:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <41DFEDBD-5CDF-41C0-97C9-0308C4EA451F@insensate.co.uk> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <0D3A9FA5-5703-4562-86AE-D537C4C407A2@egh.com> To: Jonathan Cronin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "Holmes, David W \[CTO\]" , Ken Pogran , Hala Mowafy , "dispatch@ietf.org" Subject: Re: [dispatch] draft charter 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, 26 Feb 2015 19:48:15 -0000 Hi Jonathon, folks, The "standard example" used over here to argue against 15 character = name field limits was the "Girl Guides Association". Oldie but goodie. The original suggestion for such a severe limit was, IIRC, driven by = fitting the name into the same space as a number field. That always was a wonky choice/over-simplification, and since time t is = no longer at all relevant, IMHO. atb, Lawrence On 26 Feb 2015, at 18:03, Jonathan Cronin wrote: >> On Feb 25, 2015, at 5:27 PM, DRAGE, Keith (Keith) = wrote: >=20 >> In regards to assessing length of names in general use, please give = source references for what you think is reasonable. I am aware that this = will vary from country to country, and deployment to deployment, based = on style of naming, language, formal or informal address, title or = professional qualifications and so on. I would prefer not to work = beginning from statements that start "I think=85=94 >=20 > We=92ve been compressing caller names down to 15 octets for = caller-name for a quarter-century or so. We store a long name of 40 = octets used to create the short name. I believe that at some point in = the past that was the length limit on listed name for Bell System = standard service orders. Just a reference point. >=20 > There are cases other than single personal names that will benefit = from longer caller name: >=20 > 1) Businesses, particularly professional firms (e.g Smith, Jones and = McGarrity)=20 > 2) Couples (e.g Donald & Millicent Scanlin)=20 > 3) Couples with different surnames: (John Doe and Mary Roe) >=20 > (I know this from complaints. :)) >=20 > (from different mail from Keith Drage) >>=20 >> The definition above also raises the question of character set. >>=20 >> QSIG defines a number of different character sets. >=20 > I would use UTF-8 and be done with it. >=20 > Other thoughts: >=20 > I=92m not familiar (yet :)) with the ITU recommendation but what with = the wide variety terminating equipment intelligence, I don=92t think one = size fits all anymore. I think a network caller-name/caller-id database = should store rich data (like the JSON vcards, I think Richard Shockey = suggested?) > The terminating equipment (or intermediate system) can query for as = much data as it can use, or just say =93I can display n chars, send me = that=94. >=20 > Jonathan >=20 > Jonathan Cronin > jcronin@egh.com > 781 861 0670 >=20 > EGH, Inc. > 55 Waltham Street > Lexington, MA 02421 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Feb 27 14:47:48 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 9D67D1A07BD for ; Fri, 27 Feb 2015 14:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.479 X-Spam-Level: * X-Spam-Status: No, score=1.479 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 w-2F3ks1cF2P for ; Fri, 27 Feb 2015 14:47:44 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9EF1A07BC for ; Fri, 27 Feb 2015 14:47:43 -0800 (PST) Received: from userPC (unknown [122.167.76.6]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 84E16648189; Fri, 27 Feb 2015 22:47:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1425077263; bh=9kiaGYefXw7WepAuREQjKr4F4cg2JLZcGjJ/U3tOIOo=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=SpCo8ZaUDJ5kMi+fXb6Q87YG/1lJIMMwWli1Lnbp2enW/qwTk9Pgp4D6CK6OE+3wS 2go+0pF9x0GCquZZzf75ujaO2ZEAvONUZ+KJPjY0QrkXe0uZp3gV4rKunj2bdqY/gY 3HyECLBbL9VUrHVKo3MMF9w6iIxmOujjj4yKDhd8= From: "Parthasarathi R" To: , References: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Sat, 28 Feb 2015 04:17:29 +0530 Message-ID: <023901d052df$6056f2c0$2104d840$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023A_01D0530D.7A0F2EC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBRpv5w7XTmu/weRVKc3+vCrIJ62gBNLj+A Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.54F0F40F.00B5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: Subject: Re: [dispatch] PCP for SIP Deployments 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, 27 Feb 2015 22:47:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023A_01D0530D.7A0F2EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med, It is a interesting draft. The current writing provides PCP advantages in SIP managed network and particularly cellular. The following information has to be added to provide more clarity about this work: 1) Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP server 2) Basic callflow to show how the dialog is established in case P2P is used 3) The draft title mentions IPv6. My understanding is that this shall be used for IPv4 network as well. 4) Add more details about how SIP, PCP, ICE interworking happens as the current reference is related to PCP with rtcweb only. 5) Security implication w.r.t SIP usage of PCP has to be mentioned. 6) Advantage of using PCP over TURN in SIP network shall be provided in the introduction section for better comparison. Regards Partha From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, February 26, 2015 3:02 PM To: dispatch@ietf.org Subject: [dispatch] PCP for SIP Deployments Hi all, I would like to share with this group a short document that explains how PCP can be of great use in the context SIP-based services: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 As indicated in the I-D, the main benefits include (but not limited to): o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [ RFC7362]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in intermediate middleboxes. o Work without requiring symmetric RTP/RTCP [ RFC4961]. o Not require symmetric SIP to work (i.e., rport [ RFC3581]). o Easily support unidirectional sessions. When this document was first presented in the PCP WG, I was suggested that it is better to publish it in RAI with a review from the PCP WG. Hence, this message to the list. Cheers, Med ------=_NextPart_000_023A_01D0530D.7A0F2EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Med,

 

It is a interesting = draft. The current writing provides PCP advantages in SIP managed network and = particularly cellular. The following information has to be added to provide more = clarity about this work:

 

1)      Network = diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP = server

2)      Basic = callflow to show how the dialog is established in case P2P is = used

3)      The draft = title mentions IPv6. My understanding is that this shall be used for IPv4 = network as well.

4)      Add more = details about how SIP, PCP, ICE interworking happens as the current reference is related to PCP with rtcweb only.

5)      Security = implication w.r.t SIP usage of PCP has to be mentioned.

6)      Advantage = of using PCP over TURN in SIP network shall be provided in the introduction = section for better comparison.

 

Regards

Partha

 

From:= dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: Thursday, February 26, 2015 3:02 PM
To: dispatch@ietf.org
Subject: [dispatch] PCP for SIP Deployments

 

Hi all,

 

I would like to share with this group a short document that explains how = PCP can be of great use in the context SIP-based services:

http:= //tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03

 

As indicated in the I-D, the main benefits include (but not limited to): =

 

   o  Avoid embedding an ALG in the =
middleboxes.  Note, ALGs are =
not
      recommended =
since the evolution of the service would depend on =
the
      ALG maintenance.
   =
o  Not require any Hosted NAT Traversal function (e.g., [RFC7362]) =
to
      be embedded in =
the SIP server.  Intermediate NATs and =
firewalls
      are =
transparent to the SIP service =
platform.
   o  Avoid overloading =
the network with keepalive message to =
maintain
      the mapping =
in intermediate middleboxes.
   o  =
Work without requiring symmetric RTP/RTCP [RFC4961].
  =
; o  Not require symmetric SIP to work (i.e., rport [RFC3581]).
 &nbs=
p; o  Easily support unidirectional sessions.

 

When this document was first presented in the PCP WG, I was suggested that it = is better to publish it in RAI with a review from the PCP WG. Hence, this = message to the list.

 

Cheers,

Med

------=_NextPart_000_023A_01D0530D.7A0F2EC0--