Re: draft-iab-dns-applications - clarification re: Send-N
David Conrad wrote: > In the intervening decades, it is probably worthwhile dealing > with the reality that PSTN (and hence E.164) exists. But, why do we have to be bothered by proposals for more efficient processing of the declining and disappearing E.164? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
On Oct 20, 2010, at 5:28 PM, Masataka Ohta wrote: > Richard Shockey wrote: >> So what is your point ..you don't use phone numbers so the rest of the >> planet shouldn't? > > As PSTN will disappear, E.164 will also disappear, because there > will be no PSTN operator to maintain E.164 number space. "In the long run, we're all dead" -- John Maynard Keynes In the intervening decades, it is probably worthwhile dealing with the reality that PSTN (and hence E.164) exists. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Martin Rex wrote: >> The weakest DNS architectural idea is the notion that DNS resolvers are >> untrusted. This is simply wrong. Every DNS resolver performs a trusted role. > > Nope, just the opposite. Name to address translation is meant to > be an extremely lightweight and fast service. DNS has been extremely lightweight, fast and trustable service > Hostnames are NOT supposed to be trusted in any way and it a serious > misconception to think they're trusted. DNS, including but not limited to DNSSEC, has been weakly secure and is as secure as, for example, PSTN function for callees to know callers number, which is trusted upon by most mobile phone users. You can just trust network and domain operators of the Internet, just as you can trust network and E.164 number operators of PSTN. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Exactly, The pre-DNSSEC application architecture for DNS is now obsolete. We have at this point only developed a technical infrastructure for securing DNS responses. Developing the application architecture to leverage that opportunity still lies ahead of us. But even in the new world of DNSSEC with end-to-end authentication, the resolver plays a role that requires trust and thus should be chosen and trusted. On Wed, Oct 20, 2010 at 9:55 PM, Mark Andrews wrote: > > In message <201010210114.o9l1e0mh004...@fs4113.wdf.sap.corp>, Martin Rex > writes > : > > Phillip Hallam-Baker wrote: > > > > > > The weakest DNS architectural idea is the notion that DNS resolvers are > > > untrusted. This is simply wrong. Every DNS resolver performs a trusted > role > > . > > > > Nope, just the opposite. Name to address translation is meant to > > be an extremely lightweight and fast service. > > The DNS is not just name to address translation. > > > Hostnames are NOT supposed to be trusted in any way and it a serious > > misconception to think they're trusted. > > > > If you want to authenticate your peer, use something like an SSH host > key. > > And how do you know you should trust the host key the remote machine > presents? > > > The routing of datagrams on the internet is also untrusted, so any notion > > that a service that translates hostnames into IP-Addresses should be > > trusted is fatally flawed and is totally ignorant about the fundamental > > architecture of the internet. > > > > -Martin > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
In message <201010210114.o9l1e0mh004...@fs4113.wdf.sap.corp>, Martin Rex writes : > Phillip Hallam-Baker wrote: > > > > The weakest DNS architectural idea is the notion that DNS resolvers are > > untrusted. This is simply wrong. Every DNS resolver performs a trusted role > . > > Nope, just the opposite. Name to address translation is meant to > be an extremely lightweight and fast service. The DNS is not just name to address translation. > Hostnames are NOT supposed to be trusted in any way and it a serious > misconception to think they're trusted. > > If you want to authenticate your peer, use something like an SSH host key. And how do you know you should trust the host key the remote machine presents? > The routing of datagrams on the internet is also untrusted, so any notion > that a service that translates hostnames into IP-Addresses should be > trusted is fatally flawed and is totally ignorant about the fundamental > architecture of the internet. > > -Martin > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Phillip Hallam-Baker wrote: > > The weakest DNS architectural idea is the notion that DNS resolvers are > untrusted. This is simply wrong. Every DNS resolver performs a trusted role. Nope, just the opposite. Name to address translation is meant to be an extremely lightweight and fast service. Hostnames are NOT supposed to be trusted in any way and it a serious misconception to think they're trusted. If you want to authenticate your peer, use something like an SSH host key. The routing of datagrams on the internet is also untrusted, so any notion that a service that translates hostnames into IP-Addresses should be trusted is fatally flawed and is totally ignorant about the fundamental architecture of the internet. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Richard Shockey wrote: > So what is your point ..you don't use phone numbers so the rest of the > planet shouldn't? As PSTN will disappear, E.164 will also disappear, because there will be no PSTN operator to maintain E.164 number space. Or, do you think people may keep paying for the maintenance fee for e164.arpa. subtree in addition to maintenance fee for their own domain names? I don't think so. Note that I wrote in my paper for INET2000 that: http://www.isoc.org/inet2000/cdproceedings/4a/4a_3.htm However, it is obvious that the telephone network will be replaced by the Internet, and will eventually disappear. At that time, most of the features of VoIP protocols will become obsolete. and e164.arpa. will be obsolete. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Looking at the rest of the document, I do find that it is written rather oddly. The document essentially says 'the DNS is designed with these assumptions in mind, therefore applications must take these into account'. I would hope that an Internet Architecture Board would look at the features that applications require and propose an architecture to support them. There are some DNS architectural assumptions that cannot be changed. For example, ownership of names must be unambiguous. There cannot be two example.com domains being run by separate parties. But that does not mean that the mappings within that namespace must be universal and context free. The market has abandoned the notion that DNS mappings be global long ago. The weakest DNS architectural idea is the notion that DNS resolvers are untrusted. This is simply wrong. Every DNS resolver performs a trusted role. The failure to recognize this fact in the DNS architecture is an architectural failure of the type I would like to see the IAB saying 'this is wrong, this is bad, this should change'. There is no reason intrinsic to the DNS design that requires hosts to engage in promiscuous resolution. There are obvious health risks to doing so. Deprecating this bad architectural commitment allows many other DNS flaws to be mitigated, the vulnerability to traffic analysis and denial of service, for example. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
On 20October2010Wednesday, at 14:06, David Conrad wrote: > Bill, > > On Oct 20, 2010, at 1:58 PM, bill manning wrote: >> 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. > > I would truly love to see the data you have that backs this up. Pointers? > (Note that this is not rhetorical -- I'm doing some work right now in which > this info would be quite helpful). i can show the auth data I have, the (to me) data from large caches is suggested in places like OARC and elsewhere that suggest caching is a huge factor is the scaling of the DNS. I've been flogging the idea that it would be an excellent idea to correlate data flows between stub/cache/auth servers and maybe have a couple of interested parties. if your doing similar work, we should talk in a more restricted setting. > >> 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. > > I thought the (vast) over-provisioning of the root servers was to cope with > DDoS attacks. this (leaking) is a DDoS... :) -- bill > > Regards, > -drc > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-iab-dns-applications - clarification re: Send-N
> > 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... Well if that is the preference of the IAB and the IESG then so be it. What we need now is clarity on the architectural status for this class of application drafts etc and this document is not providing it. After almost 4 years of ongoing discussion on how to deal with this data in a IP context now we have this "Well guys maybe this isn't such a good idea." ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
On Oct 20, 2010, at 10:47 PM, Richard Shockey wrote: > 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 :-) I am trying to understand where there are misunderstandings and differences in insight. And I think you might have read 5.1 different than intended: It is not trying to speak about data that is leaked from "internal" to "public" DNS installs. But it tries to make a more generic point that solutions that are engineered for environments that are supposed to be closed will leak to the public Internet. With that comes a responsibility to design those solutions and protocols in such a way that they will have the appropriate security, privacy, and scalability properties. ? --Olaf (speaking for myself) Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
I use telephone numbers, but I don't use a dial pad to dial. And I strongly suspect that my mode of use is the norm. Since we are talking about an optimization here, as opposed to a functional capability, I think it rather more important to look at the real requirements and optimize for that case rather than optimize for a mode of use that is rapidly becoming obsolete. On Wed, Oct 20, 2010 at 4:51 PM, Richard Shockey wrote: > So what is your point ..you don’t use phone numbers so the rest of the > planet shouldn’t? > > > > *From:* Phillip Hallam-Baker [mailto:hal...@gmail.com] > *Sent:* Wednesday, October 20, 2010 4:42 PM > *To:* Paul Hoffman > *Cc:* bill manning; Richard Shockey; Ray Bellis; > draft-iab-dns-applicati...@tools.ietf.org; ietf@ietf.org > > *Subject:* Re: draft-iab-dns-applications - clarification re: Send-N > > > > I don't much see the issue here. > > > > Looking at my AT&T records, I have made about 1000 iphone calls in the past > year. Of those less than 50 are to numbers not in my contacts and I probably > dialed half of those using Safari. > > > > Telephone numbers are not going away, but telephone dialing is already a > necessary legacy thing more than a current requirement. > > > > > > At this point I don't think that there are any telephone numbers I dial > from memory. > > > > I think that the underlying problem here is that the crappy POTS handsets > on sale today do not interface to Internet telephony systems well. > > > > This whole problem would go away if Cisco and the other makers of VOIP > bridges worked out that the real market requirement here is for a box that > plugs into an ethernet port and connects to DECT6.0 telephones rather than a > box that plugs into an ethernet port and has telephone wires sticking out > the back. > > > > That way the VOIP system knows how long the telephone number from the phone > book entry. Your basic problem here is that you are losing this information > by converting all your data to the obsolete POTS wire format and back. > > > > Anyone who wants to do that should further realize that what they need to > do is to allow for multiple boxes on the same VOIP connection in a secure > fashion. DECT6.0 does not have the range to cover some houses and for some > reason the pinheads that designed it seem to think that 6 phones is enough > for one house. > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Bill, On Oct 20, 2010, at 1:58 PM, bill manning wrote: > 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. I would truly love to see the data you have that backs this up. Pointers? (Note that this is not rhetorical -- I'm doing some work right now in which this info would be quite helpful). > 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. I thought the (vast) over-provisioning of the root servers was to cope with DDoS attacks. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of bill > manning > Sent: Wednesday, October 20, 2010 3:43 PM > To: Richard Shockey > Cc: 'Ray Bellis'; draft-iab-dns-applicati...@tools.ietf.org; ietf@ietf.org > 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 netwo
RE: draft-iab-dns-applications - clarification re: Send-N
So what is your point ..you don't use phone numbers so the rest of the planet shouldn't? From: Phillip Hallam-Baker [mailto:hal...@gmail.com] Sent: Wednesday, October 20, 2010 4:42 PM To: Paul Hoffman Cc: bill manning; Richard Shockey; Ray Bellis; draft-iab-dns-applicati...@tools.ietf.org; ietf@ietf.org Subject: Re: draft-iab-dns-applications - clarification re: Send-N I don't much see the issue here. Looking at my AT&T records, I have made about 1000 iphone calls in the past year. Of those less than 50 are to numbers not in my contacts and I probably dialed half of those using Safari. Telephone numbers are not going away, but telephone dialing is already a necessary legacy thing more than a current requirement. At this point I don't think that there are any telephone numbers I dial from memory. I think that the underlying problem here is that the crappy POTS handsets on sale today do not interface to Internet telephony systems well. This whole problem would go away if Cisco and the other makers of VOIP bridges worked out that the real market requirement here is for a box that plugs into an ethernet port and connects to DECT6.0 telephones rather than a box that plugs into an ethernet port and has telephone wires sticking out the back. That way the VOIP system knows how long the telephone number from the phone book entry. Your basic problem here is that you are losing this information by converting all your data to the obsolete POTS wire format and back. Anyone who wants to do that should further realize that what they need to do is to allow for multiple boxes on the same VOIP connection in a secure fashion. DECT6.0 does not have the range to cover some houses and for some reason the pinheads that designed it seem to think that 6 phones is enough for one house. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
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 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@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-iab-dns-applications - clarification re: Send-N
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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of bill manning Sent: Wednesday, October 20, 2010 3:43 PM To: Richard Shockey Cc: 'Ray Bellis'; draft-iab-dns-applicati...@tools.ietf.org; ietf@ietf.org 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
I don't much see the issue here. Looking at my AT&T records, I have made about 1000 iphone calls in the past year. Of those less than 50 are to numbers not in my contacts and I probably dialed half of those using Safari. Telephone numbers are not going away, but telephone dialing is already a necessary legacy thing more than a current requirement. At this point I don't think that there are any telephone numbers I dial from memory. I think that the underlying problem here is that the crappy POTS handsets on sale today do not interface to Internet telephony systems well. This whole problem would go away if Cisco and the other makers of VOIP bridges worked out that the real market requirement here is for a box that plugs into an ethernet port and connects to DECT6.0 telephones rather than a box that plugs into an ethernet port and has telephone wires sticking out the back. That way the VOIP system knows how long the telephone number from the phone book entry. Your basic problem here is that you are losing this information by converting all your data to the obsolete POTS wire format and back. Anyone who wants to do that should further realize that what they need to do is to allow for multiple boxes on the same VOIP connection in a secure fashion. DECT6.0 does not have the range to cover some houses and for some reason the pinheads that designed it seem to think that 6 phones is enough for one house. On Wed, Oct 20, 2010 at 4:18 PM, Paul Hoffman wrote: > At 12:43 PM -0700 10/20/10, bill manning 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. > > This line of reasoning is getting old. DNS records have TTLs that are > established at the same time, and in the same interface, as the data itself. > Caching based on TTLs is trivial to do, and devices that do it wrong usually > don't do it at all, which affects long-lived TTLs just as badly. > > If you want to argue "TTL=5 considered harmful", that's fine, but for the > kind of data that is being discussed here (someone's phone number, not > Google's IP address), the operational difference between TTL=3600 and TTL=5 > is lost in the noise. And it's not like the alternative you are hoping they > use, HTTP, is any different with respect to caching, systems that ignore the > TTLs, and so on. > > --Paul Hoffman, Director > --VPN Consortium > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
On Oct 20, 2010, at 1:36 PM, bill manning wrote: > My experiences with cache manipulation suggest there are many > other problems with the existing caching design as used by the DNS. Such as? Thanks, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Paul, if you posit that TTL manipulation is the sole problem w/ caching, then you might be right. My experiences with cache manipulation suggest there are many other problems with the existing caching design as used by the DNS. Your experiences may be different and the assumptions in the draft may include caching behaviours. Based on Richards email, it didn't seem so. --bill On 20October2010Wednesday, at 13:18, Paul Hoffman wrote: > At 12:43 PM -0700 10/20/10, bill manning 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. > > This line of reasoning is getting old. DNS records have TTLs that are > established at the same time, and in the same interface, as the data itself. > Caching based on TTLs is trivial to do, and devices that do it wrong usually > don't do it at all, which affects long-lived TTLs just as badly. > > If you want to argue "TTL=5 considered harmful", that's fine, but for the > kind of data that is being discussed here (someone's phone number, not > Google's IP address), the operational difference between TTL=3600 and TTL=5 > is lost in the noise. And it's not like the alternative you are hoping they > use, HTTP, is any different with respect to caching, systems that ignore the > TTLs, and so on. > > --Paul Hoffman, Director > --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
At 12:43 PM -0700 10/20/10, bill manning 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. This line of reasoning is getting old. DNS records have TTLs that are established at the same time, and in the same interface, as the data itself. Caching based on TTLs is trivial to do, and devices that do it wrong usually don't do it at all, which affects long-lived TTLs just as badly. If you want to argue "TTL=5 considered harmful", that's fine, but for the kind of data that is being discussed here (someone's phone number, not Google's IP address), the operational difference between TTL=3600 and TTL=5 is lost in the noise. And it's not like the alternative you are hoping they use, HTTP, is any different with respect to caching, systems that ignore the TTLs, and so on. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-iab-dns-applications - clarification re: Send-N
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Telechat Review of draft-ietf-netmod-dsdl-map-08
Update: The author communicated with me off-list that he had in fact cleared the co-author removal with the affected parties, so I withdraw that comment. Thanks! Ben. On Oct 18, 2010, at 4:19 PM, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-netmod-dsdl-map-08 > Reviewer: Ben Campbell > Review Date: 18 Oct 2010 > IESG Telechat date: 21 Oct 2010 > > Summary: This draft is ready for publication as a proposed standard. > > This version addresses all of the comments from my review of version 07 at > IETF LC. > > Major Issues: None > > Minor Issues: None > > Nits and Editorial Comments: > > -- The resolution to my comment about invalid author email addresses was to > remove the co-authors, as they are no longer active in the working group. I > have no opinion as to whether that is a good idea or not, and I assume all > involved are okay with it. I merely bring it up to make sure people have > thought about it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Ray Bellis wrote: >> where even telephone switches (thus, telephone operators) do not have >> any knowledge on how many numbers should be dialed. > > It is for this reason that Send-N specifies the _minimum_ number of > required digits, not the exact number. It contradicts with the following description of the draft: With this information, the application is not required to query the DNS every time a new digit is dialed, but can wait to collect sufficient digits to receive a response. That is, the application can wait to collect sufficient digits to know the _minimum_ number means that the application MUST know the minimum number of digit to make such query, even though E.164 structure often changes. Worse, even if the application knows the _minimum_ number, the application MUST make DNS querys for every digit beyond the _minimum_ number, which means negligibly small number of queries could be saved. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
> Such a mechanism simply does not work when: > > > In these > plans, a telephone switch ordinarily cannot anticipate when a dialed > number is complete, as only the terminating customer premise > equipment (typically a private branch exchange) knows how long a > telephone number needs to be. > > where even telephone switches (thus, telephone operators) do not have > any knowledge on how many numbers should be dialed. It is for this reason that Send-N specifies the _minimum_ number of required digits, not the exact number. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-iab-dns-applications - clarification re: Send-N
Ray Bellis wrote: > (http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt) > > Send-N is not only intended for open number plans, it's intended > for use in _any_ plan with variable length telephone numbers. Such a mechanism simply does not work when: In these plans, a telephone switch ordinarily cannot anticipate when a dialed number is complete, as only the terminating customer premise equipment (typically a private branch exchange) knows how long a telephone number needs to be. where even telephone switches (thus, telephone operators) do not have any knowledge on how many numbers should be dialed. > It came out of the proposed specifications for the UK local number > portability database, where E.164 numbers vary from 8 to 12 digits > in length. If the number portability database operated by telephone operators can eve exist, it is impossible that CPEs operated by subscribers determine the length of telephone numbers. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-iab-dns-applications - clarification re: Send-N
Gentlemen, Re: §4.2 of your IAB Draft draft-iab-dns-applications-00: (http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt) Send-N is not only intended for open number plans, it's intended for use in _any_ plan with variable length telephone numbers. It came out of the proposed specifications for the UK local number portability database, where E.164 numbers vary from 8 to 12 digits in length. A typical application for Send-N might be where an analogue phone is attached to a CP-managed SIP ATA - this will be a common setup in "Next Generation Networks". It is a solution to the problem of gatewaying between the 100s of millions of dumb handsets that use overlapped dialling[*] and the SIP world where overlapped dialling is not currently feasible. As an analogue phone has no "dial" button the ATA must listen for DTMF digits, and somehow figure out for itself when the user has finished dialling before initiating the SIP call over the ATA's SIP trunk. A common (but unreliable) method is to use inter-digit timeouts, but the end user experience is poor - it might take the ATA a few seconds to start the SIP session after the last digit is dialled. Assuming that the ATA doesn't do ENUM dips itself, the existing alternative would be for the ATA to establish a brand new SIP session after each digit is dialled, receiving a "484 Address Incomplete" error from the CP switch until the number is complete. With Send-N metadata available, the definition of the SIP "484 Address Incomplete" could be extended to return the Send-N data so that an ATA can benefit from this information and omit unnecessary SIP session establishments. Regarding this sentence: "Maintaining that synchronization, however, requires that the DNS have semi-real time updates that may conflict with scale and caching mechanisms." As Jon pointed out during the ENUM session at Maastricht there is indeed a need to synchronise the metadata with the underlying data. However number plans are not generally prone to sudden unexpected changes. In any event with Send-N the only identified synchronisation issue is when a Send-N record indicates that _more_ digits are required than is actually the case. Since it is very rare (if not unheard of) for number blocks to get smaller I don't consider this a significant risk. The assertion therefore appears to be unjustified. 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. kind regards, Ray [*] the draft misdescribes overlapped dialling - it's the practise of sending digits to the network as they're received rather than "en bloc" at the end of dialling. It's what analogue phones do, and is completely separate from "open number plans". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
