Re: [drinks] Comment on today's drinks discussion

"PFAUTZ, PENN L, ATTCORP" <ppfautz@att.com> Wed, 29 July 2009 20:39 UTC

Return-Path: <ppfautz@att.com>
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 <drinks@core3.amsl.com>; 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 <drinks@core3.amsl.com>; 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 <drinks@ietf.org>; 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 <drinks@ietf.org>; 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 <drinks@ietf.org>; 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" <ppfautz@att.com>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>, 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 <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=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. 

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