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: [email protected] [mailto:[email protected]] On Behalf Of bill
> manning
> Sent: Wednesday, October 20, 2010 3:43 PM
> To: Richard Shockey
> Cc: 'Ray Bellis'; [email protected]; [email protected]
> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ietf
>
> _______________________________________________
> Ietf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
>
> _______________________________________________
> Ietf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
