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

["Cartwright, Kenneth" <kcartwright at tnsi.com>]

Thanks.  Can you please provide more detail on this so that we are able to assess whether we need to add something to the protocol to support it.  More specifically:

1) Numbers can certainly be "resold" as you say (e.g. an MVNO).  But what impact does this have on the features of the protocol?  I do not think the Use Case document contains use cases that document what you may be getting at.
2) What exactly do you mean by "SOME provisioning responsibility goes with the resale".
3) You separately ("there are also cases") refer to the fact that there are "chains of resellers" and "the services each can provision may be different".  Can you be more specific with what you mean by "services" in the above statement?

Thanks

-----Original Message-----
From: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, July 30, 2009 2:55 AM
To: 'Guyton, Deborah A'; 'PFAUTZ, PENN L, ATTCORP'; 'Alexander Mayrhofer'; drinks at ietf.org
Subject: Re: [drinks] Comment on today's drinks discussion

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 at ietf.org [mailto:drinks-bounces at ietf.org] On
> Behalf Of Guyton, Deborah A
> Sent: Thursday, July 30, 2009 2:42 AM
> To: 'PFAUTZ, PENN L, ATTCORP'; Alexander Mayrhofer; drinks at 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 at ietf.org [mailto:drinks-bounces at ietf.org] On
> Behalf Of PFAUTZ, PENN L, ATTCORP
> Sent: Wednesday, July 29, 2009 4:39 PM
> To: Alexander Mayrhofer; drinks at 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 at nic.at]
> Sent: Monday, July 27, 2009 12:56 PM
> To: PFAUTZ, PENN L, ATTCORP; drinks at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/drinks
> _______________________________________________
> drinks mailing list
> drinks at ietf.org
> https://www.ietf.org/mailman/listinfo/drinks

_______________________________________________
drinks mailing list
drinks at 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 Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.