From jf.mule@cablelabs.com Mon Mar 1 04:49:37 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA4228C2EA for ; Mon, 1 Mar 2010 04:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGQybbGBD20e for ; Mon, 1 Mar 2010 04:49:36 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CD2B13A871B for ; Mon, 1 Mar 2010 04:49:36 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o21CnYHx001139; Mon, 1 Mar 2010 05:49:34 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 1 Mar 2010 05:49:35 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 1 Mar 2010 05:49:35 -0700 From: Jean-Francois Mule To: "PFAUTZ, PENN L (ATTCORP)" , "drinks@ietf.org" Date: Mon, 1 Mar 2010 05:49:33 -0700 Thread-Topic: [drinks] LUF and LRF (again) Thread-Index: AQHKsJExYF8XQFhPYESVG9kVczJAtpHL85kggAAG2XCAEQ2agA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D316FA@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 12:49:37 -0000 Penn wrote: > I think the issue is at least partly that of *distinguishing* LUF and > LRF per the Speermint model in a drinks implementation. There are use > cases in which one wants drinks to handle the LUF function and leave > the > LRF to other means and some in which the functions may be combined. I agree with you Penn. More efforts should be made in the documents to exp= lain how the users of the drinks protocols may use them for LUF-only, or LU= F+LRF. I would note that the protocol proposed for client-to-registry communicatio= ns in Stochholm has the means to distinguish these. A public identifier (sa= y a TN or MDN) gets you to a name (route group name). If that name is the = target domain, or better, if a route group can point to a domain name objec= t, then you have the LUF. If folks want to further develop the SED, the route group name can point to= other things. Isn't that sufficient to address the needs to distinguish the two (along wi= th more text and examples in the document)? Jean-Fran=E7ois From jf.mule@cablelabs.com Mon Mar 1 04:58:28 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A637B28C2F5 for ; Mon, 1 Mar 2010 04:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtKTFr-swePa for ; Mon, 1 Mar 2010 04:58:24 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7143128C2F1 for ; Mon, 1 Mar 2010 04:58:24 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o21CwNa1001659; Mon, 1 Mar 2010 05:58:24 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 1 Mar 2010 05:58:23 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 1 Mar 2010 05:58:24 -0700 From: Jean-Francois Mule To: "Ray.Bellis@nominet.org.uk" , "Cartwright, Kenneth" Date: Mon, 1 Mar 2010 05:58:21 -0700 Thread-Topic: [drinks] LUF and LRF (again) Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFgg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D316FB@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FBsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 12:58:28 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FBsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW - we are re-hashing things we have discussed before: July 2008 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.ht= ml http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html and missing to point out how the currently proposed protocol requirements o= r draft specifications fail to meet them. Can folks point out more specific changes they would like to see? Jean-Francois. Ray wrote: From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Ray.Bellis@nominet.org.uk Sent: Thursday, February 18, 2010 9:22 AM To: Cartwright, Kenneth Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) > There are cases where the LUF would > just return some identifier that represents the WHO, while not > returning the ultimate destination. That's closest to my vision for DRINKS et al. The LUF says "WHO", and in many cases "roughly WHERE". That "roughly WHERE" corresponds to the "destination group" term that I int= roduced. The LRF then turns "roughly WHERE" into "this particular ingress point". > Mapping what is happening in the real world onto these Speermint > abstractions is "interesting". It sure is, although FWIW what I've described above is pretty much the prop= osed model for the UK number portability database, should OFCOM ever decide= to mandate one. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FBsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BTW – we are re-hashing things we have discussed befor= e:

July 2008 - = http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html<= /o:p>

= http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html<= /o:p>

= http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html<= /o:p>

 

 

and missing to point out how the currently proposed protocol requirements or draft specifications fail to meet them.

 

Can folks point out more specific changes they would like to see?

 

Jean-Francois.

 

Ray wrote:

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk
Sent: Thursday, February 18, 2010 9:22 AM
To: Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: Re: [drinks] LUF and LRF (again)

 


> There are cases where the LUF would
> just return some identifier that represents the WHO, while not
> returning the ultimate destination.

That's closest to my vision for DRINKS= et al.

The LUF says "WHO", and in m= any cases "roughly WHERE".

That "roughly WHERE" corresp= onds to the "destination group" term that I introduced.
The LRF then turns "roughly WHERE= " into "this particular ingress point".

> Mapping what is happening in the real world onto these Speermint <= /tt>
> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much the = proposed model for the UK number portability database, should OFCOM ever decide to mandate one.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211

--_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FBsrvxchg_-- From jf.mule@cablelabs.com Mon Mar 1 05:27:14 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C3928C3EE for ; Mon, 1 Mar 2010 05:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCIyPlZjLOBL for ; Mon, 1 Mar 2010 05:27:08 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A4F1E28E1D5 for ; Mon, 1 Mar 2010 05:11:34 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o21DBYmi002772; Mon, 1 Mar 2010 06:11:34 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 1 Mar 2010 06:11:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 1 Mar 2010 06:11:34 -0700 From: Jean-Francois Mule To: "Ray.Bellis@nominet.org.uk" , "Cartwright, Kenneth" Date: Mon, 1 Mar 2010 06:11:32 -0700 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FCsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 13:27:14 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FCsrvxchg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be more specific, we had put a demarcation line in the data model of SPP= P between the destination group and the route group. A route group mapping = to a domain name would constitute the base for a LUF look-up. A route grou= p mapping to further object types (e.g. NAPTR or a more generic incarnation= of a NAPTR) would provide some LRF support. Do folks want more specific decoupling in the data model? One potential option is to create a domain name object that= can be mapped to a route group - LUF only Another is to put a requirement to use the route group name= (rteGrpName) as the target domain name for LUF-only provisioning Another is to create a new set of protocol operations for L= UF-only Thoughts appreciated. Jean-Fran=E7ois From: Jean-Francois Mule Sent: Monday, March 01, 2010 5:58 AM To: 'Ray.Bellis@nominet.org.uk'; Cartwright, Kenneth Cc: drinks@ietf.org Subject: RE: [drinks] LUF and LRF (again) BTW - we are re-hashing things we have discussed before: July 2008 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.ht= ml http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html and missing to point out how the currently proposed protocol requirements o= r draft specifications fail to meet them. Can folks point out more specific changes they would like to see? Jean-Francois. Ray wrote: From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Ray.Bellis@nominet.org.uk Sent: Thursday, February 18, 2010 9:22 AM To: Cartwright, Kenneth Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) > There are cases where the LUF would > just return some identifier that represents the WHO, while not > returning the ultimate destination. That's closest to my vision for DRINKS et al. The LUF says "WHO", and in many cases "roughly WHERE". That "roughly WHERE" corresponds to the "destination group" term that I int= roduced. The LRF then turns "roughly WHERE" into "this particular ingress point". > Mapping what is happening in the real world onto these Speermint > abstractions is "interesting". It sure is, although FWIW what I've described above is pretty much the prop= osed model for the UK number portability database, should OFCOM ever decide= to mandate one. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FCsrvxchg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To be more specific, we had put a demarcation line in the da= ta model of SPPP between the destination group and the route group. A route gr= oup mapping to a domain name would constitute the base for a LUF look-up. = A route group mapping to further object types (e.g. NAPTR or a more generic incarnation of a NAPTR) would provide some LRF support.

 

Do folks want more specific decoupling in the data model?

          =       One potential option is to create a domain name object that can be mapped to a route group – LUF only

          =       Another is to put a requirement to use the route group name (rteGrpName) as the tar= get domain name for LUF-only provisioning

          =       Another is to create a new set of protocol operations for LUF-only

 

Thoughts appreciated.

Jean-François

          =      

 

 

 

From: Jean-Francois= Mule
Sent: Monday, March 01, 2010 5:58 AM
To: 'Ray.Bellis@nominet.org.uk'; Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: RE: [drinks] LUF and LRF (again)

 

BTW – we are re-hashing things we have discussed befor= e:

July 2008 - = http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html<= /o:p>

= http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html<= /o:p>

= http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html<= /o:p>

 

 

and missing to point out how the currently proposed protocol requirements or draft specifications fail to meet them.

 

Can folks point out more specific changes they would like to see?

 

Jean-Francois.

 

Ray wrote:

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk
Sent: Thursday, February 18, 2010 9:22 AM
To: Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: Re: [drinks] LUF and LRF (again)

 


> There are cases where the LUF would
> just return some identifier that represents the WHO, while not
> returning the ultimate destination.

That's closest to my vision for DRINKS= et al.

The LUF says "WHO", and in m= any cases "roughly WHERE".

That "roughly WHERE" corresp= onds to the "destination group" term that I introduced.
The LRF then turns "roughly WHERE= " into "this particular ingress point".

> Mapping what is happening in the real world onto these Speermint <= /tt>
> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much the proposed model for the UK number portability database, should OFCOM ever de= cide to mandate one.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211

--_000_76AC5FEF83F1E64491446437EA81A61F7CD4D316FCsrvxchg_-- From kcartwright@tnsi.com Mon Mar 1 06:36:42 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF4C28C0EE for ; Mon, 1 Mar 2010 06:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JUvqVgVSphv for ; Mon, 1 Mar 2010 06:36:35 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 7C5973A8448 for ; Mon, 1 Mar 2010 06:36:35 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41040546; Mon, 01 Mar 2010 09:36:24 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 1 Mar 2010 09:36:24 -0500 From: "Cartwright, Kenneth" To: Jean-Francois Mule , "Ray.Bellis@nominet.org.uk" Date: Mon, 1 Mar 2010 09:36:22 -0500 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyAAAv/9MA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4TNSMAILNAwin2_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 14:36:42 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4TNSMAILNAwin2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My understanding of what the commenters are suggesting is that the LUF prov= isioning protocol not be baked in with the LRF provisioning protocol so tha= t if one wants to just implements a LUF they do not have to concern themsel= ves with the larger data model of the LRF. Now a couple subtle aspects of the LUF LRF separation that I think most hav= e not realized are: (1) Separation of the LUF and LRF from a provisioning perspective does = not also *require* separation of the LUF and LRF from a resolution perspect= ive (although it does allow it). (2) I *think* that separating the LUF and LRF from a resolution perspec= tive strongly suggests that the resolution protocol for the LRF *not* be en= um. This is of course because LUF is supposed to return an AOR such that t= he domain name portion of the AOR indicates the current organization that s= ervices the address that was looked up. And of course enum is unfortunatel= y a resolution protocol that only support TNs as lookup keys. But maybe I'= m missing something. Ken ________________________________ From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Monday, March 01, 2010 8:12 AM To: Ray.Bellis@nominet.org.uk; Cartwright, Kenneth Cc: drinks@ietf.org Subject: RE: [drinks] protocol commands to provision LUF-only data and LUF+= LRF To be more specific, we had put a demarcation line in the data model of SPP= P between the destination group and the route group. A route group mapping = to a domain name would constitute the base for a LUF look-up. A route grou= p mapping to further object types (e.g. NAPTR or a more generic incarnation= of a NAPTR) would provide some LRF support. Do folks want more specific decoupling in the data model? One potential option is to create a domain name object that= can be mapped to a route group - LUF only Another is to put a requirement to use the route group name= (rteGrpName) as the target domain name for LUF-only provisioning Another is to create a new set of protocol operations for L= UF-only Thoughts appreciated. Jean-Fran=E7ois From: Jean-Francois Mule Sent: Monday, March 01, 2010 5:58 AM To: 'Ray.Bellis@nominet.org.uk'; Cartwright, Kenneth Cc: drinks@ietf.org Subject: RE: [drinks] LUF and LRF (again) BTW - we are re-hashing things we have discussed before: July 2008 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.ht= ml http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html and missing to point out how the currently proposed protocol requirements o= r draft specifications fail to meet them. Can folks point out more specific changes they would like to see? Jean-Francois. Ray wrote: From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Ray.Bellis@nominet.org.uk Sent: Thursday, February 18, 2010 9:22 AM To: Cartwright, Kenneth Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) > There are cases where the LUF would > just return some identifier that represents the WHO, while not > returning the ultimate destination. That's closest to my vision for DRINKS et al. The LUF says "WHO", and in many cases "roughly WHERE". That "roughly WHERE" corresponds to the "destination group" term that I int= roduced. The LRF then turns "roughly WHERE" into "this particular ingress point". > Mapping what is happening in the real world onto these Speermint > abstractions is "interesting". It sure is, although FWIW what I've described above is pretty much the prop= osed model for the UK number portability database, should OFCOM ever decide= to mandate one. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4TNSMAILNAwin2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My understanding of what the commenter= s are suggesting is that the LUF provisioning protocol not be baked in with= the LRF provisioning protocol so that if one wants to just implements a LUF they do not have to= concern themselves with the larger data model of the LRF.

 

Now a couple subtle aspects of the LUF= LRF separation that I think most have not realized are:<= /font>

(1) =     Separation of the LUF and LRF from a provisioning perspective d= oes not also *require* separation of the LUF and LRF from a resolution perspective (although it d= oes allow it).

(2) =     I *think* that s= eparating the LUF and LRF from a resolution perspective strongly suggests that the resolution protocol for the LRF *not* be enum.  This is of course beca= use LUF is supposed to return an AOR such that the domain name portion of t= he AOR indicates the current organization that services the address that was looked up.  And of course enum is = unfortunately a resolution protocol that only support TNs as lookup keys.&n= bsp; But maybe I’m missing something.

Ken

 

From: Jean= -Francois Mule [mailto:jf.mule@cablelabs.com]
Sent: Monday, March 01, 2010= 8:12 AM
To: Ray.Bellis@nominet.org.u= k; Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: RE: [drinks] protoc= ol commands to provision LUF-only data and LUF+LRF

 

= To be mo= re specific, we had put a demarcation line in the data model of SPPP betwee= n the destination group and the route group. A route group mapping to a domain name would constitute the base for a LUF= look-up.  A route group mapping to further object types (e.g. NAPTR o= r a more generic incarnation of a NAPTR) would provide some LRF support.

= &nb= sp;

= Do folks= want more specific decoupling in the data model?<= /p>

=  &n= bsp;            = ;  One potential option is to create a domain name object that can be = mapped to a route group – LUF only

=  &n= bsp;            = ;  Another is to put a requirement to use the route group name (rteGrp= Name) as the target domain name for LUF-only provisioning

=  &n= bsp;            = ;  Another is to create a new set of protocol operations for LUF-only<= o:p>

= &nb= sp;

= Thoughts= appreciated.

= Jean-Fra= n=E7ois

=  &n= bsp;            = ; 

= &nb= sp;

= &nb= sp;

= &nb= sp;

From: Jean= -Francois Mule
Sent: Monday, March 01, 2010= 5:58 AM
To: 'Ray.Bellis@nominet.org.= uk'; Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: RE: [drinks] LUF an= d LRF (again)

 

= BTW R= 11; we are re-hashing things we have discussed before:

= July 200= 8 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html

= http= ://www.ietf.org/mail-archive/web/drinks/current/msg00072.html

= http= ://www.ietf.org/mail-archive/web/drinks/current/msg00109.html

= &nb= sp;

= &nb= sp;

= and miss= ing to point out how the currently proposed protocol requirements or draft = specifications fail to meet them.

= &nb= sp;

= Can folk= s point out more specific changes they would like to see?=

= &nb= sp;

= Jean-Fra= ncois.

= &nb= sp;

= Ray wrot= e:

= &nb= sp;

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ray.Bellis@nomi= net.org.uk
Sent: Thursday, February 18,= 2010 9:22 AM
To: Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: Re: [drinks] LUF an= d LRF (again)

 


> There are cases where the LUF would
> just return some identifier that repres= ents the WHO, while not
> returning the ultimate destination.

= That's closest to my vision for DRINKS et al.

= The LUF says "WHO", and in many cases "roughly WHERE".<= /span>

= That "roughly WHERE" corresponds to the "destination group&q= uot; term that I introduced.

= The LRF then turns "roughly WHERE" into "this particular ing= ress point".

> Mapping what is happening in the real w= orld onto these Speermint
> abstractions is "interesting"= .

It sure is, although FWIW what I've describe= d above is pretty much the proposed model for the UK number portability database, should OFCOM ever decide to ma= ndate one.

= Ray

= --
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nomi= net
e: ray@nominet.org.uk, t: +44 1865 33221= 1


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4TNSMAILNAwin2_-- From jf.mule@cablelabs.com Mon Mar 1 07:06:29 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C3428C35D for ; Mon, 1 Mar 2010 07:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5tGuvPPK9vp for ; Mon, 1 Mar 2010 07:06:28 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 89AEF28C2F9 for ; Mon, 1 Mar 2010 07:06:28 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o21F6Snq011776; Mon, 1 Mar 2010 08:06:28 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 1 Mar 2010 08:06:28 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 1 Mar 2010 08:06:28 -0700 From: Jean-Francois Mule To: "Cartwright, Kenneth" , "Ray.Bellis@nominet.org.uk" Date: Mon, 1 Mar 2010 08:06:25 -0700 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyAAAv/9MAABAIsA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 15:06:29 -0000 Ken wrote: > My understanding of what the commenters are suggesting is that the LUF > provisioning protocol not be baked in with the LRF provisioning > protocol so that if one wants to just implements a LUF they do not > have to concern themselves with the larger data model of the LRF. Right and this is what I meant by "demarcation" point and what I was asking= about is whether a mapping between Route Group to a target domain would su= ffice to address the comment. I do not understand what you mean by "not be baked in": to me, there could = be one provisioning protocol and based on the schema sub-set you use, you e= xercise the LUF-only provisioning, or the LUF+LRF provisioning. =20 > Now a couple subtle aspects of the LUF LRF separation that I think > most have not realized are: I'm not sure how those aspects on the resolution protocols help here. > (1) Separation of the LUF and LRF from a provisioning perspective does > not also *require* separation of the LUF and LRF from a resolution > perspective (although it does allow it). > (2) I *think* that separating the LUF and LRF from a resolution > perspective strongly suggests that the resolution protocol for the LRF > *not* be enum.=A0 This is of course because LUF is supposed to return an > AOR such that the domain name portion of the AOR indicates the current > organization that services the address that was looked up.=A0 And of > course enum is unfortunately a resolution protocol that only support > TNs as lookup keys.=A0 But maybe I'm missing something. How does this discussion influence the design here? Jean-Fran=E7ois From kcartwright@tnsi.com Mon Mar 1 07:13:04 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67403A8982 for ; Mon, 1 Mar 2010 07:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3zlQxN0OCrT for ; Mon, 1 Mar 2010 07:13:00 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id E00433A879A for ; Mon, 1 Mar 2010 07:12:59 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41041941; Mon, 01 Mar 2010 10:12:48 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 1 Mar 2010 10:12:48 -0500 From: "Cartwright, Kenneth" To: Jean-Francois Mule , "Ray.Bellis@nominet.org.uk" Date: Mon, 1 Mar 2010 10:12:46 -0500 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyAAAv/9MAABAIsAAABfnfA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D88FE2E70@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 15:13:04 -0000 (a) "not be baked in" means that they would be specified separately. (b) the tangential points I made about the separation of LUF and LRF are ju= st that, tangential. Sorry if they clouded the discussion, but I sent them= out before and garnered no responses to them. -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Monday, March 01, 2010 10:06 AM To: Cartwright, Kenneth; Ray.Bellis@nominet.org.uk Cc: drinks@ietf.org Subject: RE: [drinks] protocol commands to provision LUF-only data and LUF+= LRF Ken wrote: > My understanding of what the commenters are suggesting is that the LUF > provisioning protocol not be baked in with the LRF provisioning > protocol so that if one wants to just implements a LUF they do not > have to concern themselves with the larger data model of the LRF. Right and this is what I meant by "demarcation" point and what I was asking= about is whether a mapping between Route Group to a target domain would su= ffice to address the comment. I do not understand what you mean by "not be baked in": to me, there could = be one provisioning protocol and based on the schema sub-set you use, you e= xercise the LUF-only provisioning, or the LUF+LRF provisioning. > Now a couple subtle aspects of the LUF LRF separation that I think > most have not realized are: I'm not sure how those aspects on the resolution protocols help here. > (1) Separation of the LUF and LRF from a provisioning perspective does > not also *require* separation of the LUF and LRF from a resolution > perspective (although it does allow it). > (2) I *think* that separating the LUF and LRF from a resolution > perspective strongly suggests that the resolution protocol for the LRF > *not* be enum. This is of course because LUF is supposed to return an > AOR such that the domain name portion of the AOR indicates the current > organization that services the address that was looked up. And of > course enum is unfortunately a resolution protocol that only support > TNs as lookup keys. But maybe I'm missing something. How does this discussion influence the design here? Jean-Fran=E7ois This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jf.mule@cablelabs.com Mon Mar 1 07:32:14 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB93B28C405 for ; Mon, 1 Mar 2010 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VosM4sNhX81B for ; Mon, 1 Mar 2010 07:32:14 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 8E59328C407 for ; Mon, 1 Mar 2010 07:32:13 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o21FWD06014089; Mon, 1 Mar 2010 08:32:13 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 1 Mar 2010 08:32:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 1 Mar 2010 08:32:13 -0700 From: Jean-Francois Mule To: "Cartwright, Kenneth" , "Ray.Bellis@nominet.org.uk" Date: Mon, 1 Mar 2010 08:32:11 -0700 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyAAAv/9MAABAIsAAABfnfAAADlM0A== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D3170F@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2E70@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D88FE2E70@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 15:32:15 -0000 Ken wrote > (a) "not be baked in" means that they would be specified separately. Let's drill down on what this would mean to make sure everyone pictures thi= s and can throw in their 2 cents. Based on the registry in production today, we have examples of folks lookin= g at accommodating customers that need just LUF provisioning and customers = that require LUF+LRF provisioning (on the same registry). Use cases are: - SSP1 provisions LUF-only data in the registry. SSP1 wants to provision the registry for LUF lookup only. SSP1 prefers LRF = to its domain be done using RFC3263 because they manage their DNS and this = is how they've chosen to manage location routing. So their peers must do 32= 63 to reach them. =20 - SSP2 prefers to provision LUF+LRF data in the registry. SSP2 prefers to also put in the Registry which SBE to contact upon registry= query. They don't use 3263 (many SSPs don't for good or bad reasons), and= they prefer to manage their "call routing" or SED in one place: these TNs= go into this destination group, and this destination group maps to this ro= uting group which means that ingress route on my net. Based on the above, I think this is not a goal to define two provisioning p= rotocols, one for LUF prov and one for LUF+LRF. The goal should be to make sure that: - folks that only want to provision LUF do it without having to know about= LRF and do so with simplicity (this gets down to potentially have simplified protocol operations for LUF = prov only, kind of a mask for LUF usage) - folks that want to provision LUF+LRF do it simply too=20 (and if these folks decide to implement DNS systems to manage LRF in their = domains, then they can move from LUF+LRF provisioning to just LRF without p= rotocol changes) - registry implementers that need to support both only implement one proto= col, the syntax helps populate the registry and guide the resolution logic - OSS-BSS implementers that write clients to provision the registries can = do so for LUF-only, or LUF+LRF and can re-use their application code across= clients. Thoughts? Jean-Fran=E7ois From pp3129@att.com Mon Mar 1 12:59:33 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B59028C1BD for ; Mon, 1 Mar 2010 12:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiARCHnhVjYD for ; Mon, 1 Mar 2010 12:59:28 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id B432728C16D for ; Mon, 1 Mar 2010 12:59:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-4.tower-129.messagelabs.com!1267477167!29998192!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 22651 invoked from network); 1 Mar 2010 20:59:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Mar 2010 20:59:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o21KxHXA021711 for ; Mon, 1 Mar 2010 15:59:18 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o21KxDIN021632 for ; Mon, 1 Mar 2010 15:59:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB982.11CC75AF" Date: Mon, 1 Mar 2010 15:59:18 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0374ED50@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4D316FB@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] LUF and LRF (again) Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggABCoP+A= References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il><754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com><35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com><754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FB@srvxchg> From: "PFAUTZ, PENN L (ATTCORP)" To: "Jean-Francois Mule" , , "Cartwright,Kenneth" Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 20:59:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB982.11CC75AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In terms of rehashing, one question as I shake off the cobwebs.... =20 If a query returns NAPTR that resolves to the target SF URI, do we consider LUF and LRF to have been done? =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Jean-Francois Mule Sent: Monday, March 01, 2010 7:58 AM To: Ray.Bellis@nominet.org.uk; Cartwright,Kenneth Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) =20 BTW - we are re-hashing things we have discussed before: July 2008 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html =20 =20 and missing to point out how the currently proposed protocol requirements or draft specifications fail to meet them. =20 Can folks point out more specific changes they would like to see? =20 Jean-Francois. =20 Ray wrote: =20 From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk Sent: Thursday, February 18, 2010 9:22 AM To: Cartwright, Kenneth Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) =20 > There are cases where the LUF would=20 > just return some identifier that represents the WHO, while not=20 > returning the ultimate destination.=20 That's closest to my vision for DRINKS et al.=20 The LUF says "WHO", and in many cases "roughly WHERE".=20 That "roughly WHERE" corresponds to the "destination group" term that I introduced.=20 The LRF then turns "roughly WHERE" into "this particular ingress point". > Mapping what is happening in the real world onto these Speermint=20 > abstractions is "interesting". It sure is, although FWIW what I've described above is pretty much the proposed model for the UK number portability database, should OFCOM ever decide to mandate one.=20 Ray=20 --=20 Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 ------_=_NextPart_001_01CAB982.11CC75AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In terms of rehashing, one question as I shake off the = cobwebs….

 

If a  query returns NAPTR that resolves to the = target SF URI, do we consider LUF and LRF to have been = done?

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Jean-Francois Mule
Sent: Monday, March 01, 2010 7:58 AM
To: Ray.Bellis@nominet.org.uk; Cartwright,Kenneth
Cc: drinks@ietf.org
Subject: Re: [drinks] LUF and LRF (again)

 

BTW – we are re-hashing things we have discussed = before:

July 2008 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html

http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html

http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html

 

 

and missing to point out how the currently proposed = protocol requirements or draft specifications fail to meet = them.

 

Can folks point out more specific changes they would like = to see?

 

Jean-Francois.

 

Ray wrote:

 

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Ray.Bellis@nominet.org.uk
Sent: Thursday, February 18, 2010 9:22 AM
To: Cartwright, Kenneth
Cc: drinks@ietf.org
Subject: Re: [drinks] LUF and LRF (again)

 


> There are cases where the LUF would
> just return some identifier that represents the WHO, while not =
> returning the ultimate destination.

That's closest to my vision for = DRINKS et al.

The LUF says "WHO", and = in many cases "roughly WHERE".

That "roughly WHERE" = corresponds to the "destination group" term that I introduced. =

The LRF then turns "roughly = WHERE" into "this particular ingress point".

> Mapping what is happening in the real world onto these = Speermint
> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much = the proposed model for the UK number portability database, should OFCOM ever = decide to mandate one.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211

------_=_NextPart_001_01CAB982.11CC75AF-- From adam.uzelac@gmail.com Mon Mar 1 14:15:54 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AC928C1BE for ; Mon, 1 Mar 2010 14:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=2.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnPdLeNDcXkm for ; Mon, 1 Mar 2010 14:15:53 -0800 (PST) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id B26493A8BB4 for ; Mon, 1 Mar 2010 14:15:52 -0800 (PST) Received: by qyk33 with SMTP id 33so1806397qyk.17 for ; Mon, 01 Mar 2010 14:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fQPpk8hI/ypgUPMI83gg8NCdvM7LMUdi2/hDkm7bDCA=; b=S2YLpf/kwgn/GynlGiJzJb5J9AtKYd1lAUXZU0Eocw3rYjPim6T38ZoDiowE9CBCqn pgw4BxsWpKbYs55llQQALbukoazJMtHy+/RBD2mahKbizyGz1MOdxwREJ+jRgudAtkkp QW+Zhclysn9ffyMgU/JAwG4T5nBbEGlzLfQuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ysh0lZL23QatPq521oax0TpHfh844JxFD9t9j2vusY0jXYl4QRfH2k6/1nGdsY7b0v Qs6Ez66crpGAQB5VS5ybkEPMK0GQIv7fAmAx48ZaKuLJzD+cOx143YH/VFaIAvSUZC8X HJFvUDsUSnqJcwORaRM0otH5VmwSiNsrz6430= MIME-Version: 1.0 Received: by 10.229.221.130 with SMTP id ic2mr643148qcb.73.1267481750509; Mon, 01 Mar 2010 14:15:50 -0800 (PST) In-Reply-To: <35FE871E2B085542A35726420E29DA6B0374ED50@gaalpa1msgusr7a.ugd.att.com> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FB@srvxchg> <35FE871E2B085542A35726420E29DA6B0374ED50@gaalpa1msgusr7a.ugd.att.com> Date: Mon, 1 Mar 2010 17:15:50 -0500 Message-ID: <3d58c41e1003011415y6aac8d16wf963674b9885b03e@mail.gmail.com> From: Adam Uzelac To: "PFAUTZ, PENN L (ATTCORP)" Content-Type: multipart/alternative; boundary=0016361e7f647f9adc0480c497f4 Cc: Ray.Bellis@nominet.org.uk, drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:15:54 -0000 --0016361e7f647f9adc0480c497f4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am of the camp that the answer to this question is "YES". Which makes things confusing - Daryl addressed this in a SPEERMINT thread: http://www.ietf.org/mail-archive/web/speermint/current/msg02629.html So the query does resolve both, but doesn't have to. Shaking off the cobwebs, but exposing the dust on this one unfortunately. Adam Uzelac Global Crossing On Mon, Mar 1, 2010 at 3:59 PM, PFAUTZ, PENN L (ATTCORP) wr= ote: > In terms of rehashing, one question as I shake off the cobwebs=85. > > > > If a query returns NAPTR that resolves to the target SF URI, do we > consider LUF *and* LRF to have been done? > > > > Penn Pfautz > > AT&T Access Management > > +1-732-420-4962 > > *From:* drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] *On > Behalf Of *Jean-Francois Mule > *Sent:* Monday, March 01, 2010 7:58 AM > *To:* Ray.Bellis@nominet.org.uk; Cartwright,Kenneth > > *Cc:* drinks@ietf.org > *Subject:* Re: [drinks] LUF and LRF (again) > > > > BTW =96 we are re-hashing things we have discussed before: > > July 2008 - > http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html > > http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html > > http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html > > > > > > and missing to point out how the currently proposed protocol requirements > or draft specifications fail to meet them. > > > > Can folks point out more specific changes they would like to see? > > > > Jean-Francois. > > > > Ray wrote: > > > > *From:* drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] *On > Behalf Of *Ray.Bellis@nominet.org.uk > *Sent:* Thursday, February 18, 2010 9:22 AM > *To:* Cartwright, Kenneth > *Cc:* drinks@ietf.org > *Subject:* Re: [drinks] LUF and LRF (again) > > > > > > There are cases where the LUF would > > just return some identifier that represents the WHO, while not > > returning the ultimate destination. > > That's closest to my vision for DRINKS et al. > > The LUF says "WHO", and in many cases "roughly WHERE". > > That "roughly WHERE" corresponds to the "destination group" term that I > introduced. > > The LRF then turns "roughly WHERE" into "this particular ingress point". > > > Mapping what is happening in the real world onto these Speermint > > abstractions is "interesting". > > It sure is, although FWIW what I've described above is pretty much the > proposed model for the UK number portability database, should OFCOM ever > decide to mandate one. > > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > > --0016361e7f647f9adc0480c497f4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am of the camp that the answer to this question is "YES".=A0 Wh= ich makes things confusing - Daryl addressed this in a SPEERMINT thread:

http://www.ietf.org/mail-archive/web/speermint/current/msg02629.html<= /a>

So the query does resolve both, but doesn't have to. Shaking off the co= bwebs, but exposing the dust on this one unfortunately.


Adam Uzelac
Global Crossing

On Mon, Mar 1, 2010 at 3:= 59 PM, PFAUTZ, PENN L (ATTCORP) <pp3129@att.com> wrote:

In terms of rehashing, one question as I shake off the cobwebs=85.

=A0

If a =A0query returns NAPTR that resolves to the target SF URI, do we consider LUF and LRF to have been done?

=A0

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= drinks-bounces= @ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Jean-Francois Mule
Sent: Monday, March 01, 2010 7:58 AM
To: R= ay.Bellis@nominet.org.uk; Cartwright,Kenneth


Cc: drinks@ietf= .org
Subject: Re: [drinks] LUF and LRF (again)

=A0

BTW =96 we are re-hashing things we have discussed before:

July 2008 - http://www.ietf.org/mail-archive/web= /drinks/current/msg00023.html

http://www.ietf.org/mail-archive/web/drinks/curr= ent/msg00072.html

http://www.ietf.org/mail-archive/web/drinks/curr= ent/msg00109.html

=A0

=A0

and missing to point out how the currently proposed protocol requirements or draft specifications fail to meet them.

=A0

Can folks point out more specific changes they would like to see?

=A0

Jean-Francois.

=A0

Ray wrote:

=A0

From:= drinks-bounces= @ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk<= br> Sent: Thursday, February 18, 2010 9:22 AM
To: Cartwright, Kenneth
Cc: drinks@ietf= .org
Subject: Re: [drinks] LUF and LRF (again)

=A0


> There are cases where the LUF would
> just return some identifier that represents the WHO, while not
> returning the ultimate destination.

That's closest to my vision for DR= INKS et al.

The LUF says "WHO", and in m= any cases "roughly WHERE".

That "roughly WHERE" corresp= onds to the "destination group" term that I introduced.
The LRF then turns "roughly WHERE= " into "this particular ingress point".

> Mapping what is happening in the real world onto these Speermint <= /tt>
> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much = the proposed model for the UK number portability database, should OFCOM ever de= cide to mandate one.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.= org.uk, t: +44 1865 332211


_______________________________________________
drinks mailing list
drinks@ietf.org
= https://www.ietf.org/mailman/listinfo/drinks


--0016361e7f647f9adc0480c497f4-- From sumanth@cablelabs.com Tue Mar 2 09:45:16 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF8F28C207 for ; Tue, 2 Mar 2010 09:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-i1JyMH2I2A for ; Tue, 2 Mar 2010 09:45:16 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 000D028C205 for ; Tue, 2 Mar 2010 09:45:15 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o22HjGHR027245 for ; Tue, 2 Mar 2010 10:45:16 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Mar 2010 10:45:16 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 2 Mar 2010 10:45:16 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Tue, 2 Mar 2010 10:45:15 -0700 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyAAAv/9MAABAIsAAABfnfAAADlM0AA3Z8Fg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D31890@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2E70@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D3170F@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4D3170F@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:45:17 -0000 The two use cases and suggested approach to have a single protocol to satis= fy them makes sense to me. It should address what we have heard in terms of= flexibility, without getting wrapped around with terminology, no? If I don= 't hear any objections, I will add this to the list of use cases and requir= ements I-D. - S=20 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Jean-Francois Mule Sent: Monday, March 01, 2010 8:32 AM To: Cartwright, Kenneth; Ray.Bellis@nominet.org.uk Cc: drinks@ietf.org Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+= LRF Ken wrote > (a) "not be baked in" means that they would be specified separately. Let's drill down on what this would mean to make sure everyone pictures thi= s and can throw in their 2 cents. Based on the registry in production today, we have examples of folks lookin= g at accommodating customers that need just LUF provisioning and customers = that require LUF+LRF provisioning (on the same registry). Use cases are: - SSP1 provisions LUF-only data in the registry. SSP1 wants to provision the registry for LUF lookup only. SSP1 prefers LRF = to its domain be done using RFC3263 because they manage their DNS and this = is how they've chosen to manage location routing. So their peers must do 32= 63 to reach them. =20 - SSP2 prefers to provision LUF+LRF data in the registry. SSP2 prefers to also put in the Registry which SBE to contact upon registry= query. They don't use 3263 (many SSPs don't for good or bad reasons), and= they prefer to manage their "call routing" or SED in one place: these TNs= go into this destination group, and this destination group maps to this ro= uting group which means that ingress route on my net. Based on the above, I think this is not a goal to define two provisioning p= rotocols, one for LUF prov and one for LUF+LRF. The goal should be to make sure that: - folks that only want to provision LUF do it without having to know about= LRF and do so with simplicity (this gets down to potentially have simplifi= ed protocol operations for LUF prov only, kind of a mask for LUF usage) - folks that want to provision LUF+LRF do it simply too (and if these folk= s decide to implement DNS systems to manage LRF in their domains, then they= can move from LUF+LRF provisioning to just LRF without protocol changes) - registry implementers that need to support both only implement one proto= col, the syntax helps populate the registry and guide the resolution logic - OSS-BSS implementers that write clients to provision the registries can = do so for LUF-only, or LUF+LRF and can re-use their application code across= clients. Thoughts? Jean-Fran=E7ois _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From dschwartz@xconnect.net Wed Mar 3 05:23:36 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2083A8DC9 for ; Wed, 3 Mar 2010 05:23:36 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2oaycRCtznm for ; Wed, 3 Mar 2010 05:23:35 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 78B3E3A8DC7 for ; Wed, 3 Mar 2010 05:23:33 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 3 Mar 2010 15:23:32 +0200 From: David Schwartz To: "Ray.Bellis@nominet.org.uk" , "Cartwright, Kenneth" Date: Wed, 3 Mar 2010 15:20:41 +0200 Thread-Topic: [drinks] LUF and LRF (again) Thread-Index: AcqwtoXPhVWpvRSlSXGJ90YsTudB6gKHcznS Message-ID: <6EA53FAD386F9D46B97D49BFE148D5140603A403@ISR-JLM-MAIL1.xconnect.co.il> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 13:23:36 -0000 I still see this as a three (not two) stage process that in many cases coll= apses into one or two steps. * who - identity (e.g. AOR, SPID) * where - Target (domain) * how - Route=20 Any attempt to bypass any of these steps in the design phase will only come= back to bite us later, D. ________________________________________ From: drinks-bounces@ietf.org [drinks-bounces@ietf.org] On Behalf Of Ray.Be= llis@nominet.org.uk [Ray.Bellis@nominet.org.uk] Sent: Thursday, February 18, 2010 6:21 PM To: Cartwright, Kenneth Cc: drinks@ietf.org Subject: Re: [drinks] LUF and LRF (again) > There are cases where the LUF would > just return some identifier that represents the WHO, while not > returning the ultimate destination. That's closest to my vision for DRINKS et al. The LUF says "WHO", and in many cases "roughly WHERE". That "roughly WHERE" corresponds to the "destination group" term that I int= roduced. The LRF then turns "roughly WHERE" into "this particular ingress point". > Mapping what is happening in the real world onto these Speermint > abstractions is "interesting". It sure is, although FWIW what I've described above is pretty much the prop= osed model for the UK number portability database, should OFCOM ever decide= to mandate one. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From dschwartz@xconnect.net Wed Mar 3 05:45:15 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B6028C0DE for ; Wed, 3 Mar 2010 05:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUstRQr79yCF for ; Wed, 3 Mar 2010 05:45:14 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id F1DD928C378 for ; Wed, 3 Mar 2010 05:45:13 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 3 Mar 2010 15:45:13 +0200 From: David Schwartz To: Jean-Francois Mule , "Cartwright, Kenneth" , "Ray.Bellis@nominet.org.uk" Date: Wed, 3 Mar 2010 15:45:12 +0200 Thread-Topic: [drinks] protocol commands to provision LUF-only data and LUF+LRF Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggAABxvyAAAv/9MAABAIsAAGFxFbo= Message-ID: <6EA53FAD386F9D46B97D49BFE148D5140603A404@ISR-JLM-MAIL1.xconnect.co.il> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com>, <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 13:45:15 -0000 Why is a comment like "domain name portion of the AOR indicates the current= organization that services the address that was looked up" necessarily tru= e? Why not just treat as an identity in the context of the specified domain= without making a statement about the "servicing of the address" implying s= ome routing responsibilities? Does a Tel uri constitue an AoR? many will ar= gue - yes. I know this has been debated back and forth on many lists for so= me time and the fact that it is still unclear is related to this exact issu= e. I believe that: a. AoR does not necessarily have to have a domain b. if it does - it still does not necessarily mandate routability - rather = just specifying a relationship or context I guess an analogy to this would be shipping vs billing address. When I ide= ntify myslef on ebay with a billing address (or context not unlike a domain= associated with an AoR) - i.e. the David Schwartz living at ..., this in n= o way implies that I want you to necessarily send my package to this addres= s. D. ________________________________________ From: drinks-bounces@ietf.org [drinks-bounces@ietf.org] On Behalf Of Jean-F= rancois Mule [jf.mule@cablelabs.com] Sent: Monday, March 01, 2010 5:06 PM To: Cartwright, Kenneth; Ray.Bellis@nominet.org.uk Cc: drinks@ietf.org Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF= +LRF Ken wrote: > My understanding of what the commenters are suggesting is that the LUF > provisioning protocol not be baked in with the LRF provisioning > protocol so that if one wants to just implements a LUF they do not > have to concern themselves with the larger data model of the LRF. Right and this is what I meant by "demarcation" point and what I was asking= about is whether a mapping between Route Group to a target domain would su= ffice to address the comment. I do not understand what you mean by "not be baked in": to me, there could = be one provisioning protocol and based on the schema sub-set you use, you e= xercise the LUF-only provisioning, or the LUF+LRF provisioning. > Now a couple subtle aspects of the LUF LRF separation that I think > most have not realized are: I'm not sure how those aspects on the resolution protocols help here. > (1) Separation of the LUF and LRF from a provisioning perspective does > not also *require* separation of the LUF and LRF from a resolution > perspective (although it does allow it). > (2) I *think* that separating the LUF and LRF from a resolution > perspective strongly suggests that the resolution protocol for the LRF > *not* be enum. This is of course because LUF is supposed to return an > AOR such that the domain name portion of the AOR indicates the current > organization that services the address that was looked up. And of > course enum is unfortunately a resolution protocol that only support > TNs as lookup keys. But maybe I'm missing something. How does this discussion influence the design here? Jean-Fran=E7ois _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From lendl@nic.at Wed Mar 3 08:56:43 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A7428C148 for ; Wed, 3 Mar 2010 08:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRYdIvCjhoxV for ; Wed, 3 Mar 2010 08:56:43 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id E1B7328C111 for ; Wed, 3 Mar 2010 08:56:42 -0800 (PST) Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 9358B4C515 for ; Wed, 3 Mar 2010 17:56:42 +0100 (CET) Message-ID: <4B8E94CB.9000400@nic.at> Date: Wed, 03 Mar 2010 17:56:43 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: drinks@ietf.org References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com><35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com><754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:56:43 -0000 On 18.02.2010 17:21, Ray.Bellis@nominet.org.uk wrote: > >> There are cases where the LUF would >> just return some identifier that represents the WHO, while not >> returning the ultimate destination. > > That's closest to my vision for DRINKS et al. > > The LUF says "WHO", and in many cases "roughly WHERE". > > That "roughly WHERE" corresponds to the "destination group" term that I introduced. > > The LRF then turns "roughly WHERE" into "this particular ingress point". This LRF characterization only works if there is a direct interconnection to the network serving the destination. In the transit case, the LRF returns the ingress point of a suitable transit network. Otherwise, yes, this makes sense. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From Ray.Bellis@nominet.org.uk Wed Mar 3 09:03:05 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F6328C141; Wed, 3 Mar 2010 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzQQG6rnr4RM; Wed, 3 Mar 2010 09:03:04 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 79F9D3A87DB; Wed, 3 Mar 2010 09:03:03 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=WG0DQLsJX9kIX/Xlqa+bdX2vZa6sPgRlu0EFpVjotjA+A37jT4vUUg0e 2gJlvJJyyo3k3zIvkV1CFyY54n7WuxWWr/PyU08rKNI4qvOJ3BqXKdQ+F RmdTSYECeVbQNFO; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1267635785; x=1299171785; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[drin ks]=20LUF=20and=20LRF=20(again)|Date:=20Wed,=203=20Mar=20 2010=2017:03:02=20+0000|Message-ID:=20 |To:=20Otmar=20Lendl=20|Cc:=20drinks@ietf.o rg,=0D=0A=09drinks-bounces@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<4B8E94CB.9000400@nic.at>|References:=20< 6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xc onnect.co.il>=09<754963199212404AB8E9CFCA6C3D0CDA0D881DC6 33@TNS-MAIL-NA.win2k.corp.tnsi.com><35FE871E2B085542A3572 6420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com><75496319 9212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp .tnsi.com>=0D=0A=09=20<4B8E94CB.9000400@ nic.at>; bh=ZGCp2ItB+SP+vxghp1sgqXzt+8dlseap+4z6TkLpffQ=; b=AKIdqSvO8GWktqV5aBqDtJDc8jXaDT3aO2S1qSSDUYWhkZISGZmcjQel DTiMyuR2USRNU/Dpkvf4iJE6FpVs+WAm61ba5P7YFMdZ2KoMMdXZt/85m vvqqq6uQ7aERL9o; X-IronPort-AV: E=Sophos;i="4.49,574,1262563200"; d="scan'208";a="16721209" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Mar 2010 17:03:03 +0000 In-Reply-To: <4B8E94CB.9000400@nic.at> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com><35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com><754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <4B8E94CB.9000400@nic.at> To: Otmar Lendl MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 3 Mar 2010 17:03:02 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/03/2010 05:03:03 PM, Serialize complete at 03/03/2010 05:03:03 PM Content-Type: multipart/alternative; boundary="=_alternative 005DA9A4802576DB_=" Cc: drinks@ietf.org, drinks-bounces@ietf.org Subject: Re: [drinks] LUF and LRF (again) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:03:06 -0000 This is a multipart message in MIME format. --=_alternative 005DA9A4802576DB_= Content-Type: text/plain; charset="US-ASCII" > > The LRF then turns "roughly WHERE" into "this particular ingress point". > > This LRF characterization only works if there is a direct interconnection > to the network serving the destination. In the transit case, the LRF > returns the ingress point of a suitable transit network. > > Otherwise, yes, this makes sense. Yes, you're right. More accurately, I should have said that the LRF turns "roughly WHERE" into "the next hop". Ray --=_alternative 005DA9A4802576DB_= Content-Type: text/html; charset="US-ASCII"
> > The LRF then turns "roughly WHERE" into "this particular ingress point".
>
> This LRF characterization only works if there is a direct interconnection
> to the network serving the destination. In the transit case, the LRF
> returns the ingress point of a suitable transit network.
>
> Otherwise, yes, this makes sense.
Yes, you're right.

More accurately, I should have said that the LRF turns "roughly WHERE" into "the next hop".

Ray
--=_alternative 005DA9A4802576DB_=-- From lendl@nic.at Wed Mar 3 09:31:26 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234AD28C1A1 for ; Wed, 3 Mar 2010 09:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhcpVc1qZTiL for ; Wed, 3 Mar 2010 09:31:21 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 4F01E28C198 for ; Wed, 3 Mar 2010 09:31:16 -0800 (PST) Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 790FA4C515 for ; Wed, 3 Mar 2010 18:31:17 +0100 (CET) Message-ID: <4B8E9CE6.5010606@nic.at> Date: Wed, 03 Mar 2010 18:31:18 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: drinks@ietf.org References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il> <754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FC@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2DF4@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D3170A@srvxchg> <754963199212404AB8E9CFCA6C3D0CDA0D88FE2E70@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D3170F@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4D3170F@srvxchg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:31:26 -0000 On 01.03.2010 16:32, Jean-Francois Mule wrote: > > Let's drill down on what this would mean to make sure everyone pictures > this and can throw in their 2 cents. > > Based on the registry in production today, we have examples of folks > looking at accommodating customers that need just LUF provisioning and > customers that require LUF+LRF provisioning (on the same registry). > > Use cases are: - SSP1 provisions LUF-only data in the registry. SSP1 > wants to provision the registry for LUF lookup only. SSP1 prefers LRF to > its domain be done using RFC3263 because they manage their DNS and this > is how they've chosen to manage location routing. So their peers must do > 3263 to reach them. I think this is an important point to stress: RFC3263 is a protocol to implement the LRF. (just as basic ENUM is a simple LUF protocol) My problem with this scenario is that RFC3263 assumes a fully interconnected mesh of networks (even if used only inside a walled garden). I strongly believe that this design decision inherent in 3263 makes it unsuitable as real world LRF, except in very clearly defined special cases. It simply fails in the presence of transit. Rich got it IMHO right as he wrote "The data associated with the LRF is then presumed to be a private data exchange between bilateral transit partners [...]" on Feb 20th. In any non-trivial interconnection scenario the LRF is a full blown routing algorithm. It should be powered mainly via bi-lateral reachability/ingress-point data exchanges that can include paths to third-party destinations. Putting static LRF data in the LUF registry is a crude hack that works only within flat network structures. From a design point of view, it's like putting Ethernet MAC addresses in the DNS instead of A records. Sure, it can save one ARP lookup in certain cases, but at what loss of flexibility? /ol (see also http://lendl.priv.at/blog/2009/08/10/whats-wrong-with-speermint-and-drinks/ and draft-lendl-speermint-background-02 for my PoV on this.) -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From richard@shockey.us Thu Mar 4 09:39:19 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B90B3A8DB5 for ; Thu, 4 Mar 2010 09:39:19 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcQs7YORKSsG for ; Thu, 4 Mar 2010 09:39:18 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 4D0313A8DAE for ; Thu, 4 Mar 2010 09:39:18 -0800 (PST) Received: (qmail 23488 invoked by uid 0); 4 Mar 2010 17:39:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 4 Mar 2010 17:39:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=T36KuN9qF6MQxe64qX2+l8ENrsc/BEg3R2kq/Bi5rpyupQq8FqFjxuKm6ivneU5eFXD/hiKHRiQDWWl5Ol+pgkkJZ24i/XuBu3bn0MaTO1Wroy0D/rEzSJDLrKQ+8K1R; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NnF15-0002hl-Ue for drinks@ietf.org; Thu, 04 Mar 2010 10:39:20 -0700 From: "Richard Shockey" To: Date: Thu, 4 Mar 2010 12:39:17 -0500 Message-ID: <003a01cabbc1$9e1aa8f0$da4ffad0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7u9WT+AlpSHHfQLyh+Q7Hh1SyGgABcR7w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Subject: [drinks] FW: 77th IETF - WG Agendas X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:39:19 -0000 -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On = Behalf Of IETF Agenda Sent: Thursday, March 04, 2010 11:58 AM To: Working Group Chairs Cc: irsg@isi.edu Subject: 77th IETF - WG Agendas=20 Draft Working Group agendas are due by Wednesday, March 10 at 17:00 PT (01:00 Thursday, March 11 UTC), upload using the IETF Meeting Materials Management Tool = https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Revised Working Group agendas are due by Monday, March 15 at 17:00 PT (24:00 UTC), upload using the IETF Meeting Materials Management Tool https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Thanks, Wanda From sumanth@cablelabs.com Thu Mar 4 13:02:57 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49A03A8E6C for ; Thu, 4 Mar 2010 13:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zajFr5C67XA0 for ; Thu, 4 Mar 2010 13:02:56 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id C87963A8E66 for ; Thu, 4 Mar 2010 13:02:56 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o24L2xC1023998; Thu, 4 Mar 2010 14:02:59 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 4 Mar 2010 14:02:58 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 4 Mar 2010 14:02:58 -0700 From: Sumanth Channabasappa To: Richard Shockey , "drinks@ietf.org" Date: Thu, 4 Mar 2010 14:02:57 -0700 Thread-Topic: [drinks] FW: 77th IETF - WG Agendas Thread-Index: Acq7u9WT+AlpSHHfQLyh+Q7Hh1SyGgABcR7wAAT2FUA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D31ADB@srvxchg> References: <003a01cabbc1$9e1aa8f0$da4ffad0$@us> In-Reply-To: <003a01cabbc1$9e1aa8f0$da4ffad0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] FW: 77th IETF - WG Agendas X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 21:02:57 -0000 I'd like to request a timeslot for an update regarding the use cases and re= quirements (15 mts). I am guessing other use case contributors (e.g., David= Schwartz, Ken, Manjul, Alex) may also be interested in presenting specific= use cases.. =20 =20 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Richard Shockey Sent: Thursday, March 04, 2010 10:39 AM To: drinks@ietf.org Subject: [drinks] FW: 77th IETF - WG Agendas -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behal= f Of IETF Agenda Sent: Thursday, March 04, 2010 11:58 AM To: Working Group Chairs Cc: irsg@isi.edu Subject: 77th IETF - WG Agendas=20 Draft Working Group agendas are due by Wednesday, March 10 at 17:00 PT (01:= 00 Thursday, March 11 UTC), upload using the IETF Meeting Materials Managem= ent Tool https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Revised Working Group agendas are due by Monday, March 15 at 17:00 PT (24:0= 0 UTC), upload using the IETF Meeting Materials Management Tool https://dat= atracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Thanks, Wanda _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From jf.mule@CableLabs.com Mon Mar 8 08:40:10 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93243A69FD for ; Mon, 8 Mar 2010 08:40:10 -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=[AWL=-0.057, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eehLJ25N3stO for ; Mon, 8 Mar 2010 08:40:09 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 64C813A683E for ; Mon, 8 Mar 2010 08:40:09 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o28GeANk024017; Mon, 8 Mar 2010 09:40:11 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 8 Mar 2010 09:40:10 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 8 Mar 2010 09:40:11 -0700 From: Jean-Francois Mule To: "PFAUTZ, PENN L (ATTCORP)" , "Ray.Bellis@nominet.org.uk" , "Cartwright,Kenneth" Date: Mon, 8 Mar 2010 09:40:08 -0700 Thread-Topic: Examples of LUF-only and LUF+LRF prov operations (was RE: [drinks] LUF and LRF (again)) Thread-Index: AcqwtpAMqPGyOrCmTX6hN/3zehcfbwIhzFggABCoP+ABVwFVMA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4D31CCF@srvxchg> References: <6EA53FAD386F9D46B97D49BFE148D5140603A388@ISR-JLM-MAIL1.xconnect.co.il><754963199212404AB8E9CFCA6C3D0CDA0D881DC633@TNS-MAIL-NA.win2k.corp.tnsi.com><35FE871E2B085542A35726420E29DA6B035F86EB@gaalpa1msgusr7a.ugd.att.com><754963199212404AB8E9CFCA6C3D0CDA0D881DC766@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CD4D316FB@srvxchg> <35FE871E2B085542A35726420E29DA6B0374ED50@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B0374ED50@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" , "Ali, Syed Wasim" Subject: [drinks] Examples of LUF-only and LUF+LRF prov operations (was RE: LUF and LRF (again)) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:40:10 -0000 Pen wrote: > If a query returns NAPTR that resolves to the target SF URI, do we > consider LUF and LRF to have been done? Yes, I think so. LUF+LRF is done if the NAPTR contains the FQDN of the target SF host. We (co-authors of the proto ID, copied on this message) are putting the fol= lowing examples in the draft proto-02 that will be released today to help d= istinguish the LUF-only and LUF+LRF provisioning cases (per the mailing lis= t requests). --- folks who want LUF+LRF only operations id-12317123 20 registrantID123 registrarId0 2010-05-04T18:13:51.0Z 2010-05-04T18:13:51.0Z ...--> route_grp_1 ...--> ssp1.example.com true =3D> basically here, you add a route group that points to the target domain= and stop there. --- folks who want LUF+LRF provisioning operations id-12317123 20 registrantID123 registrarId0 2010-05-04T18:13:51.0Z 2010-05-04T18:13:51.0Z route_grp_1 ...--> ssp1.example.com true ...--> 10 100 u E2U+sip ^(.*)$ sip:\1;npdi@sbe34-ssp1.example.com; true =3D=3D> here a NAPTR is provided. The protocol will allow extensions for o= ther types of route records. Does this help "distinguishing" the two sets of use cases concretely? Do folks have concerns with this approach? Jean-Francois. > -----Original Message----- > From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] > Sent: Monday, March 01, 2010 1:59 PM > To: Jean-Francois Mule; Ray.Bellis@nominet.org.uk; > Cartwright,Kenneth > Cc: drinks@ietf.org > Subject: RE: [drinks] LUF and LRF (again) >=20 > In terms of rehashing, one question as I shake off the cobwebs.. >=20 > If a =A0query returns NAPTR that resolves to the target SF URI, do we > consider LUF and LRF to have been done? From richard@shockey.us Mon Mar 8 14:01:29 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F035B3A69D9 for ; Mon, 8 Mar 2010 14:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kq4dakLu9IU for ; Mon, 8 Mar 2010 14:01:29 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 97ED33A68E7 for ; Mon, 8 Mar 2010 14:01:28 -0800 (PST) Received: (qmail 25408 invoked by uid 0); 8 Mar 2010 22:01:32 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 8 Mar 2010 22:01:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Y2KDNoFUUONqHkCaBPS055CiYvo/x2XvwZqzq0dWNn9k42KPxMGYybzNuHk8rT5+iy+kbF1jHIMOnC5pSeEoekcR4ntMcEIxVMGSJgLZGNx9PoDPzroYLFjpVwttZYBZ; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nol12-00077q-D8 for drinks@ietf.org; Mon, 08 Mar 2010 15:01:32 -0700 From: "Richard Shockey" To: Date: Mon, 8 Mar 2010 17:01:29 -0500 Message-ID: <05e001cabf0a$e8866360$b9932a20$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_05E1_01CABEE0.FFB05B60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/CiJUyrVb4DAyTOSnN+mWGFhCMwAAMEQQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: [drinks] FW: I-D Action:draft-mule-drinks-proto-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:01:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_05E1_01CABEE0.FFB05B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 08, 2010 4:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-drinks-proto-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Peering Provisioning Protocol Author(s) : J. Mule, et al. Filename : draft-mule-drinks-proto-02.txt Pages : 49 Date : 2010-03-08 This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS, and an XML Schema Document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-drinks-proto-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_05E1_01CABEE0.FFB05B60 Content-Type: Message/External-body; name="draft-mule-drinks-proto-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mule-drinks-proto-02.txt" Content-Type: text/plain Content-ID: <2010-03-08134231.I-D@ietf.org> ------=_NextPart_000_05E1_01CABEE0.FFB05B60 Content-Type: text/plain; name="ATT01418.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01418.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_05E1_01CABEE0.FFB05B60-- From alexander.mayrhofer@nic.at Tue Mar 9 07:53:47 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050133A698B for ; Tue, 9 Mar 2010 07:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAsPlJKgimwE for ; Tue, 9 Mar 2010 07:53:46 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 847893A6996 for ; Tue, 9 Mar 2010 07:53:41 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Tue, 9 Mar 2010 16:53:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Mar 2010 16:53:47 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508F4E2B7@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for the Anaheim DRINKS meeting Thread-Index: Acq/oLR52OeCw9PBSLu8S+eVV1T1+Q== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Draft Agenda for the Anaheim DRINKS meeting X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 15:53:47 -0000 Hi, Please find the proposed Agenda for the WG meeting in Anaheim below. Please let the chairs know if you have changes to suggest. Thanks, Alex & Richard ------- DRINKS WG Agenda for the 77th IETF Meeting=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hilton Anaheim 777 Convention Way Anaheim, CA 92802 Tel: 1-714-750-4321 WEDNESDAY, March 24, 2010 0900-1015 Morning Session I, Room "Palos Verdes"=20 Data for Reachability of Inter/tra-NetworK SIP (drinks) Chairs: Richard Shockey Alexander Mayrhofer Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion: drinks@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/drinks Archive: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html 09:00 (5m) - Welcome & Administrivia (WG Chairs) 09:05 (10m) - (short) Milestone Discussion (WG Chairs lead) 09:15 (15m) - "DRINKS Use cases and Protocol Requirements" (Sumanth Channabasappa) =20 http://tools.ietf.org/wg/drinks/draft-ietf-drinks-usecases-requirements/ 09:30 (20m) - "Session Peering Provisioning Protocol" (Jean-Francois Mule) http://tools.ietf.org/id/draft-mule-drinks-proto-02.txt 09:50 (10m) - "SPPP Over SOAP and HTTP" (Ken Cartwright) =20 http://tools.ietf.org/id/draft-cartwright-drinks-sppp-over-soap-01.txt 10:00 (15m) - Open Issues & next steps discussion=20 From kcartwright@tnsi.com Wed Mar 10 09:11:01 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965E03A6BD6; Wed, 10 Mar 2010 09:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UJIrov2Ugod; Wed, 10 Mar 2010 09:10:51 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 717553A6C03; Wed, 10 Mar 2010 09:10:37 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41334725; Wed, 10 Mar 2010 12:10:30 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 10 Mar 2010 12:10:31 -0500 From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L (ATTCORP)" , "mohamed.boucadair@orange-ftgroup.com" , Dean Willis Date: Wed, 10 Mar 2010 12:10:29 -0500 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq8j+6o6c1MOz+jQyGq+55MeiM4hwCNy+vQABO7wMAAVoMlQA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D8925D533@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_" MIME-Version: 1.0 Cc: "drinks@ietf.org" , "dispatch@ietf.org" Subject: Re: [drinks] [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 17:11:02 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ...taking this discussion onto a related tangent.... These regulatory and contractual limitations on access to TN->Carrier assig= nments are one of the reasons that existing systems that currently provide = the envisioned LUF feature (query a TN to find out the responsible carrier = currently assigned to that TN, more or less) are *required* to allow the LU= F responses to vary based on the querier. Additional requirements that nec= essitate this are: (1) This TN->CarrierAssignment data set is often/usually "layered", in = the sense that the a country code's Based Number Plan TN->CarrierAssignment= s comprise the foundation layer, that is then overlaid by (but not co-mingl= ed with) number portability TN->CarrierAssignmens, that is then overlaid by= (but not comingled with) TN->CarrierAssignments for TNs that are leased ac= ross carriers, that is then overlaid by TN->CarrierAssignments for TNs that= override any of the proceeding for any number of business or operational r= easons (although this last overlay is less structured and less relevant to = the overall point). (2) Regulatory, contractual, and business reasons currently determine, = for each country code, the layers and subsets of layers of TN->CarrierAssig= nments that any given querier is allowed to "see". (3) Some queriers simply do not want to see certain layers of TN->Carri= erAssignemnts for given country codes. (4) Because many country codes do not have a regulatory or any well def= ined source for TN->CarrierAssignments, the data is sourced from multiple p= arties. So even within a given country code, only portions of a given laye= r may be allowed to be seen by some queriers. So one way of looking at the problem space of the LUF is that the above req= uirements are not what we want to solve and standardize. What we want to s= olve and standardize is the much simpler and pristine end goal of ... all T= N->CarrierAssignment information is queriable by any organization and all t= hose organizations have legal access to all of it. We solve and standardiz= e this with the view of "build it and they will come". The other way of looking at the problem is that we solve the requirements s= tated above. Ken ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of PFAUTZ, PENN L (ATTCORP) Sent: Monday, March 08, 2010 6:27 PM To: mohamed.boucadair@orange-ftgroup.com; Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alter= native? Just a word of caution re number portability. In some countries access to t= his data is restricted to legally qualified carriers. Will ITADs always co= rrespond to such entities? Looking at the IANA list so far that's not my im= pression. You may find that the entities that do have access to NP database= s may not be the ones interested in a TRIP-like mechanism and vice versa. Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of mohamed.boucadair@orange-ftgroup.com Sent: Monday, March 08, 2010 9:33 AM To: Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alter= native? Dear Dean, all, Please see inline. Cheers, Med ________________________________ De : Dean Willis [mailto:dean.willis@softarmor.com] Envoy=E9 : vendredi 5 mars 2010 19:16 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Daryl Malas; dispatch@ietf.org Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event altern= ative? On Mar 5, 2010, at 1:38 AM, > > wrote: Dear Dean, all, In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interc= onnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_challeng= es_of_IP_telephony_Eurescom_study_P1853.asp I'm having a hard time resolving this link, as it appears to be 404. Perhap= s there's a typo? With respect to: 21. Extended TRIP protocol is suggested to be used as base for IP Telephony= routing; We've heard here that TRIP, as currently modeled, doesn't work due to the L= NP problem. What sorts of extensions id you have in mind? Were they intende= d to address this problem? [Med] An alternative would be to use TRIP in conjunction with a the current= Number Portability infrastructure as used in PSTN infrastructure for placi= ng inter-ITAD calls (this means that the owner domain will always advertise= its aggregate in TRIP, but a NPDB (Network Portability Database) should qu= estioned first). Examples of extensions to TRIP (or whatever dynamic telephony routing) woul= d be: - Avoid AS (Autonomous System) spiral: the media traffic can cross the same= AS several times - Ability to maintain multiple inter-ITAD paths - Ability to enforce some advanced TE such as: Avoid that my VoIP traffic t= o cross a given AS domain (TRIP only maintain an ITAD list) - Ability to avoid congestionned links - etc. BTW, TRIP is only considered as starting point, this does not preclude to i= nvestigate any new solution to meet the recommendations we identified. BTW,= In the recommendations list we have identified the need to encourage aggre= gation-based models. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

…taking this discussion onto a r= elated tangent….

 

These regulatory and contractual limit= ations on access to TN->Carrier assignments are one of the reasons that = existing systems that currently provide the envisioned LUF feature (query a TN to find out the responsible= carrier currently assigned to that TN, more or less) are *required* to allow the LUF responses to va= ry based on the querier.  Additional requirements that necessitate this are:

 

(1) =     This TN->CarrierAssignment data set is often/usually “= layered”, in the sense that the a country code’s Based Number Plan TN->CarrierAssignments comprise the foundation layer, that = is then overlaid by (but not co-mingled with) number portability TN->Car= rierAssignmens, that is then overlaid by (but not comingled with) TN->Ca= rrierAssignments for TNs that are leased across carriers, that is then overlaid by TN->CarrierAssignments for TN= s that override any of the proceeding for any number of business or operati= onal reasons (although this last overlay is less structured and less releva= nt to the overall point).

(2) =     Regulatory, contractual, and business reasons currently determi= ne, for each country code, the layers and subsets of layers of TN->CarrierAssignments that any given querier is allowed t= o “see”.

(3) =     Some queriers simply do not want to see certain layers of TN-&g= t;CarrierAssignemnts for given country codes.

(4) =     Because many country codes do not have a regulatory or any well= defined source for TN->CarrierAssignments, the data is sourced from multiple parties.  So even within a given countr= y code, only portions of a given layer may be allowed to be seen by some qu= eriers.

 

So one way of looking at the problem s= pace of the LUF is that the above requirements are not what we want to solv= e and standardize.  What we want to solve and standardize is the much simpler and pristine end= goal of … all TN->CarrierAssignment information is queriable by a= ny organization and all those organizations have legal access to all of it.=   We solve and standardize this with the view of “build it and they will come”.

 

The other way of looking at the proble= m is that we solve the requirements stated above.<= /p>

 

Ken

 

From: disp= atch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L = (ATTCORP)
Sent: Monday, March 08, 2010= 6:27 PM
To: mohamed.boucadair@orange= -ftgroup.com; Dean Willis
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Why = are we TRIPped out? Is there an sip-event alternative?

 

= Just a w= ord of caution re number portability. In some countries access to this data= is restricted to legally qualified carriers.  Will ITADs always correspond to such entities? Looking at the IANA list so= far that’s not my impression. You may find that the entities that do= have access to NP databases may not be the ones interested in a TRIP-like = mechanism and vice versa.

= &nb= sp;

Penn Pfautz<= /span>

AT&T Acc= ess Management

+1-732-4= 20-4962

From: disp= atch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.boucada= ir@orange-ftgroup.com
Sent: Monday, March 08, 2010= 9:33 AM
To: Dean Willis
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Why = are we TRIPped out? Is there an sip-event alternative?

 

 

Dear Dean, all,

 

Please see inline.

Cheers,

Med

 

De : Dean Willis [mailto:dean.willis@softarmor.com]
Envoy=E9 : vendredi 5 m= ars 2010 19:16
=C0 : BOUCADAIR Mohamed= NCPI/NAD/TIP
Cc : Daryl Malas; dispa= tch@ietf.org
Objet : Re: [dispatch] = Why are we TRIPped out? Is there an sip-event alternative?

 

 


Dear Dean, all,

In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of= _IP_telephony_Eurescom_study_P1853.asp).

I'm having a hard time resolving this link, as it appears to be 404= . Perhaps there's a typo?

 

With respect to:

 

 

21. Extended TRIP protocol is suggested to be used as base for IP Teleph= ony routing;

 

We've heard here that TRIP, as currently modeled, doesn't work due = to the LNP problem. What sorts of extensions id you have in mind? Were they= intended to address this problem?

[Med] An alternative would be to use TRIP in conjunction wi= th a the current Number Portability infrastructure as used in&nbs= p;PSTN infrastructure for placing inter-ITAD calls (this means tha= t the owner domain will always advertise its aggregate in TRIP, but a = NPDB (Network Portability Database) should questioned first). <= /font>

 

Examples of extensions to TRIP (or whatever dynamic telephony routing= ) would be:

- Avoid AS (Autonomous System) spiral: the media traffic can cross th= e same AS several times

- Ability to maintain multiple inter-ITAD paths

- Ability to enforce some advanced TE such as: Avoid that my VoIP tra= ffic to cross a given AS domain (TRIP only maintain an ITAD list)

- Ability to avoid congestionned links

- etc.

 

BTW, TRIP is only considered as starting point, this does not preclud= e to investigate any new solution to meet the recommendations we identified. BTW, In the recommendations list we have identified the nee= d to encourage aggregation-based models.

 

*********************************
This message and any attachments (the "message") are confidentia=
l and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, chang=
ed or falsified.
If you are not the intended addressee of this message, please cancel it im=
mediately and inform the sender.
********************************

This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_-- From root@core3.amsl.com Mon Mar 8 10:15:02 2010 Return-Path: X-Original-To: drinks@ietf.org Delivered-To: drinks@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B120C3A69B3; Mon, 8 Mar 2010 10:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308181502.B120C3A69B3@core3.amsl.com> Date: Mon, 8 Mar 2010 10:15:02 -0800 (PST) X-Mailman-Approved-At: Thu, 11 Mar 2010 08:26:11 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action:draft-ietf-drinks-usecases-requirements-01.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF. Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-ietf-drinks-usecases-requirements-01.txt Pages : 23 Date : 2010-03-08 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-usecases-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-drinks-usecases-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08100907.I-D@ietf.org> --NextPart-- From pp3129@att.com Mon Mar 15 11:17:07 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C223A6900 for ; Mon, 15 Mar 2010 11:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.665 X-Spam-Level: X-Spam-Status: No, score=-106.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLkJicd5aNM7 for ; Mon, 15 Mar 2010 11:17:05 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id B6B6C3A69C4 for ; Mon, 15 Mar 2010 11:16:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-13.tower-167.messagelabs.com!1268677006!28680445!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 18805 invoked from network); 15 Mar 2010 18:16:46 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2010 18:16:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2FIGXuU014988 for ; Mon, 15 Mar 2010 14:16:35 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2FIGUsK014962 for ; Mon, 15 Mar 2010 14:16:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Mar 2010 14:16:40 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B0389A608@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <20100308181502.B120C3A69B3@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] I-D Action:draft-ietf-drinks-usecases-requirements-01.txt Thread-Index: AcrBN5mvDRiwhjqBQgKB/gwQvcELzADMA9rA References: <20100308181502.B120C3A69B3@core3.amsl.com> From: "PFAUTZ, PENN L (ATTCORP)" To: Subject: Re: [drinks] I-D Action:draft-ietf-drinks-usecases-requirements-01.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 18:17:07 -0000 Since I won't make it to Anaheim a couple of comments/questions re the use case draft: 1. re UC ROUTING #2. Am I right that there's nothing special about the geographic example here? DGs could just as well be assigned on, say, the basis of assigning special ingress routes to TNs with special functionality, e.g. video capability. In the example DGs just happen to be a proxy for regions. 2. re UC ROUTING #5. I presume the base case of direct non-selective inter-network peering is just a degenerate form of this case. 3. re UC ROUTING #6. Again, just applying the general recipient group capability to the egress route problem, right? Here I would expect the data only goes to the originating SSP's LDR. This is an alternative to the approach in draft-malas-dispatch-sip-egress-route which draft melds the egress and ingress info into one record. 4. re UC ROUTING #7: Does this include returning a NAPTR with the terminating SBE? DNS resolution of the hostname may still be required. 5. re FREQ #10: I assume this case applies only where the Registry being provisioned is one that handles traffic on a query basis as opposed to bulk download to an originating SSP LDR. (To me it wouldn't make sense to expect an originating SSP to apply the source selection logic defined by a terminating SSP) Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 08, 2010 1:15 PM To: i-d-announce@ietf.org Cc: drinks@ietf.org Subject: [drinks] I-D Action:draft-ietf-drinks-usecases-requirements-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF. Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-ietf-drinks-usecases-requirements-01.txt Pages : 23 Date : 2010-03-08 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-usecases-requireme nts-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From jf.mule@cablelabs.com Mon Mar 22 10:50:40 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3304E3A699F for ; Mon, 22 Mar 2010 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.575 X-Spam-Level: * X-Spam-Status: No, score=1.575 tagged_above=-999 required=5 tests=[AWL=-1.692, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwmpX40B8eOf for ; Mon, 22 Mar 2010 10:50:39 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 6EE5E3A696E for ; Mon, 22 Mar 2010 10:50:39 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2MHot1c006257; Mon, 22 Mar 2010 11:50:55 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 22 Mar 2010 11:50:55 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 22 Mar 2010 11:50:55 -0600 From: Jean-Francois Mule To: "drinks@ietf.org" Date: Mon, 22 Mar 2010 11:50:37 -0600 Thread-Topic: Proposal for an interim meeting in first half of May Thread-Index: AcrJ6C5G+cQFGAM/T+KQnCR3wjd4fg== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4E30C72@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {242A995C-1398-4670-93C5-01BEDB91BDC3} x-cr-hashedpuzzle: B5wp EZ9Y FGko GG0T NzXR PNvP PbNr QGpZ ka4l o+Tp p6zK vdUm x+DM 5RID 59NW 9cVE; 6; YQBsAGUAeABhAG4AZABlAHIALgBtAGEAeQByAGgAbwBmAGUAcgBAAG4AaQBjAC4AYQB0ADsAZAByAGkAbgBrAHMALQBjAGgAYQBpAHIAcwBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AGQAcgBpAG4AawBzAEAAaQBlAHQAZgAuAG8AcgBnADsAawBjAGEAcgB0AHcAcgBpAGcAaAB0AEAAdABuAHMAaQAuAGMAbwBtADsAbQBtAGEAaABhAHIAaQBzAGgAaQBAAHQAbgBzAGkALgBjAG8AbQA7AHMAeQBlAGQALgBhAGwAaQBAAG4AZQB1AHMAdABhAHIALgBiAGkAegA=; Sosha1_v1; 7; {242A995C-1398-4670-93C5-01BEDB91BDC3}; agBmAC4AbQB1AGwAZQBAAGMAYQBiAGwAZQBsAGEAYgBzAC4AYwBvAG0A; Mon, 22 Mar 2010 17:50:37 GMT; UAByAG8AcABvAHMAYQBsACAAZgBvAHIAIABhAG4AIABpAG4AdABlAHIAaQBtACAAbQBlAGUAdABpAG4AZwAgAGkAbgAgAGYAaQByAHMAdAAgAGgAYQBsAGYAIABvAGYAIABNAGEAeQA= acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "drinks-chairs@tools.ietf.org" , Syed Ali Subject: [drinks] Proposal for an interim meeting in first half of May X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 17:50:40 -0000 All, The design team copied on this message thinks we should meet shortly afte= r the IETF face-to-face to advance open issues and release updated IDs. We= did let the wg chairs know about this but wanted to get this out on the li= st. We would like to propose an interim drinks WG meeting on the US East Coas= t in the first half of May (and following IETF rules, 30 days after it is a= nnounced to the list). TNS has offered to host the meeting near Reston, VA= . For the folks who are interested, please: - reply to me and copy the folks on the cc: list=20 - indicate if there are days from May 3-14 that you absolutely canno= t make such a meeting Thanks, Jean-Francois. =20 From richard@shockey.us Mon Mar 22 16:20:35 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566D028C229 for ; Mon, 22 Mar 2010 16:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9KaC7eQcHav for ; Mon, 22 Mar 2010 16:20:27 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 1FC1628C1C4 for ; Mon, 22 Mar 2010 16:20:19 -0700 (PDT) Received: (qmail 6057 invoked by uid 0); 22 Mar 2010 22:20:30 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 22 Mar 2010 22:20:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=AUJ5GI3IatKCeR0t9w9cAuDbFFAM3Lt4FLJofq0DoEVw5s/3UIWLQNxsnEqqMkSnB3LKw00MgVYjPQYpSlzJxZ5fHjBS0+sgCUdnojTIvF7zLBXfkPBcXTSInA9sMj9u; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ntqv7-0004gv-C0; Mon, 22 Mar 2010 17:20:29 -0600 From: "Richard Shockey" To: "'Jean-Francois Mule'" , References: <76AC5FEF83F1E64491446437EA81A61F7CD4E30C72@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4E30C72@srvxchg> Date: Mon, 22 Mar 2010 19:20:23 -0400 Message-ID: <002301caca16$41390e70$c3ab2b50$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJ6C5G+cQFGAM/T+KQnCR3wjd4fgALfFEA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: drinks-chairs@tools.ietf.org, 'Syed Ali' Subject: Re: [drinks] Proposal for an interim meeting in first half of May X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 23:20:36 -0000 The 10th through the 13 is blocked for me for a conference in Boston. -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Monday, March 22, 2010 1:51 PM To: drinks@ietf.org Cc: Sumanth Channabasappa; Alexander Mayrhofer; Cartwright, Kenneth; Maharishi, Manjul; Syed Ali; drinks-chairs@tools.ietf.org Subject: Proposal for an interim meeting in first half of May All, The design team copied on this message thinks we should meet shortly after the IETF face-to-face to advance open issues and release updated IDs. We did let the wg chairs know about this but wanted to get this out on the list. We would like to propose an interim drinks WG meeting on the US East Coast in the first half of May (and following IETF rules, 30 days after it is announced to the list). TNS has offered to host the meeting near Reston, VA. For the folks who are interested, please: - reply to me and copy the folks on the cc: list - indicate if there are days from May 3-14 that you absolutely cannot make such a meeting Thanks, Jean-Francois. From jf.mule@cablelabs.com Tue Mar 23 06:29:15 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F6D3A6B3B for ; Tue, 23 Mar 2010 06:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.267 X-Spam-Level: *** X-Spam-Status: No, score=3.267 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT-Eob25aFes for ; Tue, 23 Mar 2010 06:29:14 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 60D793A6BB1 for ; Tue, 23 Mar 2010 06:28:40 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2NDSwHq010567 for ; Tue, 23 Mar 2010 07:28:58 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 23 Mar 2010 07:28:58 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 23 Mar 2010 07:28:59 -0600 From: Jean-Francois Mule To: "drinks@ietf.org" Date: Tue, 23 Mar 2010 07:28:57 -0600 Thread-Topic: ad-hoc design team meeting today 3/23 in Lido B @ 5:30pm Thread-Index: AcrKjMqtIhXm7STaSxCKKluunvylSA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4E30D57@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] ad-hoc design team meeting today 3/23 in Lido B @ 5:30pm X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 13:29:15 -0000 We will meet in Lido B at 5:30pm today to advance some open issues on use c= ases, requirements and the protocol documents. Anyone is welcome to join us. Jean-Francois. From alexander.mayrhofer@nic.at Tue Mar 23 10:12:39 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E3A3A6C45 for ; Tue, 23 Mar 2010 10:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62iJBBrkln-z for ; Tue, 23 Mar 2010 10:12:37 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 9EDC63A6C8B for ; Tue, 23 Mar 2010 10:12:02 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Tue, 23 Mar 2010 18:12:19 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Mar 2010 18:12:18 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508F4EF73@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRINKS WG session: starts Wed 0900 instead of 1015 Thread-Index: AcrKq/4H5OweW6WgST6DOiwaK8e7Vw== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] DRINKS WG session: starts Wed 0900 instead of 1015 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:12:39 -0000 If you plan to attend the DRINKS WG session: Note that we have been assigned the full Wed morning slot, contrary to the initial scheduling (which had only the second half of the morning). Therefore, the meeting will start at 0900, not at 1015. An updated WG meeting agenda will be posted soon. That also means we will have ample open mic time for discussions. Alex From alexander.mayrhofer@nic.at Tue Mar 23 17:16:56 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468553A694C for ; Tue, 23 Mar 2010 17:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoQzdep5a9AQ for ; Tue, 23 Mar 2010 17:16:55 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id B6B0D3A68C0 for ; Tue, 23 Mar 2010 17:16:53 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Wed, 24 Mar 2010 01:17:11 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Mar 2010 01:17:08 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508F4EF7A@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda updated Thread-Index: AcrK51dtY2eseFbAQpevzB1V+vrsoQ== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Agenda updated X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 00:16:56 -0000 All, I have just uploaded an updated agenda, reflecting that we have now a 2.5h slot available. I have simply stretched each of the slots - if we finish earlier with one of the slots, we have more open mic time: http://tools.ietf.org/wg/drinks/agenda?item=3Dagenda77.html Alex From alexander.mayrhofer@nic.at Tue Mar 23 17:27:20 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1B83A6D10 for ; Tue, 23 Mar 2010 17:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.65 X-Spam-Level: X-Spam-Status: No, score=-7.65 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1lXK4ddBd-c for ; Tue, 23 Mar 2010 17:27:19 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id ED7793A6D7F for ; Tue, 23 Mar 2010 17:19:10 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Wed, 24 Mar 2010 01:19:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Mar 2010 01:19:26 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508F4EF7B@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D466508F4EF7A@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Agenda updated Thread-Index: AcrK51dtY2eseFbAQpevzB1V+vrsoQAACt0w References: <8BC845943058D844ABFC73D2220D466508F4EF7A@nics-mail.sbg.nic.at> From: "Alexander Mayrhofer" To: "Alexander Mayrhofer" , X-XWALL-BCKS: auto Subject: Re: [drinks] Agenda updated X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 00:27:20 -0000 [correction, sorry] > http://tools.ietf.org/wg/drinks/agenda?item=3Dagenda77.html The tools site doesn't seem to have synced yet with the materials upload site - the correct URL for the new agenda is: http://www.ietf.org/proceedings/10mar/agenda/drinks.txt Alex From richard@shockey.us Tue Mar 23 19:05:35 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760CE3A6969 for ; Tue, 23 Mar 2010 19:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dp5MzMUlmun for ; Tue, 23 Mar 2010 19:05:34 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 911933A63D3 for ; Tue, 23 Mar 2010 19:05:34 -0700 (PDT) Received: (qmail 3787 invoked by uid 0); 24 Mar 2010 01:05:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 24 Mar 2010 01:05:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=FOYse7ZD9kfN3sgIIumtNGiRCzvV3yLJlFM/WC1BQK3NBZXiJmWVVmjFU76esoRMUkliS3SBiC4rRQHjtTxjTFM3m4l5ArE+gJEhgm08JwUvDPSephZ2F8H0UtNJ97au; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuFyl-0003hC-D1 for drinks@ietf.org; Tue, 23 Mar 2010 20:05:55 -0600 From: "Richard Shockey" To: Date: Tue, 23 Mar 2010 22:05:50 -0400 Message-ID: <000701cacaf6$876cf1f0$9646d5d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrK825OptV8mgMiTISukrB0MCNLTAAAQPsQAABueJA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Subject: [drinks] Requirements for DRINKS to accomodiate ITU SIPD X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:05:35 -0000 Just a reminder because this came up again on the E2MD list. -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Tuesday, March 23, 2010 9:59 PM To: 'trutkowski@netmagic.com' Cc: 'Dean Willis'; 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF discussion list' Subject: RE: [e2md] We need another acronym besides SPID for service provider ID It's my understanding that SG2 has a separate task underway that Gary Richenaker is leading on the Global SPID. The IETF DRINKS WG received a formal liaison from ITU-T requesting that the DRINKS protocol accommodate such as identifier. It is my working assumption that E2MD should explicit accommodate this request as well. https://datatracker.ietf.org/liaison/518/ -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com] Sent: Tuesday, March 23, 2010 9:43 PM To: Richard Shockey Cc: 'Dean Willis'; 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] We need another acronym besides SPID for service provider ID On 3/23/2010 9:14 PM, Richard Shockey wrote: > In the US its SPID but we would also have to reserve the ITU type currently > under development as well Service Provider Network Identifier (SPN) > > What ITU-T type currently under development? The ITU-T's IdM group recommended that the IETF's Enterprise Numbers be used for a SPID, and that consideration be given to binding them to EVcerts. --tony From trutkowski@netmagic.com Tue Mar 23 19:10:59 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D543A6952 for ; Tue, 23 Mar 2010 19:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esNfDKm4MViu for ; Tue, 23 Mar 2010 19:10:58 -0700 (PDT) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 746713A68D0 for ; Tue, 23 Mar 2010 19:10:58 -0700 (PDT) Received: from [192.168.0.173] ([unknown] [173.72.150.224]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZR00EEAKQSNV49@vms173011.mailsrvcs.net> for drinks@ietf.org; Tue, 23 Mar 2010 21:11:17 -0500 (CDT) Message-id: <4BA974C4.8070705@netmagic.com> Date: Tue, 23 Mar 2010 22:11:16 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-version: 1.0 To: Richard Shockey References: <000701cacaf6$876cf1f0$9646d5d0$@us> In-reply-to: <000701cacaf6$876cf1f0$9646d5d0$@us> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: drinks@ietf.org Subject: Re: [drinks] Requirements for DRINKS to accomodiate ITU SIPD X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:10:59 -0000 Hi Richard, > Just a reminder because this came up again on the E2MD list. > to which the reply was: > > Hi Richard, > > It's my understanding that SG2 has a separate task underway that Gary > > Richenaker is leading on the Global SPID. The IETF DRINKS WG received a > > formal liaison from ITU-T requesting that the DRINKS protocol accommodate > > such as identifier. > > > Actually NeuStar made the proposal out of the blue. > Gary as you know works for NeuStar. The proposal > had many significant flaws and received no apparent > support at the meeting (or anywhere else). Other > ITU-T Study Groups had suggested that IETF > Enterprise Numbers be used as they were the > predominant SPID in use, but needed a better > trust mechanism. A SG2 correspondence group > was formed to further consider it, but thus > far there has been no activity. I think you can > consider the effort dead. > > --tony > _______________________________________________ From alexander.mayrhofer@nic.at Fri Mar 26 09:44:15 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA873A684B for ; Fri, 26 Mar 2010 09:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApfgfsGZRkOr for ; Fri, 26 Mar 2010 09:44:15 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 96F403A6B13 for ; Fri, 26 Mar 2010 09:43:04 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Fri, 26 Mar 2010 17:43:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Mar 2010 17:43:26 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508FC894D@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scheduling the Interim. Thread-Index: AcrNA3UVFuPCbyXqQFCaOdab2NEI0A== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Scheduling the Interim. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:44:15 -0000 As mentioned in the WG session, we would like to hold an Interim Meeting between IETF 77 and IETF 78.=20 The meeting will run one day long, and we have identified three potential dates. Please indicate which of those dates fits for you here: http://doodle.com/7z44ztd4eea7i2c5 (please pick *all* possible dates - this makes scheduling much easier). We need to get scheduling done within the next few days, so a timely response is appreciated. Thanks, Alex From alexander.mayrhofer@nic.at Tue Mar 30 07:50:05 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9CA3A6BE3 for ; Tue, 30 Mar 2010 07:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwKcawp90r8V for ; Tue, 30 Mar 2010 07:50:04 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id E5A933A6BDA for ; Tue, 30 Mar 2010 07:46:53 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Tue, 30 Mar 2010 16:47:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Mar 2010 16:47:23 +0200 Message-ID: <8BC845943058D844ABFC73D2220D466508FC8C5B@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder - interim meeting scheduling Thread-Index: AcrQF+h2nIemeXL7T7i/445LRyiv4w== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Reminder - interim meeting scheduling X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:50:05 -0000 Hello, If you haven't yet indicated your preference for the date of the Interim meeting, please do so asap at: http://doodle.com/7z44ztd4eea7i2c5 Thanks, Alex