Re: [dispatch] VIPR - proposed charter version 3

[Peter Musgrave <[e-mail]>]

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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
> > 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)
> > <[e-mail]> 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: [e-mail]
> > >> [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>