RE: Solving the right problems ...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Solving the right problems ...



We've tested similar mechanism with SRV and performance seems does not suffer.
/Yuri

-----Original Message-----
From: Henry Sinnreich [mailto:Henry.Sinnreich at mci.com]
Sent: Tuesday, September 02, 2003 7:46 PM
To: 'vinton g. cerf'; ietf at ietf.org
Cc: Richard Shockey; Christian Stredicke
Subject: RE: Solving the right problems ...


> Could one use the NAPTR concept to create a new identifier space with 
> specific dynamics? It would take two lookups: one to DNS to get the NAPTR 
> and one to resolve the NAPTR identifier into an IP address.

We will be soon able to test the speed of such a mechanism with the NAPTR
client built into SIP phones that are just emerging. I have copied here its
developer, Christian Stredicke and the ENUM co-chair Richard Shockey to
answer questions on this.

Thanks, Henry

-----Original Message-----
From: owner-ietf at ietf.org [mailto:owner-ietf at ietf.org] On Behalf Of vinton
g. cerf
Sent: Wednesday, August 27, 2003 10:09 PM
To: ietf at ietf.org
Subject: RE: Solving the right problems ...

If you look at the instant messaging systems, they map a private identifier
space (IM name or "handle") into IP addresses and apparently run background
heartbeat to re-assign the mapping if the identifier in the heartbeat
arrives in a packet with a different IP address than before - not sure
whether or how hijack is avoided. Could one use the NAPTR concept to create
a new identifier space with specific dynamics? It would take two lookups:
one to DNS to get the NAPTR and one to resolve the NAPTR identifier into an
IP address. The latter resolution need not necessarily be done via DNS.

vint



Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
vinton.g.cerf at mci.com
www.mci.com/cerfsup 








Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.