RE: draft-iab-dns-applications - clarification re: Send-N

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.


"3. The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.

4. The working group will also examine the use of RFC 3761 technology
for storing and delivering other information about services addressed
by E.164 numbers, for example PSTN call routing and signaling data."

As a practical matter the horse has left the barn, mated, now has several
foals. 

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.

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 :-) 

-----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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]