From jcronin@egh.com Tue Jun 30 10:22:01 2009 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 48C5D3A6E84 for ; Tue, 30 Jun 2009 10:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] 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 8p75NGQwrM8b for ; Tue, 30 Jun 2009 10:22:00 -0700 (PDT) Received: from mia.egh.com (static-72-93-100-146.bstnma.fios.verizon.net [72.93.100.146]) by core3.amsl.com (Postfix) with ESMTP id 527803A6CF1 for ; Tue, 30 Jun 2009 10:21:59 -0700 (PDT) Received: from Jojo.egh.com (Jojo.egh.com [198.179.132.13]) by mia.egh.com (8.13.6+Sun/8.13.6) with ESMTP id n5UHLGWD027234 for ; Tue, 30 Jun 2009 13:21:18 -0400 (EDT) Message-Id: <5CB90290-036B-47CF-BB44-6FF3E21D403B@egh.com> From: Jonathan Cronin To: IETF DRINKS WG In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 13:21:11 -0400 References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Thu, 02 Jul 2009 08:44:28 -0700 Subject: Re: [drinks] WG poll on transport protocol 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 Jun 2009 17:26:47 -0000 1. How many folks have SOAP implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? Not sure as to the kind of protocol, but we definitely use SOAP. 2. How many folks have a REST-like implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? No, although we aim towards some REST-like principles in our use of SOAP. 3. In general what data model or protocol properties do your organizations ultimately lean towards - SOAP vs. REST? Other? As others have said, SOAP is here, but REST has a lot of virtues, We do SOAP, (because our customers do) but would be happy with REST if our customers want it. 4. What are the specific applications that SSP are looking for DRINKS to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ? No opinion... Questions to reach WG concensus on: 3. Do you agree that the design team should define the architecture data model independently from the definition of a potential transport protocol? (as far as possible) Absolutely; data models outlive transports; otherwise we will at some point find ourselves building tunnels to carry the old transport over the new transport. 4. Given the goal to define the data model outside its transport, do you prefer the group to: A. Define a SOAP based transport protocol and if anyone is interested they can work on a RESTful version? Yes. If the SOAP based one is (I hate this expression :) ) RESTful in architecture, the REST version should be relatively easy. And bearing REST in mind for the SOAP definition should bend it in a simpler, cleaner direction. (Which is not to say the WG wouldn't come up with a clean design regardless; I've just seen SOAP definitions that could have used some REST.) B. The WG try and do both? No. (Kenneth Cartwright's response to the survey pretty much corresponds to my opinion, with useful detail.) Jonathan Cronin EGH, Inc. From br@brianrosen.net Thu Jul 2 09:05:49 2009 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 0844A3A6B86 for ; Thu, 2 Jul 2009 09:05:49 -0700 (PDT) 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 vRlASGNgGodc for ; Thu, 2 Jul 2009 09:05:46 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A957228C234 for ; Thu, 2 Jul 2009 09:03:56 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMOlZ-000842-II; Thu, 02 Jul 2009 11:04:05 -0500 From: "Brian Rosen" To: "'Alexander Mayrhofer'" , "'IETF DRINKS WG'" References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> Date: Thu, 2 Jul 2009 12:04:11 -0400 Message-ID: <018a01c9fb2e$beb489e0$3c1d9da0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn2Yh8jnu04p0/PR3Wwi5SjbfhmhQEzEaLw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [drinks] WG poll on transport protocol 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, 02 Jul 2009 16:05:49 -0000 Our OSS-BSS products use SOAP. We don't currently use REST, although we try to adhere to some of the RESTful principals. Our customers seem to use SOAP. We have never, to my knowledge, had a request to support a straight REST/no SOAP interface. No one seems to have any problems with the overhead. Brian > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Alexander Mayrhofer > Sent: Friday, June 26, 2009 9:29 AM > To: IETF DRINKS WG > Subject: [drinks] WG poll on transport protocol > > > All, > > The chairs would like to seek some input from the list on the practical > options the WG now needs to confront on what is the most appropriate, > but > more importantly, what is also most deployable transport protocol for > DRINKS. > > The protocol design team has made good progress towards a first draft > of the DRINKS protocol, and the issue of which transport protocol to > proceed with was discussed during several conference calls. > > The chairs wish to formally reach concensus on how the group > should proceed regarding that protocol transport issue. > > Discussions during our face to face meetings have indicated that > a SOAP/XML based approach would fit most of the various vendors > and service providers that would potentially deploy a DRINKS protocol. > > http://en.wikipedia.org/wiki/SOAP > > The design team been advised that it might also be useful to look at > REST-like > protocols as REST design principles for WEB protocols overcome many of > the > known limitations and interoperability problems associated with SOAP. > > There are arguments that a RESTful Web Services approach for a DRINKS > protocol from a provisioning would not only be appropriate for a Client > 2 > Server but also Server 2 Server approaches as well. > > It should be understood that REST is not a protocol but a series of > design > principals. > > http://en.wikipedia.org/wiki/REST > > The central counter argument is that SOAP is the most universally > deployed > data exchange mechanism out there and that anecdotal evidence indicates > that > SOAP is the predominant form of transport mechanism in current use > among > SSP's and will be for the foreseeable future. > > The design team has currently concluded that it would be beneficial to > seperate the definition of the data object from the underlying > transport protocol to permit defining more than one transport, if > necessary. > > In order to document WG consensus on this issue the chairs would like > to > poll the WG on the following questions: > > It is very important that as many members of the list participate in > this > poll as possible. Please provide feedback to each question as fully as > possible. > > General questions regarding deployed transport protocols: > > 1. How many folks have SOAP implementations in their OSS-BSS systems > for > the > kinds of protocols DRINKS is looking out? > > 2. How many folks have a REST-like implementations in their OSS-BSS > systems > for the kinds of protocols DRINKS is looking out? > > 3. In general what data model or protocol properties do your > organizations > ultimately lean towards - SOAP vs. REST? Other? > > 4. What are the specific applications that SSP are looking for DRINKS > to > enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? > > Questions to reach WG concensus on: > > 3. Do you agree that the design team should define the architecture / > data model independently from the definition of a potential > transport protocol? (as far as possible) > > 4. Given the goal to define the data model outside its transport, do > you > prefer the group to > A. Define a SOAP based transport protocol and if anyone is > interested they can work on a RESTful version? > B. The WG try and do both? > > > Please provide feedback before July 8th, if possible. > > Thanks, > > Richard & Alex > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From HKaplan@acmepacket.com Thu Jul 2 10:05:07 2009 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 E7A083A6B98 for ; Thu, 2 Jul 2009 10:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 Ax2sgukJ-1Xl for ; Thu, 2 Jul 2009 10:05:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1043E3A6890 for ; Thu, 2 Jul 2009 10:05:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 2 Jul 2009 13:05:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Jul 2009 13:05:27 -0400 From: Hadriel Kaplan To: Alexander Mayrhofer , IETF DRINKS WG Date: Thu, 2 Jul 2009 13:05:27 -0400 Thread-Topic: WG poll on transport protocol Thread-Index: Acn2Yh8jnu04p0/PR3Wwi5SjbfhmhQE0tTMQ Message-ID: References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> 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 Subject: Re: [drinks] WG poll on transport protocol 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, 02 Jul 2009 17:05:08 -0000 > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf > Of Alexander Mayrhofer >=20 > General questions regarding deployed transport protocols: >=20 > 1. How many folks have SOAP implementations in their OSS-BSS systems for > the > kinds of protocols DRINKS is looking out? We have both on the embedded systems, but from OSS we only offer/expose SOA= P because that's what every single customer (in the SP market) seems to wan= t. (in the Enterprise market there's a mix) That's assuming the "kinds of protocols DRINKS is looking at" are "provisio= ning" protocols to OSS systems, for LUF type global data. As opposed to, f= or example, "peering" protocols for LRF type local data with real-time topo= logy-aware SIP routing decision implications. =20 > Questions to reach WG concensus on: >=20 > 3. Do you agree that the design team should define the architecture / > data model independently from the definition of a potential > transport protocol? (as far as possible) YES. =20 > 4. Given the goal to define the data model outside its transport, do you > prefer the group to > A. Define a SOAP based transport protocol and if anyone is > interested they can work on a RESTful version? > B. The WG try and do both? A. One step at a time. -hadriel From richard@shockey.us Mon Jul 6 17:12:53 2009 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 E8A1228C452 for ; Mon, 6 Jul 2009 17:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 t1OrPk8-3aHR for ; Mon, 6 Jul 2009 17:12:53 -0700 (PDT) Received: from outbound-mail-09.bluehost.com (outbound-mail-09.bluehost.com [69.89.17.209]) by core3.amsl.com (Postfix) with SMTP id 140493A6A71 for ; Mon, 6 Jul 2009 17:12:53 -0700 (PDT) Received: (qmail 12249 invoked by uid 0); 7 Jul 2009 00:05:24 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy1.bluehost.com with SMTP; 7 Jul 2009 00:05:24 -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=WBQE5UUzeageJKzDDYkHdfgBdTeJH3CpVwCTFpLZnEl4Y/zEKMRLU5XH5hhxDzYBwC/KL9+wC6qsmA7FtIjgCj6bNsTYIPMWdzNNwvLxfLorwvesIf+9uJnoQu1EnZ6T; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MNyBY-00016a-EW for drinks@ietf.org; Mon, 06 Jul 2009 18:05:24 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Mon, 6 Jul 2009 20:05:13 -0400 Message-ID: <04c801c9fe96$9aa84bc0$cff8e340$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_04C9_01C9FE75.1396ABC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn+X9LfaL02C1WrT6Kr5cCRDwgF3gANsO9Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] FW: I-D Action:draft-mule-drinks-proto-00.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: Tue, 07 Jul 2009 00:12:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04C9_01C9FE75.1396ABC0 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, July 06, 2009 1:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-drinks-proto-00.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-00.txt Pages : 34 Date : 2009-07-06 This document defines a protocol for provisioning session establishment data into Session Data Registries or SIP Service Provider data stores, data that may then be used by various network elements for session peering. This document focuses on 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 like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document. Future revisions of this Internet-Draft will include a more complete definition of the Session Peering Provisioning Protocol and considerations and changes to make the protocol implementable using SOAP and RESTful Web Services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-drinks-proto-00.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_04C9_01C9FE75.1396ABC0 Content-Type: Message/External-body; name="draft-mule-drinks-proto-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mule-drinks-proto-00.txt" Content-Type: text/plain Content-ID: <2009-07-06101926.I-D@ietf.org> ------=_NextPart_000_04C9_01C9FE75.1396ABC0 Content-Type: text/plain; name="ATT00655.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00655.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_04C9_01C9FE75.1396ABC0-- From richard@shockey.us Tue Jul 7 05:32:10 2009 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 D413B3A6A4F for ; Tue, 7 Jul 2009 05:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DAxu+kCojIwG for ; Tue, 7 Jul 2009 05:32:10 -0700 (PDT) Received: from outbound-mail-155.bluehost.com (outbound-mail-155.bluehost.com [67.222.39.35]) by core3.amsl.com (Postfix) with SMTP id 041A53A67CC for ; Tue, 7 Jul 2009 05:32:09 -0700 (PDT) Received: (qmail 21451 invoked by uid 0); 7 Jul 2009 12:24:42 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 7 Jul 2009 12:24:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=LcQTLHMrmqtFg5YF39VeEZ8UrOEV5yoKghFOmWpWxtyyDbCBF98tb9leS0T37ydopae0EoK8NJUVJtoEG8w37HBMCpI9eRMR6ZlG6OKX5mGBRK/o69H/f00KmDXcCLDd; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MO9j0-00079Q-09; Tue, 07 Jul 2009 06:24:42 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Tue, 7 Jul 2009 08:24:30 -0400 Message-ID: <015501c9fefd$e1830190$a48904b0$@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: Acn+/eBEsyrR5zqiQaq9/CIihRe+Cg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] Final AGENDA Times Monday 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, 07 Jul 2009 12:32:10 -0000 The chairs will be quickly developing the agenda. It will focus on the following items. A. Status of the Usecases Requirements Document. B. The new protocol document just posted. C. Open discussion of the issues surrounding selection of SOAP vs RESTful as the baseline DRINKS transport protocol. D. Architectural issues surrounding transport layer decisions such as error code handling etc. I'd like to remind the list if you have not responded to our poll on transport issues please do ASAP. If there any other issues please let the chairs know now. MONDAY, July 27, 2009 1500-1520 Afternoon Beverage and Snack Break I - Congresshall Foyer 1520-1720 Afternoon Session II Room 307 INT autoconf Ad-Hoc Network Autoconfiguration WG Congresshall C INT pwe3 Pseudowire Emulation Edge to Edge WG Small Stage OPS grow Global Routing Operations WG Cabaret OPS ipfix IP Flow Information Export WG Congresshall A RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG Large Stage SEC hokey Handover Keying WG Room 300 SEC sasl Simple Authentication and Security Layer WG Congresshall B TSV tsvarea Transport Area Open Meeting Richard Shockey PSTN Mobile: +1 703.593.2683 skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 From richard@shockey.us Mon Jul 13 14:02:10 2009 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 2A86B3A6A12 for ; Mon, 13 Jul 2009 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 885QQkGXhIu6 for ; Mon, 13 Jul 2009 14:02:09 -0700 (PDT) Received: from outbound-mail-30.bluehost.com (outbound-mail-30.bluehost.com [69.89.17.212]) by core3.amsl.com (Postfix) with SMTP id 48BD33A67AA for ; Mon, 13 Jul 2009 14:02:09 -0700 (PDT) Received: (qmail 18594 invoked by uid 0); 13 Jul 2009 21:02:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 13 Jul 2009 21:02:40 -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=c7YtyZm9utIRy/b0kZQtTdYupis+c9/xQpJEKLWP6gFEw0f9XdKJ44ECGeBXiSJbi3iifOr8LxmuSHmXBS1/cRgOuvpSI/lnetnFvYWJXblLuDxTN38kfUEIHp918h5u; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MQSfX-0001ft-UU for drinks@ietf.org; Mon, 13 Jul 2009 15:02:40 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Mon, 13 Jul 2009 17:02:33 -0400 Message-ID: <007f01ca03fd$3e89fc00$bb9df400$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0080_01CA03DB.B7785C00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoD1Zg06IERgNWLS22apkm4QSVVvgAJ6JPg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] FW: I-D Action:draft-mule-drinks-proto-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, 13 Jul 2009 21:02:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0080_01CA03DB.B7785C00 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, July 13, 2009 12:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-drinks-proto-01.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-01.txt Pages : 43 Date : 2009-07-13 This document defines a protocol for provisioning session establishment data into Session Data Registries or SIP Service Provider data stores. The provisioned data may then be used by various network elements for session peering. This document focuses on 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 like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-drinks-proto-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_000_0080_01CA03DB.B7785C00 Content-Type: Message/External-body; name="draft-mule-drinks-proto-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mule-drinks-proto-01.txt" Content-Type: text/plain Content-ID: <2009-07-13090850.I-D@ietf.org> ------=_NextPart_000_0080_01CA03DB.B7785C00 Content-Type: text/plain; name="ATT00962.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00962.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_0080_01CA03DB.B7785C00-- From kcartwright@tnsi.com Wed Jul 22 12:33:07 2009 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 ED4FF3A6C41 for ; Wed, 22 Jul 2009 12:33:07 -0700 (PDT) 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 b4QBpQh8OpRL for ; Wed, 22 Jul 2009 12:33:06 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 9EE943A6C42 for ; Wed, 22 Jul 2009 12:33:04 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.30776902; Wed, 22 Jul 2009 15:34:58 -0400 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, 22 Jul 2009 15:32:07 -0400 From: "Cartwright, Kenneth" To: Brian Rosen , 'Richard Shockey' , "'Guyton, Deborah A'" , "drinks@ietf.org" Date: Wed, 22 Jul 2009 15:32:05 -0400 Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAXxC+QAAD6EtAAAMDqgAdNrLSg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA07255583C2@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net><00bb01c9edc5$287b01a0$797104e0$@us> <002101c9edc8$110ebb30$332c3190$@net> In-Reply-To: <002101c9edc8$110ebb30$332c3190$@net> 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 Subject: Re: [drinks] request for input 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, 22 Jul 2009 19:33:08 -0000 Sorry for offering this delayed input on this subject. But I'm catching up= on some IETF related emails and activities today and wanted to offer some = input on this subject. 1) I've waffled on this subject myself. 2) This discussion is occurring within the context of a provisioning protoc= ol, not a resolution protocol. 3) This discussion is not about whether NAPTRs should be used in *resolutio= n*. It is whether NAPTRs should be used in *provisioning* within the conte= xt of SPPP. 4) NAPTRs are really best suited as *resolution* data structures, but grant= ed the point of division between "provisioning system" and "resolution syst= em" can be gray. None the less, NAPTRs are primarily intended to provide s= tandardization of the data structure that is passed between elements of the= resolution system, not the provisioning system. 5) NAPTRs are of course ENUM centric, not SIP centric. 6) Both ENUM and SIP can be and are used as "resolution" protocols. So hav= ing the provisioning system be somewhat resolution protocol agnostic could = be a good thing, imo. And could turn out to be absolutely necessary. 7) Some piece of software must collect, determine, and then use data elemen= ts to ultimately *build* a NAPTR. But that does not mean that NAPTRs must = be the data structure in which all such information is passed across all la= yers of a peering eco-system. 8) The piece of software that collects, determines, and then uses data elem= ents to *build* a NAPTR could be the SPPP server, for example. Or the SPDP= server, or a combination of the two. But the vital point here is that it = need not be the SPPP client. 9) There is clear precedence here in separating/abstracting the provisionin= g protocol data structures from the resolution protocol data structures. E= PP, for example, does not have the EPP client pass in an NS record, or an A= record. Is has you "register a domain name for X years". It has you "ren= ew a domain name for X years", is has you "associate an NS name with a doma= in name", etc. The EPP registry system then collects and adds to these dat= a elements, send that set of information down to a resolution server. The = resolution server then uses these data elements and others to build a DNS r= esponse that adheres to the DNS RR resolution protocol standard. 7) Given the points above, I think it is certainly worth considering, and p= erhaps even preferable, that the data elements and objects that the SPPP pr= ovisioning protocol exposes not necessarily include a NAPTR object per se. = Instead SPPP can expose objects and contained date elements that can be us= ed by the SPP server or the SPDP server to build NAPTRs. Thanks for considering this. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Brian Rosen Sent: Monday, June 15, 2009 10:46 AM To: 'Richard Shockey'; 'Guyton, Deborah A'; drinks@ietf.org Subject: Re: [drinks] request for input I'd rather this work not get ahead of other protocol work. If there is some protocol effort for routing of "phone-like" services, and it doesn't use NAPTRs, and it has information that NAPTRs don't handle, the= n let's talk about it. I'm not aware of such, and consequently, I'd like to keep the scope to what we have, or can reasonably forecast. Brian From: Richard Shockey [mailto:richard@shockey.us] Sent: Monday, June 15, 2009 10:26 AM To: 'Brian Rosen'; 'Guyton, Deborah A'; drinks@ietf.org Subject: RE: [drinks] request for input Trunkgroup? The LRF whatever that really is.. A sore point for me BTW. Part of this is an attempt to make sure the data provisioned is agnostic to the protocol used to retrieve it . Its not supported to be either ENUM or SIP redirect centric. From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, June 15, 2009 9:55 AM To: 'Guyton, Deborah A'; drinks@ietf.org Subject: Re: [drinks] request for input We haven't found anything we can't do with a NAPTR, with parameters. Could someone cite an example of what you can't do with a NAPTR? Brian From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. Thank you. Please reply to the list. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks 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 richard@shockey.us Thu Jul 23 15:24:04 2009 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 49B083A68D1 for ; Thu, 23 Jul 2009 15:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 oEkl8Qm1YJpj for ; Thu, 23 Jul 2009 15:24:03 -0700 (PDT) Received: from outbound-mail-125.bluehost.com (outbound-mail-125.bluehost.com [67.222.38.25]) by core3.amsl.com (Postfix) with SMTP id 9192D3A6802 for ; Thu, 23 Jul 2009 15:24:03 -0700 (PDT) Received: (qmail 2016 invoked by uid 0); 23 Jul 2009 22:24:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 23 Jul 2009 22:24:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=gVQ7f2+X7fjVOcFn70ELnAqDhIpntwR0w81RBcajJwIUmsb3N7q0+6mskpofZRRwfqfuTqnHvrKREJuhvIWLqu9D4pMsO+GfiSLiiMuOBrX/SgRP813u/DsRcu5hhFig; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MU6hn-0001za-Sj; Thu, 23 Jul 2009 16:24:04 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Thu, 23 Jul 2009 18:23:47 -0400 Message-ID: <02a201ca0be4$400d1a50$c0274ef0$@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: AcoL2VeTwLd/8vtuRnqcCaAN4cZMUgACtI1w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] Final Agenda for Monday 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, 23 Jul 2009 22:24:04 -0000 http://www.ietf.org/proceedings/75/agenda/drinks.txt From dschwartz@xconnect.net Mon Jul 27 04:17:51 2009 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 A349828C162 for ; Mon, 27 Jul 2009 04:17:51 -0700 (PDT) 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 1+aI-i088XlK for ; Mon, 27 Jul 2009 04:17:50 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 66BFC3A69D5 for ; Mon, 27 Jul 2009 04:17:50 -0700 (PDT) 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; Mon, 27 Jul 2009 14:17:48 +0300 From: David Schwartz To: "drinks@ietf.org" Date: Mon, 27 Jul 2009 14:17:47 +0300 Thread-Topic: Quick comments on draft-ietf-drinks-usecases-requirements-00 Thread-Index: AQHKDqveR3/guOiAnkWzOkZLRLwVng== Message-ID: <6EA53FAD386F9D46B97D49BFE148D51480AF71@ISR-JLM-MAIL1.xconnect.co.il> 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 Subject: [drinks] Quick comments on draft-ietf-drinks-usecases-requirements-00 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, 27 Jul 2009 11:17:51 -0000 Sorry for the late comments on this - only had time to read this now :( Page 7: RN is not defined in definitions section (although I know what it i= s :)) Page 7: Does routing group cover service types as well?=20 Page 8: A TN is associated with one or more DGs? isn't it the other way aro= und? multiple TNs may be associated with a DG. Otherwise how can you find a= DG from a TN? Page 9: Can't RN reside on the other side of the DG as well? I mean can't R= N be part of SED as well? Page 10: UC2 (upload instead of download) Page 10: UC3 NRT should only override live (not future) Page 11: UC4 How is this different than just specifying data-recipient-grou= p of "self" Page 11: UC6 why delete and not inactive? "inactive" gives you insight to w= ho 'used" to own the number Page 12: UC12 need to discuss splitting up of ranges (e.g. due to NP for e= xample) Page 13: UC15a similar but in reverse - I want to request your data, if yo= u approve - need to add me to data recipient group Page 14: UC16 need to combine the two sources of data (e.g. get an extensio= n Route Header) Page 14: missing UC for SSP stepping on number space of other SSP Page 14: Why is the TN and RN data requirements only a SHOULD? Page 14: Missing the requirement for grouping of destinations within a data= recipient group Page 15: FREQ2 I find the R.T and N.R.T a misnomer. It should really be ind= ividual vs bulk. The time aspect applies to both (e.g. you can defer a bulk= registration as well) Page 15: General comment - FREQ3 should be broken out to multiple REQs. Page 15: FREQ3 are you reassigning "groupings" of PIs? if not, what do you = mean by "one or more"? Page 15: FREQ3 association and disassociation of a "Default Routing Group" = with a Data Recipient - don't you mean Data Recipient Group? Page 15: FREQ3 How is primary provider vs transit indicated? what is the me= chanism for authentication of this? This is a good requirement but imho nee= ds much flushing out Page 15: FREQ7 which UC is this referencing? What is the difference between= the sub-identities? different ingress/egress IPs? please explain Page 16: FREQ9 is there a NXDOMAIN type option as well? it seems from here = that I must return an answer Page 16: FREQ11 should be split into two or three REQs Page 16: FREQ11 How is the data object owner determined? You spoke before o= f transit providers vs CoRs so I assume that you assign a data object owner= only to CoR - how than does transit provider provision? D. From dschwartz@xconnect.net Mon Jul 27 05:01:16 2009 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 1019F3A6C20 for ; Mon, 27 Jul 2009 05:01:16 -0700 (PDT) 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 Rx+kOys8XnWR for ; Mon, 27 Jul 2009 05:01:15 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id BF7EB3A6C58 for ; Mon, 27 Jul 2009 05:01:14 -0700 (PDT) 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; Mon, 27 Jul 2009 15:01:12 +0300 From: David Schwartz To: "drinks@ietf.org" Date: Mon, 27 Jul 2009 15:01:11 +0300 Thread-Topic: Quick comments on draft-mule-drinks-proto-01 Thread-Index: AQHKDrHv4XCD4wqKK0Cybmos/RjipA== Message-ID: <6EA53FAD386F9D46B97D49BFE148D51480AF72@ISR-JLM-MAIL1.xconnect.co.il> 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 Subject: [drinks] Quick comments on draft-mule-drinks-proto-01 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, 27 Jul 2009 12:01:16 -0000 Sorry for the late comments... Page 11: where did the private ID go? Page 11 : in the UC doc there is reference to egress routing which used to = be covered by your model but has now been taken out.=20 Page 11: Where did RN groupings go? The UC doc still has in its data model Page 12: How do you deal with trunk groups? Routing Numbers? (I am aware of= the ;rn=3D tag). How about egress routes IN ADDITION to target routes? why= are we so insistent on NAPTR being the format? I have not problem with NS = but think that NAPTR is wrong. I commented about this on the list but did n= ot receive any feedback so I guess I will have to argue this at the mic :(= =20 Page 13: 3.3.2 How do you deal with the transit provider provisioning case = mentioned in the UC doc? Page 13: 3.3.3 You should add that the data does not need to be deleted onl= y treated as if date is invalid (similar to adding prior to activation date= )=20 Page 13: 3.4 I see that some of my previous comments are addressed by the c= urrent limitations section but I will leave them in this email as discussio= n points. Page 17: 4.7 Server should have the ability to throttle large uploads Did not look at the formal spec - will save for some other time :) D. From kcartwright@tnsi.com Mon Jul 27 06:37:27 2009 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 341A328C203 for ; Mon, 27 Jul 2009 06:37:27 -0700 (PDT) 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 YtpOUt8oL3oh for ; Mon, 27 Jul 2009 06:37:26 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 14C803A6C82 for ; Mon, 27 Jul 2009 06:37:25 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31051355; Mon, 27 Jul 2009 09:40:02 -0400 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, 27 Jul 2009 09:37:01 -0400 From: "Cartwright, Kenneth" To: David Schwartz , "drinks@ietf.org" Date: Mon, 27 Jul 2009 09:35:34 -0400 Thread-Topic: [drinks] Quick comments on draft-ietf-drinks-usecases-requirements-00 Thread-Index: AQHKDqveR3/guOiAnkWzOkZLRLwVnpCJYOVP Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725964D79@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6EA53FAD386F9D46B97D49BFE148D51480AF71@ISR-JLM-MAIL1.xconnect.co.il> In-Reply-To: <6EA53FAD386F9D46B97D49BFE148D51480AF71@ISR-JLM-MAIL1.xconnect.co.il> 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 Subject: Re: [drinks] Quick comments on draft-ietf-drinks-usecases-requirements-00 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, 27 Jul 2009 13:37:27 -0000 Needless to say, these are all good comments and it is good to see some tra= ffic on the mailling list. We'll work to discuss these and update the docu= ments after IETF meetings allow. Ken ________________________________________ From: drinks-bounces@ietf.org [drinks-bounces@ietf.org] On Behalf Of David = Schwartz [dschwartz@xconnect.net] Sent: Monday, July 27, 2009 7:17 AM To: drinks@ietf.org Subject: [drinks] Quick comments on draft-ietf-drinks-usecases-requirem= ents-00 Sorry for the late comments on this - only had time to read this now :( Page 7: RN is not defined in definitions section (although I know what it i= s :)) Page 7: Does routing group cover service types as well? Page 8: A TN is associated with one or more DGs? isn't it the other way aro= und? multiple TNs may be associated with a DG. Otherwise how can you find a= DG from a TN? Page 9: Can't RN reside on the other side of the DG as well? I mean can't R= N be part of SED as well? Page 10: UC2 (upload instead of download) Page 10: UC3 NRT should only override live (not future) Page 11: UC4 How is this different than just specifying data-recipient-grou= p of "self" Page 11: UC6 why delete and not inactive? "inactive" gives you insight to w= ho 'used" to own the number Page 12: UC12 need to discuss splitting up of ranges (e.g. due to NP for e= xample) Page 13: UC15a similar but in reverse - I want to request your data, if yo= u approve - need to add me to data recipient group Page 14: UC16 need to combine the two sources of data (e.g. get an extensio= n Route Header) Page 14: missing UC for SSP stepping on number space of other SSP Page 14: Why is the TN and RN data requirements only a SHOULD? Page 14: Missing the requirement for grouping of destinations within a data= recipient group Page 15: FREQ2 I find the R.T and N.R.T a misnomer. It should really be ind= ividual vs bulk. The time aspect applies to both (e.g. you can defer a bulk= registration as well) Page 15: General comment - FREQ3 should be broken out to multiple REQs. Page 15: FREQ3 are you reassigning "groupings" of PIs? if not, what do you = mean by "one or more"? Page 15: FREQ3 association and disassociation of a "Default Routing Group" = with a Data Recipient - don't you mean Data Recipient Group? Page 15: FREQ3 How is primary provider vs transit indicated? what is the me= chanism for authentication of this? This is a good requirement but imho nee= ds much flushing out Page 15: FREQ7 which UC is this referencing? What is the difference between= the sub-identities? different ingress/egress IPs? please explain Page 16: FREQ9 is there a NXDOMAIN type option as well? it seems from here = that I must return an answer Page 16: FREQ11 should be split into two or three REQs Page 16: FREQ11 How is the data object owner determined? You spoke before o= f transit providers vs CoRs so I assume that you assign a data object owner= only to CoR - how than does transit provider provision? D. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks 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 lendl@nic.at Mon Jul 27 08:13:32 2009 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 2758428C211 for ; Mon, 27 Jul 2009 08:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=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 VPE75yfNyVPw for ; Mon, 27 Jul 2009 08:13:31 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 1CFB928C1AD for ; Mon, 27 Jul 2009 08:13:31 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1MVRtI-0003Cm-00 for ; Mon, 27 Jul 2009 17:13:28 +0200 Date: Mon, 27 Jul 2009 17:13:28 +0200 From: Otmar Lendl To: drinks@ietf.org Message-ID: <20090727151328.GA12249@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Otmar Lendl Subject: [drinks] Comment on the NAPTR question 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, 27 Jul 2009 15:13:32 -0000 This is too long to be asked on the Jabber channel, but let me bring it up here: The question was whether we can capture all information needed in NAPTR records. I think that is definitetly the case for the Number->DestinationGroup mapping. Stupid Question: Would it be possible to have the Registry push the relevant DestinationGroup/RouteGroup/NAPTR data to its customer's SIP devices independently of any actual call? This is basically a routing table dump. This is the merged with local internal routing data to build the local data structures needed to generate full SED (internal routing to get to the egress element, next external hop, SIP parameters, security parameters, ...) based on a DestGroup as input. Only the TN/PI -> DestGroup mapping is done by a live, on-demand query to the Registry (or a locally cached copy). This is the only time when we actually need to transmit NAPTRs on the wire between the registry and the querying party. ------------- What I'm fearing is that we try to use ENUM/NAPTRs as a SIP-Proxy control protocol. It was never designed for that. It can be coaxed to support simple scenarions. More complexity can be supported in the answers (the ugly: URI mentioned today), but it ENUM just can't support complextity in the quesion. See http://tools.ietf.org/html/draft-lendl-speermint-background-02#section-6.2 for a more verbose explanation. All the latest perversions suggested as feature for ENUM (source-dependent lookups, Trunk-groups) stem from this mistake. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg From ppfautz@att.com Mon Jul 27 09:45:53 2009 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 B06F23A6AD5 for ; Mon, 27 Jul 2009 09:45:53 -0700 (PDT) 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 i0FhU9EuSTX0 for ; Mon, 27 Jul 2009 09:45:53 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id BD60428C0EC for ; Mon, 27 Jul 2009 09:45:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1248713152!35705987!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30200 invoked from network); 27 Jul 2009 16:45:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jul 2009 16:45:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6RGjpCe009574 for ; Mon, 27 Jul 2009 12:45:51 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6RGjnux009544 for ; Mon, 27 Jul 2009 12:45:49 -0400 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_01CA0ED9.B231B902" Date: Mon, 27 Jul 2009 12:45:49 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0w== From: "PFAUTZ, PENN L, ATTCORP" To: Subject: [drinks] Comment on today's drinks discussion 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, 27 Jul 2009 16:45:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0ED9.B231B902 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been away from the design group for a while since the focus seemed to shift more to lower level design issues outside of my bailiwick but I came away from today's IETF discussion with an uncomfortable feeling about where the drinks effort is heading. One the one hand I feel that some of the issues we agreed to set aside to narrow scope (LUF/LRF) are coming back to haunt us and on the other that the effort is straining as Otmar suggests to accommodate more and more complexity that should, perhaps be handled elsewhere. Perhaps these are different sides of the same coin.=20 I for one have concerns about how useful the resulting protocol is likely to be, at least for my company's likely applications. =20 =20 Penn Pfautz AT&T Access Management +1-732-420-4962 =20 ------_=_NextPart_001_01CA0ED9.B231B902 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I've = been away from=20 the design group for a while since the focus seemed to shift more to = lower level=20 design issues outside of my bailiwick but I came away from today's = IETF=20 discussion with an uncomfortable feeling about where the drinks = effort is=20 heading.
One = the one hand I=20 feel that some of the issues we agreed to set aside to narrow=20 scope (LUF/LRF) are coming back to haunt us and on the other that = the=20 effort is straining as Otmar suggests to accommodate more and more = complexity=20 that should, perhaps be handled elsewhere. Perhaps these are different = sides of=20 the same coin.
I for one have=20 concerns about how useful the resulting protocol is likely to be, at = least for=20 my company's likely applications.
 
 
Penn Pfautz
AT&T Access = Management
+1-732-420-4962
 
------_=_NextPart_001_01CA0ED9.B231B902-- From alexander.mayrhofer@nic.at Mon Jul 27 09:55:59 2009 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 B40C928C303 for ; Mon, 27 Jul 2009 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.442 X-Spam-Level: X-Spam-Status: No, score=-8.442 tagged_above=-999 required=5 tests=[AWL=0.988, 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 mM46IfL1vnzV for ; Mon, 27 Jul 2009 09:55:59 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 7F3C428C2E5 for ; Mon, 27 Jul 2009 09:55:57 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Mon, 27 Jul 2009 18:55:57 +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: Mon, 27 Jul 2009 18:55:57 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> In-Reply-To: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wAASmUA References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> From: "Alexander Mayrhofer" To: "PFAUTZ, PENN L, ATTCORP" , X-XWALL-BCKS: auto Subject: Re: [drinks] Comment on today's drinks discussion 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, 27 Jul 2009 16:55:59 -0000 > I for one have concerns about how useful the resulting=20 > protocol is likely to be, at least for my company's likely=20 > applications. Penn, Thanks for that "wakeup call" - as we said we want definitely a deployable protocol, so i'm concerned about your statement - could you elaborate of what properties of the current draft would make it less useful for your company's applications, and what could be done to make it fit better? Thanks Alex From andy@hxr.us Mon Jul 27 10:00:23 2009 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 6972D28C0EC for ; Mon, 27 Jul 2009 10:00:23 -0700 (PDT) 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 DFKZhLPj1Iii for ; Mon, 27 Jul 2009 10:00:22 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id A0A6D28C170 for ; Mon, 27 Jul 2009 10:00:22 -0700 (PDT) Received: from host-78-64-88-45.homerun.telia.com ([::ffff:78.64.88.45]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 27 Jul 2009 13:00:21 -0400 id 015842FB.4A6DDD25.00006293 Message-Id: From: Andrew Newton To: "PFAUTZ, PENN L, ATTCORP" In-Reply-To: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 13:00:20 -0400 References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> X-Mailer: Apple Mail (2.935.3) Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion 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, 27 Jul 2009 17:00:23 -0000 I thought it was a very good session, and I feel better now about the resulting protocol than before. -andy On Jul 27, 2009, at 12:45 PM, PFAUTZ, PENN L, ATTCORP wrote: > I've been away from the design group for a while since the focus > seemed to shift more to lower level design issues outside of my > bailiwick but I came away from today's IETF discussion with an > uncomfortable feeling about where the drinks effort is heading. > One the one hand I feel that some of the issues we agreed to set > aside to narrow scope (LUF/LRF) are coming back to haunt us and on > the other that the effort is straining as Otmar suggests to > accommodate more and more complexity that should, perhaps be handled > elsewhere. Perhaps these are different sides of the same coin. > I for one have concerns about how useful the resulting protocol is > likely to be, at least for my company's likely applications. > > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From ppfautz@att.com Wed Jul 29 13:39:38 2009 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 46D243A7031 for ; Wed, 29 Jul 2009 13:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 BkLiXcPUkQeb for ; Wed, 29 Jul 2009 13:39:37 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 96E963A6EC6 for ; Wed, 29 Jul 2009 13:39:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1248899976!4425817!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 20694 invoked from network); 29 Jul 2009 20:39:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2009 20:39:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6TKdZYe028593 for ; Wed, 29 Jul 2009 16:39:35 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6TKdSQl028522 for ; Wed, 29 Jul 2009 16:39:28 -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: Wed, 29 Jul 2009 16:39:28 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wAASmUAAGuYGvA= References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> From: "PFAUTZ, PENN L, ATTCORP" To: "Alexander Mayrhofer" , Subject: Re: [drinks] Comment on today's drinks discussion 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, 29 Jul 2009 20:39:38 -0000 Alex: My concerns are not entirely with respect to the current draft but some of the directions that the discussion during the WG session suggested the work might be taking. I've had a lingering concern about the disconnect between what Speermint has proposed (LUF/LRF)and the route that drinks has taken. Since the will of the design team seemed to be to get on with a simple protocol directed toward provisioning DNS RRs I let that ride. Monday's session, however brought up things like more abstraction of routing elements which suggests to me assumptions about the nature of interconnections and my issues with the original ESPP I-D. Brian Rosen's comment about number "ownership" relations also seemed to suggest another complexity that the protocol would try to incorporate.=20 I get concerned about a protocol that either makes a lot of specific assumptions about the nature of the registry and the interconnection framework and/or becomes bloated by trying to incorporate the panoply of possible cases. A more specific issue - the definition of Registrant as an "end user" - this is at least confusing in the context of Infrastructure vs. End User ENUM. I'll keep watching how things evolve. It may be that others conclude they need the added complexity but I wanted to be forthright about my position. Thanks for listening.=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at]=20 Sent: Monday, July 27, 2009 12:56 PM To: PFAUTZ, PENN L, ATTCORP; drinks@ietf.org Subject: RE: [drinks] Comment on today's drinks discussion > I for one have concerns about how useful the resulting=20 > protocol is likely to be, at least for my company's likely=20 > applications. Penn, Thanks for that "wakeup call" - as we said we want definitely a deployable protocol, so i'm concerned about your statement - could you elaborate of what properties of the current draft would make it less useful for your company's applications, and what could be done to make it fit better? Thanks Alex From dguyton@telcordia.com Wed Jul 29 23:42:33 2009 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 7F4053A6DC8 for ; Wed, 29 Jul 2009 23:42:33 -0700 (PDT) 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 kyvaoyUUJogk for ; Wed, 29 Jul 2009 23:42:31 -0700 (PDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by core3.amsl.com (Postfix) with ESMTP id 773603A6838 for ; Wed, 29 Jul 2009 23:42:31 -0700 (PDT) Received: from rrc-dte-ieg01.dte.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx2pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n6U6gWfQ008113 for ; Thu, 30 Jul 2009 02:42:32 -0400 (EDT) X-AuditID: 80601416-000010b0000018a4-1d-4a7140d55697 Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by rrc-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 02:42:29 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Thu, 30 Jul 2009 02:42:29 -0400 From: "Guyton, Deborah A" To: "'PFAUTZ, PENN L, ATTCORP'" , Alexander Mayrhofer , "drinks@ietf.org" Date: Thu, 30 Jul 2009 02:42:28 -0400 Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wAASmUAAGuYGvAAFaa4wA== Message-ID: References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B01FA1C64@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [drinks] Comment on today's drinks discussion 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, 30 Jul 2009 06:42:33 -0000 Hi Penn, Hopefully I can clear up one item quickly. The idea of "Registrant" is the = notion that a "Registrar" who is the "holder" of the data or carrier of rec= ord, for example, might outsource the administration of that data to a "Reg= istrant". An analogy in today's world is that some companies do not mana= ge their own data in LERG but outsource to a third party. It may be necess= ary to allow for an individual administrator "Joe Administrator" to be the = responsible individual for administering that data - hence having a login a= nd password (particularly for a GUI) but could be a login and password for = a service provisioning interface. For data issues, you might need to resolv= e with a person. If administration is done as it is today, perhaps for AT&T, Registrar =3D A= T&T and Registrant =3D AT&T. Hope that helps. Debbie -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= PFAUTZ, PENN L, ATTCORP Sent: Wednesday, July 29, 2009 4:39 PM To: Alexander Mayrhofer; drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion Alex: My concerns are not entirely with respect to the current draft but some of the directions that the discussion during the WG session suggested the work might be taking. I've had a lingering concern about the disconnect between what Speermint has proposed (LUF/LRF)and the route that drinks has taken. Since the will of the design team seemed to be to get on with a simple protocol directed toward provisioning DNS RRs I let that ride. Monday's session, however brought up things like more abstraction of routing elements which suggests to me assumptions about the nature of interconnections and my issues with the original ESPP I-D. Brian Rosen's comment about number "ownership" relations also seemed to suggest another complexity that the protocol would try to incorporate. I get concerned about a protocol that either makes a lot of specific assumptions about the nature of the registry and the interconnection framework and/or becomes bloated by trying to incorporate the panoply of possible cases. A more specific issue - the definition of Registrant as an "end user" - this is at least confusing in the context of Infrastructure vs. End User ENUM. I'll keep watching how things evolve. It may be that others conclude they need the added complexity but I wanted to be forthright about my position. Thanks for listening. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at] Sent: Monday, July 27, 2009 12:56 PM To: PFAUTZ, PENN L, ATTCORP; drinks@ietf.org Subject: RE: [drinks] Comment on today's drinks discussion > I for one have concerns about how useful the resulting > protocol is likely to be, at least for my company's likely > applications. Penn, Thanks for that "wakeup call" - as we said we want definitely a deployable protocol, so i'm concerned about your statement - could you elaborate of what properties of the current draft would make it less useful for your company's applications, and what could be done to make it fit better? Thanks Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From br@brianrosen.net Wed Jul 29 23:55:15 2009 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 0C4123A716D for ; Wed, 29 Jul 2009 23:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Bb2XjrSa4rph for ; Wed, 29 Jul 2009 23:55:14 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id F25A128C13A for ; Wed, 29 Jul 2009 23:55:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MWPXh-00034Q-0u; Thu, 30 Jul 2009 01:55:10 -0500 From: "Brian Rosen" To: "'Guyton, Deborah A'" , "'PFAUTZ, PENN L, ATTCORP'" , "'Alexander Mayrhofer'" , References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: Date: Thu, 30 Jul 2009 02:55:08 -0400 Message-ID: <00e801ca10e2$b043b100$10cb1300$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wAASmUAAGuYGvAAFaa4wAAAl+uQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [drinks] Comment on today's drinks discussion 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, 30 Jul 2009 06:55:15 -0000 I got into this with some real world issues where numbers are resold, and SOME provisioning responsibility goes with the resale. There are also cases where there is a chain of resellers, and the services each can provision may be different. Brian > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Guyton, Deborah A > Sent: Thursday, July 30, 2009 2:42 AM > To: 'PFAUTZ, PENN L, ATTCORP'; Alexander Mayrhofer; drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion > > Hi Penn, > Hopefully I can clear up one item quickly. The idea of "Registrant" is > the notion that a "Registrar" who is the "holder" of the data or > carrier of record, for example, might outsource the administration of > that data to a "Registrant". An analogy in today's world is that some > companies do not manage their own data in LERG but outsource to a > third party. It may be necessary to allow for an individual > administrator "Joe Administrator" to be the responsible individual for > administering that data - hence having a login and password > (particularly for a GUI) but could be a login and password for a > service provisioning interface. For data issues, you might need to > resolve with a person. > If administration is done as it is today, perhaps for AT&T, Registrar = > AT&T and Registrant = AT&T. > Hope that helps. > Debbie > > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of PFAUTZ, PENN L, ATTCORP > Sent: Wednesday, July 29, 2009 4:39 PM > To: Alexander Mayrhofer; drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion > > Alex: > My concerns are not entirely with respect to the current draft but some > of the directions that the discussion during the WG session suggested > the work might be taking. > > I've had a lingering concern about the disconnect between what > Speermint > has proposed (LUF/LRF)and the route that drinks has taken. Since the > will of the design team seemed to be to get on with a simple protocol > directed toward provisioning DNS RRs I let that ride. Monday's session, > however brought up things like more abstraction of routing elements > which suggests to me assumptions about the nature of interconnections > and my issues with the original ESPP I-D. > > Brian Rosen's comment about number "ownership" relations also seemed to > suggest another complexity that the protocol would try to incorporate. > > I get concerned about a protocol that either makes a lot of specific > assumptions about the nature of the registry and the interconnection > framework and/or becomes bloated by trying to incorporate the panoply > of > possible cases. > > A more specific issue - the definition of Registrant as an "end user" - > this is at least confusing in the context of Infrastructure vs. End > User > ENUM. > > I'll keep watching how things evolve. It may be that others conclude > they need the added complexity but I wanted to be forthright about my > position. > Thanks for listening. > > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at] > Sent: Monday, July 27, 2009 12:56 PM > To: PFAUTZ, PENN L, ATTCORP; drinks@ietf.org > Subject: RE: [drinks] Comment on today's drinks discussion > > > I for one have concerns about how useful the resulting > > protocol is likely to be, at least for my company's likely > > applications. > > Penn, > > Thanks for that "wakeup call" - as we said we want definitely a > deployable protocol, so i'm concerned about your statement - could you > elaborate of what properties of the current draft would make it less > useful for your company's applications, and what could be done to make > it fit better? > > Thanks > > Alex > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks