On 20October2010Wednesday, at 13:47, Richard Shockey wrote: > Well Bill with due respect, the data that most of us would like to use for > this class of application is very static and its sources are very > authoritative. That which is somewhat volatile is easy to sync such as Local > Number Portability data or line status. There is a staggering amount of data > in the field that Infrastructure oriented ENUM works and works well in the > field. Speed and scale were the keys and the desire NOT to have another > protocol stack in mission critical network elements such as the CSCF or SBC > at the edge of the SIP/IMS networks. right... but only rarely in the DNS world do edge nodes actually go hit the authoritative sources. much/most of the time they hit a cache, often one run by a random third party. Now if one presumes DNSSEC signed data, then most of my concerns evaporate. > > But the larger issue is this. When the ENUM WG was rechartered it was > explicit that this class of application was in scope. Now for some > inexplicable reason its out of scope. I want to know why. that is a very good question. the concerns wrt data "bloat" are much less of an issue now than they might have been last century. > > This document is a terrible attempt at an ex post facto architectural > decision that is significantly damaging to those of us who want to make > things in SIP work better. As a practical matter I want to know are all of > these proposals for PSTN metadata, trunk group, SPID, source URI etc are now > out of scope for IETF standardization. Even as private deployments? If so > than the IESG and the IAB should say so explicitly now and not waste our > time in Prague on a BOF that will never be chartered. well... if its done faster/better outside the IETF by an industry group... > > I personally find section 5.1 unusually amusing as if now the IAB wants to > say split-DNS "should be considered harmful". Leakage in to the public DNS > .. geez really. Like what where are the examples of the harm? So who put > ringtones in the DNS :-) oh... leakage into the public DNS means that the root nameservers have to be over-provisioned by a couple orders of magnitude to deal with the crap that should be in private space but leaked out and can't be resolved. Thats a real cost and its handwaived over by most folks. "Someone else will deal w/ it." ringtones? can't say for sure. I know there calculators, games, books, and SSH & HTTP sessions running through the DNS. Ringtones? Piece of Cake. --bill > > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of bill > manning > Sent: Wednesday, October 20, 2010 3:43 PM > To: Richard Shockey > Cc: 'Ray Bellis'; draft-iab-dns-applications@xxxxxxxxxxxxxx; ietf@xxxxxxxx > Subject: Re: draft-iab-dns-applications - clarification re: Send-N > > > > 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf