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

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Mon, 27 Jul 2009 12:45:49 -0400

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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 27 Jul 2009 18:55:57 +0200

> 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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 27 Jul 2009 13:00:20 -0400

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.
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Wed, 29 Jul 2009 16:39:28 -0400

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:[email-masked]] 
Sent: Monday, July 27, 2009 12:56 PM
To: PFAUTZ, PENN L, ATTCORP; [email-masked]
Subject: RE: [drinks] Comment on today's drinks discussion

Penn,

Thanks

Alex

---

From: "Guyton, Deborah A" <[email-masked]>
Date: Thu, 30 Jul 2009 02:42:28 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L, ATTCORP
Sent: Wednesday, July 29, 2009 4:39 PM
To: Alexander Mayrhofer; [email-masked]
Subject: Re: [drinks] Comment on today's drinks discussion

Alex:

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]]
Sent: Monday, July 27, 2009 12:56 PM
To: PFAUTZ, PENN L, ATTCORP; [email-masked]
Subject: RE: [drinks] Comment on today's drinks discussion

Penn,

Thanks

Alex

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 30 Jul 2009 02:55:08 -0400

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Guyton, Deborah A
> Sent: Thursday, July 30, 2009 2:42 AM
> To: 'PFAUTZ, PENN L, ATTCORP'; Alexander Mayrhofer; [email-masked]
> 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.