Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time.
The mechanism in the ViPR drafts seemed to be able to accomplish the "finding the party responsible for a number" - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <[email protected]> wrote: > A we already have centralized solutions for interdomain routing based on > E.164. its called ENUM in both its private and public instantiations. It > works pretty well BTW and globally deployed. > > IMHO this charter is a non starter and should not be approved on the basis > of this statement alone. > > "finding domains that claim to be responsible for a given phone number" > > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ? > > We have this problem of E.164 validation all the time in SIP and its not > going to be solved in the IETF. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 30, 2010 11:33 AM > To: Mary Barnes > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > > > -----Original Message----- > > From: Mary Barnes [mailto:[email protected]] > > Sent: Wednesday, June 30, 2010 6:24 PM > > To: Romascanu, Dan (Dan) > > Cc: DISPATCH; IETF-Discussion list > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Dan, > > > > The term peer to peer is intended to exclude mechanisms that > > would use a central repository for the information: This was > > discussed in an earlier thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > > > In one sense it is a solution, however, in another sense it > > is reusing SIP related functionality defined in RAI and thus > > is in a similar vein as specifying the use of SIP in a charter. > > > > Thanks, > > Mary. > > > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > > <[email protected]> wrote: > > >> The VIPR WG will address this problem by developing a peer to peer > > >> based approach to finding domains that claim to be > > responsible for a > > >> given phone number and validation protocols to ensure a reasonable > > >> likelihood that a given domain actually is responsible for > > the phone > > >> number. > > > > > > Hi, > > > > > > Clarification question. What exactly means 'peer to peer > > based approach' > > > and what kind of approaches are excluded by having this in > > the charter. > > > Does 'approach' mean solution? If so why does a specific type of > > > solution need to be agreed in the charter, while all we > > have at hand > > > at this point are individual contribution I-Ds that describe the > > > 'problem statement and some possible starting points for solutions'? > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > >> -----Original Message----- > > >> From: [email protected] > > >> [mailto:[email protected]] On Behalf Of Mary Barnes > > >> Sent: Monday, June 28, 2010 8:38 PM > > >> To: DISPATCH > > >> Subject: [dispatch] VIPR - proposed charter version 3 > > >> > > > > > > _______________________________________________ > dispatch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dispatch >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
