I can see how the IP address on which the customer is getting service might
change more quickly than you might want for telephony.
But that would seem to me to be something that the application layer is
going to have to take account of. DNS may not be the ultimate discovery
scheme you want, but it is going to have to be a part of the scheme you use.
Also, the people who hook their systems up to these infrastructures know
that they are doing telephony. So presumably they are not just blindly
connecting up to the local broadband providers DNS on the offchance it might
be run appropriately for their needs.
So while people do screw up DNS service at certain sites, that does not
necessarily need to be a blocking factor here.
On Wed, Oct 20, 2010 at 3:43 PM, bill manning <bmanning(_at_)isi(_dot_)edu>
wrote:
while I agree that the hierarchical and distributed nature of the DNS is
a scintillating, shimmering attractant, it is wise to be aware of the
baseline
assumption in your arguement, e.g. that a client will -ALWAYS- ask an
authoritative
source...
The DNS is so designed that caching is a huge component of the scalability
of
the DNS... and its greatest hinderance for such ideas as are laid out in
the ENUM
dip lookup. You can't be assured that the data is timely. This is a
strong reason
to consider that the DNS is _NOT_ the droid you are looking for, in spite
of its other
attractive qualities.
just my 0.02 lira.
--bill
On 20October2010Wednesday, at 12:25, Richard Shockey wrote:
And finally, regarding:
"It is unclear why this data is better maintained by the DNS
than in an unrelated application protocol."
If a device is performing an ENUM dip hoping to find a contactable SIP
URI,
it is simply most efficient for the ENUM response to directly include the
Send-N metadata when needed rather than have separate queries using a
different network protocol. Also, the hierarchical and distributed
nature
of the DNS protocol makes it an _ideal_ structural fit for this meta
data.
I believe the onus should be on your draft to explicitly identify valid
technical reasons why the DNS protocol should _not_ be used, rather than
make vague hand-waving assertions which appear to have little or no
justification.
RS> Precisely, What is unclear is why the IETF and the IAB is suddenly
trying to block a perfectly legitimate extension of RFC 3761 that is in
various forms of global deployment, proven to work, scale and more
importantly provides a valuable and essential function in the transition
from analog POTS to SIP based communication.
Just saying no is not a solution to the real issues of number translation
in
carrier networks.
Ok a lot of people hate phone numbers including, it seems, 50% of RAI
directorate but they are not going away anytime soon.
So just say it .. is this the message? Don't even try to charter E2MD?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf