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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.