<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_07_199256</id>
	<title>Paul Vixie On What DNS Is Not</title>
	<author>timothy</author>
	<datestamp>1257622200000</datestamp>
	<htmltext>CowboyRobot writes <i>"Paul Vixie (AboveNet, ARIN, ISC, MAPS, PAIX) has a fresh rant titled <a href="http://queue.acm.org/detail.cfm?id=1647302">What DNS Is Not</a> about the abuses of the Domain Name Server system. 'What DNS is not is a mapping service or a mechanism for delivering policy-based information. DNS was designed to express facts, not policies. Because it works so well and is ubiquitous, however, it's all too common for entrepreneurs to see it as a greenfield opportunity ... a few years ago VeriSign, which operates the .COM domain under contract to ICANN, added a "wild card" to the top of the .COM zone (*.COM) so that its authoritative name servers would no longer generate NXDOMAIN responses. Instead they generated responses containing the address of SiteFinder's Web site &mdash; an advertising server.'"</i></htmltext>
<tokenext>CowboyRobot writes " Paul Vixie ( AboveNet , ARIN , ISC , MAPS , PAIX ) has a fresh rant titled What DNS Is Not about the abuses of the Domain Name Server system .
'What DNS is not is a mapping service or a mechanism for delivering policy-based information .
DNS was designed to express facts , not policies .
Because it works so well and is ubiquitous , however , it 's all too common for entrepreneurs to see it as a greenfield opportunity ... a few years ago VeriSign , which operates the .COM domain under contract to ICANN , added a " wild card " to the top of the .COM zone ( * .COM ) so that its authoritative name servers would no longer generate NXDOMAIN responses .
Instead they generated responses containing the address of SiteFinder 's Web site    an advertising server .
' "</tokentext>
<sentencetext>CowboyRobot writes "Paul Vixie (AboveNet, ARIN, ISC, MAPS, PAIX) has a fresh rant titled What DNS Is Not about the abuses of the Domain Name Server system.
'What DNS is not is a mapping service or a mechanism for delivering policy-based information.
DNS was designed to express facts, not policies.
Because it works so well and is ubiquitous, however, it's all too common for entrepreneurs to see it as a greenfield opportunity ... a few years ago VeriSign, which operates the .COM domain under contract to ICANN, added a "wild card" to the top of the .COM zone (*.COM) so that its authoritative name servers would no longer generate NXDOMAIN responses.
Instead they generated responses containing the address of SiteFinder's Web site — an advertising server.
'"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016440</id>
	<title>This is a good opportunity to say...</title>
	<author>Interoperable</author>
	<datestamp>1257585120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Fuck you Bell! Give me my NXDOMAIN back.</htmltext>
<tokenext>Fuck you Bell !
Give me my NXDOMAIN back .</tokentext>
<sentencetext>Fuck you Bell!
Give me my NXDOMAIN back.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017256</id>
	<title>Re:Breaking the standards to implement policy</title>
	<author>Anonymous</author>
	<datestamp>1257593220000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Nonsense, SPF does absolutely nothing to stop spam. In fact, because spammers have jumped on the SPF bandwagon pronto, the presence of an SPF record is a reasonable indicator that the message in question might be spam.</p></htmltext>
<tokenext>Nonsense , SPF does absolutely nothing to stop spam .
In fact , because spammers have jumped on the SPF bandwagon pronto , the presence of an SPF record is a reasonable indicator that the message in question might be spam .</tokentext>
<sentencetext>Nonsense, SPF does absolutely nothing to stop spam.
In fact, because spammers have jumped on the SPF bandwagon pronto, the presence of an SPF record is a reasonable indicator that the message in question might be spam.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018614</id>
	<title>DNS is also not an inventory system</title>
	<author>Anonymous</author>
	<datestamp>1257607080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I see too many organizations using DNS as an inventory system (e.g prtsertor01) resulting in host names more difficult to remember than IP addresses.</p></htmltext>
<tokenext>I see too many organizations using DNS as an inventory system ( e.g prtsertor01 ) resulting in host names more difficult to remember than IP addresses .</tokentext>
<sentencetext>I see too many organizations using DNS as an inventory system (e.g prtsertor01) resulting in host names more difficult to remember than IP addresses.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018296</id>
	<title>Re:what it is becoming</title>
	<author>Anonymous</author>
	<datestamp>1257603240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Came here to say this. Mod parent up.</p><p>DNS provides a mechanism to request a mapping from Name -&gt; Numerical IP. Not a lot more, nothing less.</p><p>Saying the crap they're pulling with it is "not DNS" is just a lie.</p></htmltext>
<tokenext>Came here to say this .
Mod parent up.DNS provides a mechanism to request a mapping from Name - &gt; Numerical IP .
Not a lot more , nothing less.Saying the crap they 're pulling with it is " not DNS " is just a lie .</tokentext>
<sentencetext>Came here to say this.
Mod parent up.DNS provides a mechanism to request a mapping from Name -&gt; Numerical IP.
Not a lot more, nothing less.Saying the crap they're pulling with it is "not DNS" is just a lie.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30024752</id>
	<title>Confusing what is with what we'd like it to be</title>
	<author>mcrbids</author>
	<datestamp>1257672300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly. Like what Paul said about DNS. A clause like "a nameserver MUST responde truthfully, if technically possible. DNS responses MUST NOT be modified in any way for political, economic or business reasons."</i></p><p>I invite you to write the RFC. It's easy to do, and basically, anybody can write an RFC. There's the <a href="http://www.faqs.org/rfcs/rfc3514.html" title="faqs.org">infamous evil bit</a> [faqs.org] for example. But here's the thing... RFCs are just that: <b>R</b>equests <b>F</b>or <b>C</b>comment. They don't have any teeth, even if they are frequently referred to. For example, I looked directly at the RFCs in order to develop an SMTP handler a few years back...</p><p>There IS an <a href="http://www.isoc.org/standards/orgs.shtml" title="isoc.org">"Internet Standards Organization"</a> [isoc.org] or three, and they <b>do</b> often "adopt" an RFC to be an "Internet Standard", but if you look, you'll find that there's no enforcement arm whatsoever! It's up to you, the Internet participant, to require/enforce these standards. And just like the explosion in unregulated 802.11 networking, the Internet's power comes from this completely open, unregulated nature.</p><p>Sure, there's a wart or ten. Sorry, that's just how it is. I can name a few others:</p><p>1) Large ISPs often ignore the TTL values in name servers and set them to as long as 48 hours. This makes moving servers from location A to location B fraught with hacks, such as putting in a NAT router at the old location to forward traffic to the old "wrong" address to the new "right" one.</p><p>2) Mail servers that often don't bounce undeliverable messages, just passing them to<nobr> <wbr></nobr>/dev/null.</p><p>3) "Tricks" played by IE to make it seem "faster" by not negotiating a proper connection to the webserver.</p><p>Yes, all of these, (and more!) are highly annoying, but the truth is that violations of standards can't be all that flagrant, or the system breaks and people get upset. So overall, the system works remarkably well.</p><p>Can you imagine what would have happened if the Internet didn't happen and we ended up going with AOL's proprietary network?</p><p>(shudder)</p></htmltext>
<tokenext>Maybe it 's time that the Internet standards get a few clauses added that express these concepts explicitly .
Like what Paul said about DNS .
A clause like " a nameserver MUST responde truthfully , if technically possible .
DNS responses MUST NOT be modified in any way for political , economic or business reasons .
" I invite you to write the RFC .
It 's easy to do , and basically , anybody can write an RFC .
There 's the infamous evil bit [ faqs.org ] for example .
But here 's the thing... RFCs are just that : Requests For Ccomment .
They do n't have any teeth , even if they are frequently referred to .
For example , I looked directly at the RFCs in order to develop an SMTP handler a few years back...There IS an " Internet Standards Organization " [ isoc.org ] or three , and they do often " adopt " an RFC to be an " Internet Standard " , but if you look , you 'll find that there 's no enforcement arm whatsoever !
It 's up to you , the Internet participant , to require/enforce these standards .
And just like the explosion in unregulated 802.11 networking , the Internet 's power comes from this completely open , unregulated nature.Sure , there 's a wart or ten .
Sorry , that 's just how it is .
I can name a few others : 1 ) Large ISPs often ignore the TTL values in name servers and set them to as long as 48 hours .
This makes moving servers from location A to location B fraught with hacks , such as putting in a NAT router at the old location to forward traffic to the old " wrong " address to the new " right " one.2 ) Mail servers that often do n't bounce undeliverable messages , just passing them to /dev/null.3 ) " Tricks " played by IE to make it seem " faster " by not negotiating a proper connection to the webserver.Yes , all of these , ( and more !
) are highly annoying , but the truth is that violations of standards ca n't be all that flagrant , or the system breaks and people get upset .
So overall , the system works remarkably well.Can you imagine what would have happened if the Internet did n't happen and we ended up going with AOL 's proprietary network ?
( shudder )</tokentext>
<sentencetext>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly.
Like what Paul said about DNS.
A clause like "a nameserver MUST responde truthfully, if technically possible.
DNS responses MUST NOT be modified in any way for political, economic or business reasons.
"I invite you to write the RFC.
It's easy to do, and basically, anybody can write an RFC.
There's the infamous evil bit [faqs.org] for example.
But here's the thing... RFCs are just that: Requests For Ccomment.
They don't have any teeth, even if they are frequently referred to.
For example, I looked directly at the RFCs in order to develop an SMTP handler a few years back...There IS an "Internet Standards Organization" [isoc.org] or three, and they do often "adopt" an RFC to be an "Internet Standard", but if you look, you'll find that there's no enforcement arm whatsoever!
It's up to you, the Internet participant, to require/enforce these standards.
And just like the explosion in unregulated 802.11 networking, the Internet's power comes from this completely open, unregulated nature.Sure, there's a wart or ten.
Sorry, that's just how it is.
I can name a few others:1) Large ISPs often ignore the TTL values in name servers and set them to as long as 48 hours.
This makes moving servers from location A to location B fraught with hacks, such as putting in a NAT router at the old location to forward traffic to the old "wrong" address to the new "right" one.2) Mail servers that often don't bounce undeliverable messages, just passing them to /dev/null.3) "Tricks" played by IE to make it seem "faster" by not negotiating a proper connection to the webserver.Yes, all of these, (and more!
) are highly annoying, but the truth is that violations of standards can't be all that flagrant, or the system breaks and people get upset.
So overall, the system works remarkably well.Can you imagine what would have happened if the Internet didn't happen and we ended up going with AOL's proprietary network?
(shudder)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016598</id>
	<title>The two examples don't seem anything alike ...</title>
	<author>Anonymous</author>
	<datestamp>1257586800000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Ok, we all agree that funneling NXDOMAIN responses to your advertising portal is wrong. It's evil, manipulative, blah blah, not going to defend it.</p><p>What really bothers me is his rationale for the first example -- using DNS responses to properly route content to the right node in your CDN. Sure, it increases the "floor" request time by eliminating cached response closer to the user, but it also greatly decreases the average request time by serving the content from the nearest node. It seems to me like it's a huge net win for the total amount of network traffic -- you lose by having a whole lot of extra (tiny) DNS requests and cache-misses but you win huge by having Microsoft's latest service pack (many MB) traverse the smallest possible number of hops.</p><p>His second complaint, that this is somehow lawsuit-fodder, is ridiculous on its face. Akamai works incredibly well for content providers that don't want to invest in lots of redundant distribution resources. They have every incentive to outsource it to a company that will provide the users with a much faster experience and virtually nothing to lose. Most users will give up on a website if it can't serve their requests in a reasonable amount of time and I don't see a revolution in user patience about to happen.</p><p>Finally, his "solution" -- that CDNs rely on dumb ("psuedorandom" is his fancy was of saying dumb) assignment of users to distribution nodes -- is a huge step backwards. It would mean more stress on the long-haul fiber for absolutely no good reason as requests were served geographically distance from their origin. By the way, it's interesting that he labels his dumb response "truthful", as if Akamai <b>lied</b> when they assign me to a different node than my Australian buddy because we live half a globe apart? That's ridiculous. We each asked for a server that can give us www.amd.com, we got a damn truthful answer. In fact, we each got the <i>best</i> possible answer we could. That's not lying, it's giving each of us a finer-grained optimal answer than we would have received under his lame suggestion.</p><p>Please don't confuse his (for the forgoing reasons, silly) rant against CDNs with his rightful indignation at NXDOMAIN redirects. They are totally different animals.</p></htmltext>
<tokenext>Ok , we all agree that funneling NXDOMAIN responses to your advertising portal is wrong .
It 's evil , manipulative , blah blah , not going to defend it.What really bothers me is his rationale for the first example -- using DNS responses to properly route content to the right node in your CDN .
Sure , it increases the " floor " request time by eliminating cached response closer to the user , but it also greatly decreases the average request time by serving the content from the nearest node .
It seems to me like it 's a huge net win for the total amount of network traffic -- you lose by having a whole lot of extra ( tiny ) DNS requests and cache-misses but you win huge by having Microsoft 's latest service pack ( many MB ) traverse the smallest possible number of hops.His second complaint , that this is somehow lawsuit-fodder , is ridiculous on its face .
Akamai works incredibly well for content providers that do n't want to invest in lots of redundant distribution resources .
They have every incentive to outsource it to a company that will provide the users with a much faster experience and virtually nothing to lose .
Most users will give up on a website if it ca n't serve their requests in a reasonable amount of time and I do n't see a revolution in user patience about to happen.Finally , his " solution " -- that CDNs rely on dumb ( " psuedorandom " is his fancy was of saying dumb ) assignment of users to distribution nodes -- is a huge step backwards .
It would mean more stress on the long-haul fiber for absolutely no good reason as requests were served geographically distance from their origin .
By the way , it 's interesting that he labels his dumb response " truthful " , as if Akamai lied when they assign me to a different node than my Australian buddy because we live half a globe apart ?
That 's ridiculous .
We each asked for a server that can give us www.amd.com , we got a damn truthful answer .
In fact , we each got the best possible answer we could .
That 's not lying , it 's giving each of us a finer-grained optimal answer than we would have received under his lame suggestion.Please do n't confuse his ( for the forgoing reasons , silly ) rant against CDNs with his rightful indignation at NXDOMAIN redirects .
They are totally different animals .</tokentext>
<sentencetext>Ok, we all agree that funneling NXDOMAIN responses to your advertising portal is wrong.
It's evil, manipulative, blah blah, not going to defend it.What really bothers me is his rationale for the first example -- using DNS responses to properly route content to the right node in your CDN.
Sure, it increases the "floor" request time by eliminating cached response closer to the user, but it also greatly decreases the average request time by serving the content from the nearest node.
It seems to me like it's a huge net win for the total amount of network traffic -- you lose by having a whole lot of extra (tiny) DNS requests and cache-misses but you win huge by having Microsoft's latest service pack (many MB) traverse the smallest possible number of hops.His second complaint, that this is somehow lawsuit-fodder, is ridiculous on its face.
Akamai works incredibly well for content providers that don't want to invest in lots of redundant distribution resources.
They have every incentive to outsource it to a company that will provide the users with a much faster experience and virtually nothing to lose.
Most users will give up on a website if it can't serve their requests in a reasonable amount of time and I don't see a revolution in user patience about to happen.Finally, his "solution" -- that CDNs rely on dumb ("psuedorandom" is his fancy was of saying dumb) assignment of users to distribution nodes -- is a huge step backwards.
It would mean more stress on the long-haul fiber for absolutely no good reason as requests were served geographically distance from their origin.
By the way, it's interesting that he labels his dumb response "truthful", as if Akamai lied when they assign me to a different node than my Australian buddy because we live half a globe apart?
That's ridiculous.
We each asked for a server that can give us www.amd.com, we got a damn truthful answer.
In fact, we each got the best possible answer we could.
That's not lying, it's giving each of us a finer-grained optimal answer than we would have received under his lame suggestion.Please don't confuse his (for the forgoing reasons, silly) rant against CDNs with his rightful indignation at NXDOMAIN redirects.
They are totally different animals.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016744</id>
	<title>News to me</title>
	<author>Anonymous</author>
	<datestamp>1257588240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Browser implementers including Microsoft and Mozilla have begun doing DNS queries while collecting URIs from their graphical front end in order to do fancy "auto-completion." This means that during the typing time of a URI such as http://www.cnn.com/, the browser will have asked questions such as W, WW, WWW, WWW.C, WWW.CN, WWW.CNN, and so on. It's not quite that bad, since the browsers have a precompiled idea of what the top-level domains are. They won't actually ask for WWW.C, for example, but they are now asking for WWW.CN, which is in China, and WWW.CNN.CO, which is in Colombia.</p></div><p>Which browsers actually do this? Is Mozilla actually participating in that nonsense?</p></div>
	</htmltext>
<tokenext>Browser implementers including Microsoft and Mozilla have begun doing DNS queries while collecting URIs from their graphical front end in order to do fancy " auto-completion .
" This means that during the typing time of a URI such as http : //www.cnn.com/ , the browser will have asked questions such as W , WW , WWW , WWW.C , WWW.CN , WWW.CNN , and so on .
It 's not quite that bad , since the browsers have a precompiled idea of what the top-level domains are .
They wo n't actually ask for WWW.C , for example , but they are now asking for WWW.CN , which is in China , and WWW.CNN.CO , which is in Colombia.Which browsers actually do this ?
Is Mozilla actually participating in that nonsense ?</tokentext>
<sentencetext>Browser implementers including Microsoft and Mozilla have begun doing DNS queries while collecting URIs from their graphical front end in order to do fancy "auto-completion.
" This means that during the typing time of a URI such as http://www.cnn.com/, the browser will have asked questions such as W, WW, WWW, WWW.C, WWW.CN, WWW.CNN, and so on.
It's not quite that bad, since the browsers have a precompiled idea of what the top-level domains are.
They won't actually ask for WWW.C, for example, but they are now asking for WWW.CN, which is in China, and WWW.CNN.CO, which is in Colombia.Which browsers actually do this?
Is Mozilla actually participating in that nonsense?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016936</id>
	<title>Re:competition</title>
	<author>Sir\_Lewk</author>
	<datestamp>1257589920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://en.wikipedia.org/wiki/Alternative\_DNS\_root" title="wikipedia.org">Such things exist.</a> [wikipedia.org]  Nobody uses them.</p></htmltext>
<tokenext>Such things exist .
[ wikipedia.org ] Nobody uses them .</tokentext>
<sentencetext>Such things exist.
[wikipedia.org]  Nobody uses them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016312</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30038496</id>
	<title>Which Bell?  Canada? South?  Other?</title>
	<author>billstewart</author>
	<datestamp>1257762360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm not saying there aren't lots of reasons to be upset with just about any phone company, but which one are you upset at?</p></htmltext>
<tokenext>I 'm not saying there are n't lots of reasons to be upset with just about any phone company , but which one are you upset at ?</tokentext>
<sentencetext>I'm not saying there aren't lots of reasons to be upset with just about any phone company, but which one are you upset at?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016440</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016354</id>
	<title>Re:not only Verisign</title>
	<author>sopssa</author>
	<datestamp>1257627300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly. Like what Paul said about DNS. A clause like "a nameserver MUST responde truthfully, if technically possible. DNS responses MUST NOT be modified in any way for political, economic or business reasons."</p><p>Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.</p></div><p>I doubt it still would go anywhere in court. It's not like it's illegal to break RFC's and protocol standards on services you provide to your customers, who have opted-in and bought them. You <i>might</i> have a case if they blocked using other DNS servers, but they dont. And if they included a part in contract that says you're only allowed to use their DNS server (like they say for email port 25), you don't have a case with that either.</p><p>btw, this thing seems to only be a problem in USA too - they're not doing anything like that here, only interfere from ISP is that they block outgoing email to port 25.</p></div>
	</htmltext>
<tokenext>Maybe it 's time that the Internet standards get a few clauses added that express these concepts explicitly .
Like what Paul said about DNS .
A clause like " a nameserver MUST responde truthfully , if technically possible .
DNS responses MUST NOT be modified in any way for political , economic or business reasons .
" Then these fucked up ISPs would at least be in violation of a standard , which might give me what I need for a violation-of-contract suit.I doubt it still would go anywhere in court .
It 's not like it 's illegal to break RFC 's and protocol standards on services you provide to your customers , who have opted-in and bought them .
You might have a case if they blocked using other DNS servers , but they dont .
And if they included a part in contract that says you 're only allowed to use their DNS server ( like they say for email port 25 ) , you do n't have a case with that either.btw , this thing seems to only be a problem in USA too - they 're not doing anything like that here , only interfere from ISP is that they block outgoing email to port 25 .</tokentext>
<sentencetext>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly.
Like what Paul said about DNS.
A clause like "a nameserver MUST responde truthfully, if technically possible.
DNS responses MUST NOT be modified in any way for political, economic or business reasons.
"Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.I doubt it still would go anywhere in court.
It's not like it's illegal to break RFC's and protocol standards on services you provide to your customers, who have opted-in and bought them.
You might have a case if they blocked using other DNS servers, but they dont.
And if they included a part in contract that says you're only allowed to use their DNS server (like they say for email port 25), you don't have a case with that either.btw, this thing seems to only be a problem in USA too - they're not doing anything like that here, only interfere from ISP is that they block outgoing email to port 25.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016270</id>
	<title>Sorry we didn't stay in your box</title>
	<author>Anonymous</author>
	<datestamp>1257626340000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>Isn't it funny how some parents can't seem to let go after the child has grown, especially when they greatly exceed expectation?</htmltext>
<tokenext>Is n't it funny how some parents ca n't seem to let go after the child has grown , especially when they greatly exceed expectation ?</tokentext>
<sentencetext>Isn't it funny how some parents can't seem to let go after the child has grown, especially when they greatly exceed expectation?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412</id>
	<title>what it is becoming</title>
	<author>phantomfive</author>
	<datestamp>1257584820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>Looks like this article is more about, "what DNS is becoming but I don't like."  He may not like it, but that's what's happening with DNS.<br> <br>
Not that I particularly like it either, but then I wasn't too happy when the word 'hacker' changed to mean 'someone who breaks into your computer.'  Nor was I particularly happy about masquerading becoming a popular routing technique, instead of switching to IPv6.  And yet, that's what happened. Sometimes technologies are twisted in ways you don't intend or like.</htmltext>
<tokenext>Looks like this article is more about , " what DNS is becoming but I do n't like .
" He may not like it , but that 's what 's happening with DNS .
Not that I particularly like it either , but then I was n't too happy when the word 'hacker ' changed to mean 'someone who breaks into your computer .
' Nor was I particularly happy about masquerading becoming a popular routing technique , instead of switching to IPv6 .
And yet , that 's what happened .
Sometimes technologies are twisted in ways you do n't intend or like .</tokentext>
<sentencetext>Looks like this article is more about, "what DNS is becoming but I don't like.
"  He may not like it, but that's what's happening with DNS.
Not that I particularly like it either, but then I wasn't too happy when the word 'hacker' changed to mean 'someone who breaks into your computer.
'  Nor was I particularly happy about masquerading becoming a popular routing technique, instead of switching to IPv6.
And yet, that's what happened.
Sometimes technologies are twisted in ways you don't intend or like.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016494</id>
	<title>Paging Kaminsky</title>
	<author>Gothmolly</author>
	<datestamp>1257585660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'll listen to Vixie once he justifies the Kaminsky bug.</p></htmltext>
<tokenext>I 'll listen to Vixie once he justifies the Kaminsky bug .</tokentext>
<sentencetext>I'll listen to Vixie once he justifies the Kaminsky bug.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016426</id>
	<title>Re:not only Verisign</title>
	<author>Anonymous</author>
	<datestamp>1257584940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.</i></p><p><i>Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.</i></p><p>Well, you already have cause for your lawsuit - marketing. These ISPs advertise internet connections, and DNS is part of internet service.</p><p>If their DNS isn't working, then you can sue for false advertising.</p></htmltext>
<tokenext>Then these fucked up ISPs would at least be in violation of a standard , which might give me what I need for a violation-of-contract suit.Remember : These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.Well , you already have cause for your lawsuit - marketing .
These ISPs advertise internet connections , and DNS is part of internet service.If their DNS is n't working , then you can sue for false advertising .</tokentext>
<sentencetext>Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.Well, you already have cause for your lawsuit - marketing.
These ISPs advertise internet connections, and DNS is part of internet service.If their DNS isn't working, then you can sue for false advertising.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</id>
	<title>not only Verisign</title>
	<author>Anonymous</author>
	<datestamp>1257626400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Many ISPs do it as well. Right now, my ISP does it, even though I've opted out. Maybe one of these days I'll sue them.</p><p>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly. Like what Paul said about DNS. A clause like "a nameserver MUST responde truthfully, if technically possible. DNS responses MUST NOT be modified in any way for political, economic or business reasons."</p><p>Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.</p><p>Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.</p></htmltext>
<tokenext>Many ISPs do it as well .
Right now , my ISP does it , even though I 've opted out .
Maybe one of these days I 'll sue them.Maybe it 's time that the Internet standards get a few clauses added that express these concepts explicitly .
Like what Paul said about DNS .
A clause like " a nameserver MUST responde truthfully , if technically possible .
DNS responses MUST NOT be modified in any way for political , economic or business reasons .
" Then these fucked up ISPs would at least be in violation of a standard , which might give me what I need for a violation-of-contract suit.Remember : These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people .</tokentext>
<sentencetext>Many ISPs do it as well.
Right now, my ISP does it, even though I've opted out.
Maybe one of these days I'll sue them.Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly.
Like what Paul said about DNS.
A clause like "a nameserver MUST responde truthfully, if technically possible.
DNS responses MUST NOT be modified in any way for political, economic or business reasons.
"Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020320</id>
	<title>Re:Breaking the standards to implement policy</title>
	<author>dodobh</author>
	<datestamp>1257679980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>SPF breaks forwarding. Oh, and SPF itself does nothing much to help stop spam.</p></htmltext>
<tokenext>SPF breaks forwarding .
Oh , and SPF itself does nothing much to help stop spam .</tokentext>
<sentencetext>SPF breaks forwarding.
Oh, and SPF itself does nothing much to help stop spam.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016328</id>
	<title>Re:not only Verisign</title>
	<author>Zerth</author>
	<datestamp>1257627120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And that's why a cheap, low-power computer or hackable router is awesome.  Just run your own nameserver.</p><p>My ISP isn't horrible, but they hijack DNS with a "friendly" error message when there is more than a little network congestion, which sticks until the cache is flushed.  That was enough to get me to stop using their server.</p></htmltext>
<tokenext>And that 's why a cheap , low-power computer or hackable router is awesome .
Just run your own nameserver.My ISP is n't horrible , but they hijack DNS with a " friendly " error message when there is more than a little network congestion , which sticks until the cache is flushed .
That was enough to get me to stop using their server .</tokentext>
<sentencetext>And that's why a cheap, low-power computer or hackable router is awesome.
Just run your own nameserver.My ISP isn't horrible, but they hijack DNS with a "friendly" error message when there is more than a little network congestion, which sticks until the cache is flushed.
That was enough to get me to stop using their server.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016228</id>
	<title>frist</title>
	<author>Anonymous</author>
	<datestamp>1257625980000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>psot</p></htmltext>
<tokenext>psot</tokentext>
<sentencetext>psot</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460</id>
	<title>Breaking the standards to implement policy</title>
	<author>Anonymous</author>
	<datestamp>1257585300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Breaking the standards to implement policy is a good thing sometimes. Take SPF records for example: if they were to become widespread, then spam could very easily be reduced by probably 99\%.</p></htmltext>
<tokenext>Breaking the standards to implement policy is a good thing sometimes .
Take SPF records for example : if they were to become widespread , then spam could very easily be reduced by probably 99 \ % .</tokentext>
<sentencetext>Breaking the standards to implement policy is a good thing sometimes.
Take SPF records for example: if they were to become widespread, then spam could very easily be reduced by probably 99\%.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30019606</id>
	<title>Re:not only Verisign</title>
	<author>secolactico</author>
	<datestamp>1257621780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly</p></div></blockquote><p>And that would be enforced, how?</p></div>
	</htmltext>
<tokenext>Maybe it 's time that the Internet standards get a few clauses added that express these concepts explicitlyAnd that would be enforced , how ?</tokentext>
<sentencetext>Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitlyAnd that would be enforced, how?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016794</id>
	<title>Re:not only Verisign</title>
	<author>Anonymous</author>
	<datestamp>1257588660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Marketing people know what you wan't, you don't. Simple as that.</p></htmltext>
<tokenext>Marketing people know what you wa n't , you do n't .
Simple as that .</tokentext>
<sentencetext>Marketing people know what you wan't, you don't.
Simple as that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016948</id>
	<title>Re:Breaking the standards to implement policy</title>
	<author>DaveGillam</author>
	<datestamp>1257589980000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>SPF, SenderID, and DKIM are not spam-fighting techniques.  They are forgery-fighting techniques.  Some spammers use SPF and SenderID records to give their spam a higher sense of legitimacy.  A spammer cannot forge "paypal.com" because Paypal publishes SPF records.  A spammer CAN pretend to be Paypal by using a look-alike domain with its own set of SPF records (ie: paypall.com, paypal.org).  SPF and SenderID simply publish what IPs are authorized to send email claiming to be from a particular domain.  DKIM does essentially the same thing, but is arguably better since it uses a cryptographic mechanism to assure the message in question was not appreciably altered in transit.</htmltext>
<tokenext>SPF , SenderID , and DKIM are not spam-fighting techniques .
They are forgery-fighting techniques .
Some spammers use SPF and SenderID records to give their spam a higher sense of legitimacy .
A spammer can not forge " paypal.com " because Paypal publishes SPF records .
A spammer CAN pretend to be Paypal by using a look-alike domain with its own set of SPF records ( ie : paypall.com , paypal.org ) .
SPF and SenderID simply publish what IPs are authorized to send email claiming to be from a particular domain .
DKIM does essentially the same thing , but is arguably better since it uses a cryptographic mechanism to assure the message in question was not appreciably altered in transit .</tokentext>
<sentencetext>SPF, SenderID, and DKIM are not spam-fighting techniques.
They are forgery-fighting techniques.
Some spammers use SPF and SenderID records to give their spam a higher sense of legitimacy.
A spammer cannot forge "paypal.com" because Paypal publishes SPF records.
A spammer CAN pretend to be Paypal by using a look-alike domain with its own set of SPF records (ie: paypall.com, paypal.org).
SPF and SenderID simply publish what IPs are authorized to send email claiming to be from a particular domain.
DKIM does essentially the same thing, but is arguably better since it uses a cryptographic mechanism to assure the message in question was not appreciably altered in transit.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017142</id>
	<title>Re:The two examples don't seem anything alike ...</title>
	<author>Anonymous</author>
	<datestamp>1257591960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The point is that CDN via DNS doesn't work well because the IP that is used for the query is NOT the end user client, but instead another client that acts as a DNS server for the end user. I have had this argument before. The techniques are at best spotty for CDN.</p></htmltext>
<tokenext>The point is that CDN via DNS does n't work well because the IP that is used for the query is NOT the end user client , but instead another client that acts as a DNS server for the end user .
I have had this argument before .
The techniques are at best spotty for CDN .</tokentext>
<sentencetext>The point is that CDN via DNS doesn't work well because the IP that is used for the query is NOT the end user client, but instead another client that acts as a DNS server for the end user.
I have had this argument before.
The techniques are at best spotty for CDN.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016598</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020124</id>
	<title>Re:not only Verisign</title>
	<author>Anonymous</author>
	<datestamp>1257676560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>If I found a way to exploit DNS further or any other part of the net and was able to get rich from it, I'd do it in a heartbeat.</p></div><p>Well, fuck you too, asshole.</p><p><div class="quote"><p>And so would most of you, too.</p></div><p>Is that the reason why you feel being an asshole is ok? A presumption that everyone else is just as evil as you are?</p><p>Well, fuck you, <b>again</b>, you little dipshit.</p><p>There is a thing called ethics. It can be combined with a sound and effective business strategy and implemented as a real and functioning business ethics. Some of us practice it. You obviously don't.</p><p>Thus: You are a fucking asshole. Fuck you.</p></div>
	</htmltext>
<tokenext>If I found a way to exploit DNS further or any other part of the net and was able to get rich from it , I 'd do it in a heartbeat.Well , fuck you too , asshole.And so would most of you , too.Is that the reason why you feel being an asshole is ok ?
A presumption that everyone else is just as evil as you are ? Well , fuck you , again , you little dipshit.There is a thing called ethics .
It can be combined with a sound and effective business strategy and implemented as a real and functioning business ethics .
Some of us practice it .
You obviously do n't.Thus : You are a fucking asshole .
Fuck you .</tokentext>
<sentencetext>If I found a way to exploit DNS further or any other part of the net and was able to get rich from it, I'd do it in a heartbeat.Well, fuck you too, asshole.And so would most of you, too.Is that the reason why you feel being an asshole is ok?
A presumption that everyone else is just as evil as you are?Well, fuck you, again, you little dipshit.There is a thing called ethics.
It can be combined with a sound and effective business strategy and implemented as a real and functioning business ethics.
Some of us practice it.
You obviously don't.Thus: You are a fucking asshole.
Fuck you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016350</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492</id>
	<title>CDNs are good thing</title>
	<author>Anonymous</author>
	<datestamp>1257585600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>While I totally agree that overriding NXDOMAIN responses is evil, returning different DNS responses based on the clients location or for load balancing purposes is an extremely useful technique for last companies serving a large amount of web traffic. For example, check out what www.google.com resolves to from different countries or even at different times - depending on where you look it up from and what network links are up, you will get a different set of IPs.</p><p>Sure, determining a browser's location from the DNS client source IP is not totally reliable<nobr> <wbr></nobr>.. but it is accurate enough to significantly improve user-visible responsiveness by avoiding un-necessary cross-planet network traffic. And even if google gets it wrong, they are no worse off than if they never implemented this in the first place.</p></htmltext>
<tokenext>While I totally agree that overriding NXDOMAIN responses is evil , returning different DNS responses based on the clients location or for load balancing purposes is an extremely useful technique for last companies serving a large amount of web traffic .
For example , check out what www.google.com resolves to from different countries or even at different times - depending on where you look it up from and what network links are up , you will get a different set of IPs.Sure , determining a browser 's location from the DNS client source IP is not totally reliable .. but it is accurate enough to significantly improve user-visible responsiveness by avoiding un-necessary cross-planet network traffic .
And even if google gets it wrong , they are no worse off than if they never implemented this in the first place .</tokentext>
<sentencetext>While I totally agree that overriding NXDOMAIN responses is evil, returning different DNS responses based on the clients location or for load balancing purposes is an extremely useful technique for last companies serving a large amount of web traffic.
For example, check out what www.google.com resolves to from different countries or even at different times - depending on where you look it up from and what network links are up, you will get a different set of IPs.Sure, determining a browser's location from the DNS client source IP is not totally reliable .. but it is accurate enough to significantly improve user-visible responsiveness by avoiding un-necessary cross-planet network traffic.
And even if google gets it wrong, they are no worse off than if they never implemented this in the first place.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30022572</id>
	<title>Re:DNS is also not an inventory system</title>
	<author>Anonymous</author>
	<datestamp>1257701160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>... (e.g prtsertor01)<nobr> <wbr></nobr>...</p> </div><p>A print server on the Tor onion network?  That's <i>some</i> anonymous printing!</p></div>
	</htmltext>
<tokenext>... ( e.g prtsertor01 ) ... A print server on the Tor onion network ?
That 's some anonymous printing !</tokentext>
<sentencetext> ... (e.g prtsertor01) ... A print server on the Tor onion network?
That's some anonymous printing!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020402</id>
	<title>Re:what it is becoming</title>
	<author>TheRaven64</author>
	<datestamp>1257681420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>I think you're missing his point.  It's easy to do, because he does hide it quite well behind a large wall of text.  DNS, as Vixie (awesome name) rightly says, should be a cacheable mapping.  The result should depend on the query and nothing else.  It should not depend on who your ISP is.  It should not depend on your geographical location.  If you do a DNS lookup from your computer, you should get exactly the same result that I get from my computer at the same time, irrespective of where we both are in the network topology.  This is a fundamental aspect of DNS and lots of software has been written on top of the assumption that this is how DNS works.  Changing this is going to break things in fun and exciting ways.
</p><p>
A real-time block list is a perfectly acceptable use of DNS.  It maps from a domain name to some information, in this case whether the IP is a known spammer.  Putting geolocation information and telephone numbers into DNS are also valid uses.  They express facts that don't change depending on who is asking for them.  The page is a bit confusing because he uses 'policy' to mean 'information that depends on who is asking'.  A better word would be 'propaganda'.
</p><p>
By the way, he also makes the point that domain names should be written the other way around if you want autocompletion (e.g. org.slashdot.tech).  It's worth noting that the Joint Academic Network (JANET) in the UK did write them this way around, which meant things like tab-completion of hostnames could work nicely.  It was forced to change because the rest of the world was writing them the wrong way around.</p></htmltext>
<tokenext>I think you 're missing his point .
It 's easy to do , because he does hide it quite well behind a large wall of text .
DNS , as Vixie ( awesome name ) rightly says , should be a cacheable mapping .
The result should depend on the query and nothing else .
It should not depend on who your ISP is .
It should not depend on your geographical location .
If you do a DNS lookup from your computer , you should get exactly the same result that I get from my computer at the same time , irrespective of where we both are in the network topology .
This is a fundamental aspect of DNS and lots of software has been written on top of the assumption that this is how DNS works .
Changing this is going to break things in fun and exciting ways .
A real-time block list is a perfectly acceptable use of DNS .
It maps from a domain name to some information , in this case whether the IP is a known spammer .
Putting geolocation information and telephone numbers into DNS are also valid uses .
They express facts that do n't change depending on who is asking for them .
The page is a bit confusing because he uses 'policy ' to mean 'information that depends on who is asking' .
A better word would be 'propaganda' .
By the way , he also makes the point that domain names should be written the other way around if you want autocompletion ( e.g .
org.slashdot.tech ) . It 's worth noting that the Joint Academic Network ( JANET ) in the UK did write them this way around , which meant things like tab-completion of hostnames could work nicely .
It was forced to change because the rest of the world was writing them the wrong way around .</tokentext>
<sentencetext>I think you're missing his point.
It's easy to do, because he does hide it quite well behind a large wall of text.
DNS, as Vixie (awesome name) rightly says, should be a cacheable mapping.
The result should depend on the query and nothing else.
It should not depend on who your ISP is.
It should not depend on your geographical location.
If you do a DNS lookup from your computer, you should get exactly the same result that I get from my computer at the same time, irrespective of where we both are in the network topology.
This is a fundamental aspect of DNS and lots of software has been written on top of the assumption that this is how DNS works.
Changing this is going to break things in fun and exciting ways.
A real-time block list is a perfectly acceptable use of DNS.
It maps from a domain name to some information, in this case whether the IP is a known spammer.
Putting geolocation information and telephone numbers into DNS are also valid uses.
They express facts that don't change depending on who is asking for them.
The page is a bit confusing because he uses 'policy' to mean 'information that depends on who is asking'.
A better word would be 'propaganda'.
By the way, he also makes the point that domain names should be written the other way around if you want autocompletion (e.g.
org.slashdot.tech).  It's worth noting that the Joint Academic Network (JANET) in the UK did write them this way around, which meant things like tab-completion of hostnames could work nicely.
It was forced to change because the rest of the world was writing them the wrong way around.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018224</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018214</id>
	<title>Did TFA do ANY fact-checking?</title>
	<author>SanityInAnarchy</author>
	<datestamp>1257602400000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just in the first paragraph:</p><p><div class="quote"><p>DNS (Domain Name System) is a hierarchical, distributed, <b>autonomous</b>, reliable database.</p></div><p>How is it autonomous? Or at least, how is it more autonomous than any other database, certainly any database which meets the other three criteria?</p><p><div class="quote"><p>The first and only of its kind,</p></div><p>Sorry, no. Maybe the first, but it's certainly not the only. There are many other databases which offer distributed, reliable storage, and at least one I can think of which is hierarchical.</p><p><div class="quote"><p>it offers realtime performance levels</p></div><p>Realtime? Are you sure?</p><p>I mean, aside from slow DNS servers, there's the fact that while reads may be realtime, updates are anything but. Just try changing IPs and watch how long it takes the change to propagate. Real databases measure this kind of thing in seconds or minutes -- DNS measures it in days.</p><p><div class="quote"><p>Every TCP/IP traffic flow including every World Wide Web page view begins with at least one DNS transaction.</p></div><p>Bullshit. Want proof? Buy a Linksys router and hit http://192.168.1.1/ to configure it. Well, look at that! No DNS needed!</p><p>There are indeed people who run webpages off of IPs.</p><p>Alright, I didn't have to rip it apart that much, and maybe I'm nitpicking. But come on, the number of things which are <b>simply wrong</b> is staggering -- the BS-to-word-count ratio is quite high.</p><p>Do I want to read the rest of the article?</p><p>Maybe. It seems much cleaner and more accurate than that first paragraph, but it wouldn't have been that hard, especially for a guy with those credentials, to get it right.</p></div>
	</htmltext>
<tokenext>Just in the first paragraph : DNS ( Domain Name System ) is a hierarchical , distributed , autonomous , reliable database.How is it autonomous ?
Or at least , how is it more autonomous than any other database , certainly any database which meets the other three criteria ? The first and only of its kind,Sorry , no .
Maybe the first , but it 's certainly not the only .
There are many other databases which offer distributed , reliable storage , and at least one I can think of which is hierarchical.it offers realtime performance levelsRealtime ?
Are you sure ? I mean , aside from slow DNS servers , there 's the fact that while reads may be realtime , updates are anything but .
Just try changing IPs and watch how long it takes the change to propagate .
Real databases measure this kind of thing in seconds or minutes -- DNS measures it in days.Every TCP/IP traffic flow including every World Wide Web page view begins with at least one DNS transaction.Bullshit .
Want proof ?
Buy a Linksys router and hit http : //192.168.1.1/ to configure it .
Well , look at that !
No DNS needed ! There are indeed people who run webpages off of IPs.Alright , I did n't have to rip it apart that much , and maybe I 'm nitpicking .
But come on , the number of things which are simply wrong is staggering -- the BS-to-word-count ratio is quite high.Do I want to read the rest of the article ? Maybe .
It seems much cleaner and more accurate than that first paragraph , but it would n't have been that hard , especially for a guy with those credentials , to get it right .</tokentext>
<sentencetext>Just in the first paragraph:DNS (Domain Name System) is a hierarchical, distributed, autonomous, reliable database.How is it autonomous?
Or at least, how is it more autonomous than any other database, certainly any database which meets the other three criteria?The first and only of its kind,Sorry, no.
Maybe the first, but it's certainly not the only.
There are many other databases which offer distributed, reliable storage, and at least one I can think of which is hierarchical.it offers realtime performance levelsRealtime?
Are you sure?I mean, aside from slow DNS servers, there's the fact that while reads may be realtime, updates are anything but.
Just try changing IPs and watch how long it takes the change to propagate.
Real databases measure this kind of thing in seconds or minutes -- DNS measures it in days.Every TCP/IP traffic flow including every World Wide Web page view begins with at least one DNS transaction.Bullshit.
Want proof?
Buy a Linksys router and hit http://192.168.1.1/ to configure it.
Well, look at that!
No DNS needed!There are indeed people who run webpages off of IPs.Alright, I didn't have to rip it apart that much, and maybe I'm nitpicking.
But come on, the number of things which are simply wrong is staggering -- the BS-to-word-count ratio is quite high.Do I want to read the rest of the article?Maybe.
It seems much cleaner and more accurate than that first paragraph, but it wouldn't have been that hard, especially for a guy with those credentials, to get it right.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30024122</id>
	<title>This is a classic problem - with a classic answer</title>
	<author>Anonymous</author>
	<datestamp>1257711120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is a classic "closed stacks library problem"</p><p>The correct answer is that, where today there is one DNS request, in order to cope with this level of fraud there will need to be dozens/thousands of requests by resolvers to name servers. From these many duplicate requests, a most likely answer will be selected (and returned to the client) and name servers that disagree will be referred to a public reputation sharing system as "Liars". All caching will become local - a preemptive resolving daemon if you will.</p><p>additional levels of "consumer fraud detection" daemons can be layered on top this kind of service - I expect any ISP with a bad rep to suffer an immense amount of traffic from it's clients trying to determine whether the service they were sold is actually being provided.</p><p>oh, and sorry about all that extra traffic ISP - but it's your f^ckup - you deserve it.</p></htmltext>
<tokenext>This is a classic " closed stacks library problem " The correct answer is that , where today there is one DNS request , in order to cope with this level of fraud there will need to be dozens/thousands of requests by resolvers to name servers .
From these many duplicate requests , a most likely answer will be selected ( and returned to the client ) and name servers that disagree will be referred to a public reputation sharing system as " Liars " .
All caching will become local - a preemptive resolving daemon if you will.additional levels of " consumer fraud detection " daemons can be layered on top this kind of service - I expect any ISP with a bad rep to suffer an immense amount of traffic from it 's clients trying to determine whether the service they were sold is actually being provided.oh , and sorry about all that extra traffic ISP - but it 's your f ^ ckup - you deserve it .</tokentext>
<sentencetext>This is a classic "closed stacks library problem"The correct answer is that, where today there is one DNS request, in order to cope with this level of fraud there will need to be dozens/thousands of requests by resolvers to name servers.
From these many duplicate requests, a most likely answer will be selected (and returned to the client) and name servers that disagree will be referred to a public reputation sharing system as "Liars".
All caching will become local - a preemptive resolving daemon if you will.additional levels of "consumer fraud detection" daemons can be layered on top this kind of service - I expect any ISP with a bad rep to suffer an immense amount of traffic from it's clients trying to determine whether the service they were sold is actually being provided.oh, and sorry about all that extra traffic ISP - but it's your f^ckup - you deserve it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016316</id>
	<title>Re:not only Verisign</title>
	<author>prochefort</author>
	<datestamp>1257627000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Here in Toronto, Rogers does this on a routine basis. Tried to get them to stop this sh*t but the person onthe phone was either too thick to understand or simply didn't care enough. Sucks really bad. Rogers used to be this great company but they are sinking to new lows every day.</p></htmltext>
<tokenext>Here in Toronto , Rogers does this on a routine basis .
Tried to get them to stop this sh * t but the person onthe phone was either too thick to understand or simply did n't care enough .
Sucks really bad .
Rogers used to be this great company but they are sinking to new lows every day .</tokentext>
<sentencetext>Here in Toronto, Rogers does this on a routine basis.
Tried to get them to stop this sh*t but the person onthe phone was either too thick to understand or simply didn't care enough.
Sucks really bad.
Rogers used to be this great company but they are sinking to new lows every day.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017050</id>
	<title>Re:The two examples don't seem anything alike ...</title>
	<author>Anonymous</author>
	<datestamp>1257591240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Unfortunately, you are treating these as totally different animals when they are not.  He is opposed to using DNS to redirect traffic which is a reasonable statement.  NXDOMAIN and CDN's are both related to redirecting responses.  He did not say he is against hosting content close to the request.  There are other ways to solve that need.</p></htmltext>
<tokenext>Unfortunately , you are treating these as totally different animals when they are not .
He is opposed to using DNS to redirect traffic which is a reasonable statement .
NXDOMAIN and CDN 's are both related to redirecting responses .
He did not say he is against hosting content close to the request .
There are other ways to solve that need .</tokentext>
<sentencetext>Unfortunately, you are treating these as totally different animals when they are not.
He is opposed to using DNS to redirect traffic which is a reasonable statement.
NXDOMAIN and CDN's are both related to redirecting responses.
He did not say he is against hosting content close to the request.
There are other ways to solve that need.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016598</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017680</id>
	<title>IP over DNS</title>
	<author>nemesisrocks</author>
	<datestamp>1257597420000</datestamp>
	<modclass>None</modclass>
	<modscore>2</modscore>
	<htmltext>Is everyone here forgetting IP over DNS?  How else would I get free internet at paid wifi access points??</htmltext>
<tokenext>Is everyone here forgetting IP over DNS ?
How else would I get free internet at paid wifi access points ?
?</tokentext>
<sentencetext>Is everyone here forgetting IP over DNS?
How else would I get free internet at paid wifi access points?
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016350</id>
	<title>Re:not only Verisign</title>
	<author>Anonymous</author>
	<datestamp>1257627300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><i>Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.</i> <p>Every technological marketing gimick that has been invented was the result of some techie wanting to get rich quick (or kiss up to his boss) and I don't blame them. If I found a way to exploit DNS further or any other part of the net and was able to get rich from it, I'd do it in a heartbeat. </p><p>And so would most of you, too.</p></htmltext>
<tokenext>Remember : These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people .
Every technological marketing gimick that has been invented was the result of some techie wanting to get rich quick ( or kiss up to his boss ) and I do n't blame them .
If I found a way to exploit DNS further or any other part of the net and was able to get rich from it , I 'd do it in a heartbeat .
And so would most of you , too .</tokentext>
<sentencetext>Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.
Every technological marketing gimick that has been invented was the result of some techie wanting to get rich quick (or kiss up to his boss) and I don't blame them.
If I found a way to exploit DNS further or any other part of the net and was able to get rich from it, I'd do it in a heartbeat.
And so would most of you, too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30021034</id>
	<title>Re:what it is becoming</title>
	<author>jgrahn</author>
	<datestamp>1257690960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Looks like this article is more about, "what DNS is becoming but I don't like." He may not like it, but that's what's happening with DNS.
</p><p>
Not that I particularly like it either, but then I wasn't too happy when the word 'hacker' changed to mean 'someone who breaks into your computer.' [...] Sometimes technologies are twisted in ways you don't intend or like.</p></div></blockquote><p>
So you're saying he should shut up and learn to like it?
</p><p>
Part of his point is, if we let it go this way, we'll lose the opportunity to do other nifty stuff.
He explicitly mentioned a conflict between lying DNS and secure DNS.
I can't see anything wrong with pointing out such things --
especially since the vast majority of Internet users would agree with him.
Noone likes to get ad-ridden crap pages when they should have gotten
a "name or service not known" error message.</p></div>
	</htmltext>
<tokenext>Looks like this article is more about , " what DNS is becoming but I do n't like .
" He may not like it , but that 's what 's happening with DNS .
Not that I particularly like it either , but then I was n't too happy when the word 'hacker ' changed to mean 'someone who breaks into your computer .
' [ ... ] Sometimes technologies are twisted in ways you do n't intend or like .
So you 're saying he should shut up and learn to like it ?
Part of his point is , if we let it go this way , we 'll lose the opportunity to do other nifty stuff .
He explicitly mentioned a conflict between lying DNS and secure DNS .
I ca n't see anything wrong with pointing out such things -- especially since the vast majority of Internet users would agree with him .
Noone likes to get ad-ridden crap pages when they should have gotten a " name or service not known " error message .</tokentext>
<sentencetext>Looks like this article is more about, "what DNS is becoming but I don't like.
" He may not like it, but that's what's happening with DNS.
Not that I particularly like it either, but then I wasn't too happy when the word 'hacker' changed to mean 'someone who breaks into your computer.
' [...] Sometimes technologies are twisted in ways you don't intend or like.
So you're saying he should shut up and learn to like it?
Part of his point is, if we let it go this way, we'll lose the opportunity to do other nifty stuff.
He explicitly mentioned a conflict between lying DNS and secure DNS.
I can't see anything wrong with pointing out such things --
especially since the vast majority of Internet users would agree with him.
Noone likes to get ad-ridden crap pages when they should have gotten
a "name or service not known" error message.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016802</id>
	<title>Re:CDNs are good thing</title>
	<author>QuantumRiff</author>
	<datestamp>1257588720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>He argues that the problem is, the client doesn't usually hit the DNS server, the clients DNS server only does after it expires its own local cache.</p><p>Just because your ISP's DNS servers are sitting in LA, doesn't mean you are.  You could be on Seattle, and using those DNS servers, or out in the world, on the work VPN, using their DNS server in downtown Chicago.  Thats how many people get around regional restrictions now, in fact.</p><p>People have shoehorned DNS into something that it is neither Efficient, or designed to do.</p></htmltext>
<tokenext>He argues that the problem is , the client does n't usually hit the DNS server , the clients DNS server only does after it expires its own local cache.Just because your ISP 's DNS servers are sitting in LA , does n't mean you are .
You could be on Seattle , and using those DNS servers , or out in the world , on the work VPN , using their DNS server in downtown Chicago .
Thats how many people get around regional restrictions now , in fact.People have shoehorned DNS into something that it is neither Efficient , or designed to do .</tokentext>
<sentencetext>He argues that the problem is, the client doesn't usually hit the DNS server, the clients DNS server only does after it expires its own local cache.Just because your ISP's DNS servers are sitting in LA, doesn't mean you are.
You could be on Seattle, and using those DNS servers, or out in the world, on the work VPN, using their DNS server in downtown Chicago.
Thats how many people get around regional restrictions now, in fact.People have shoehorned DNS into something that it is neither Efficient, or designed to do.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016248</id>
	<title>them dollar</title>
	<author>Anonymous</author>
	<datestamp>1257626220000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>0</modscore>
	<htmltext>Well Paul, in this world it all depends on how much money you throw at it.</htmltext>
<tokenext>Well Paul , in this world it all depends on how much money you throw at it .</tokentext>
<sentencetext>Well Paul, in this world it all depends on how much money you throw at it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020480</id>
	<title>Re:CDNs are good thing</title>
	<author>kegon</author>
	<datestamp>1257682980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>Sure, determining a browser's location from the DNS client source IP is not totally reliable<nobr> <wbr></nobr>.. but it is accurate enough to significantly improve user-visible responsiveness</p></div></blockquote><p>I disagree.</p><p>Getting the <b>wrong</b> web page is not helpful. For example, go to Japan and look up some big name website, e.g. google.com and you get it localized into Japanese. I didn't want google.co.jp, I wanted google.com. How does DNS know what language I speak ?</p><p>Many, many times I tried to look up the website of a big American or European company while in Japan and I could only get the the Japanese language version. No matter which page I tried to get brain dead websites trust DNS absolutely and always redirect to a Japanese language page. Japanese friends have these same problems all the time. One friend wanted to buy something from an American company and get it shipped but he simply couldn't check out the specification because they had closed their local operation and all requests originating from Japan were redirected to the local website apologizing for closing their local store.</p><p>These examples are not isolated; users in other countries must suffer similar problems. Stop abusing DNS is the answer.</p></div>
	</htmltext>
<tokenext>Sure , determining a browser 's location from the DNS client source IP is not totally reliable .. but it is accurate enough to significantly improve user-visible responsivenessI disagree.Getting the wrong web page is not helpful .
For example , go to Japan and look up some big name website , e.g .
google.com and you get it localized into Japanese .
I did n't want google.co.jp , I wanted google.com .
How does DNS know what language I speak ? Many , many times I tried to look up the website of a big American or European company while in Japan and I could only get the the Japanese language version .
No matter which page I tried to get brain dead websites trust DNS absolutely and always redirect to a Japanese language page .
Japanese friends have these same problems all the time .
One friend wanted to buy something from an American company and get it shipped but he simply could n't check out the specification because they had closed their local operation and all requests originating from Japan were redirected to the local website apologizing for closing their local store.These examples are not isolated ; users in other countries must suffer similar problems .
Stop abusing DNS is the answer .</tokentext>
<sentencetext>Sure, determining a browser's location from the DNS client source IP is not totally reliable .. but it is accurate enough to significantly improve user-visible responsivenessI disagree.Getting the wrong web page is not helpful.
For example, go to Japan and look up some big name website, e.g.
google.com and you get it localized into Japanese.
I didn't want google.co.jp, I wanted google.com.
How does DNS know what language I speak ?Many, many times I tried to look up the website of a big American or European company while in Japan and I could only get the the Japanese language version.
No matter which page I tried to get brain dead websites trust DNS absolutely and always redirect to a Japanese language page.
Japanese friends have these same problems all the time.
One friend wanted to buy something from an American company and get it shipped but he simply couldn't check out the specification because they had closed their local operation and all requests originating from Japan were redirected to the local website apologizing for closing their local store.These examples are not isolated; users in other countries must suffer similar problems.
Stop abusing DNS is the answer.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018338</id>
	<title>Protocols evolve</title>
	<author>Anonymous</author>
	<datestamp>1257603660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Protocols evolve and to new stuff that the original designers didn't think of. That is just the way it is. DNS does not have to be inline to be able to enforce a policy. This makes it inexpensive for service providers to implement "value added services" in DNS. The alternative is to do it with DPI boxes from Allot, Procera or Cisco and sit inline. I rather have some NXDOMAIN responses that I can opt out from, than somebody that sniffs on all my traffic.</p><p>Mr Vixie should know that service providers don't listen to what the hell IETF, ARIN and other non profit organizations have to say. And I agree with other comments here as well, him sitting on the Advisory Board for Nominum is disturbing. I have never heard anybody saying anything good about Nominum since they helped with the development of Bind 9 about 10 years ago.<nobr> <wbr></nobr>/Mr.75</p></htmltext>
<tokenext>Protocols evolve and to new stuff that the original designers did n't think of .
That is just the way it is .
DNS does not have to be inline to be able to enforce a policy .
This makes it inexpensive for service providers to implement " value added services " in DNS .
The alternative is to do it with DPI boxes from Allot , Procera or Cisco and sit inline .
I rather have some NXDOMAIN responses that I can opt out from , than somebody that sniffs on all my traffic.Mr Vixie should know that service providers do n't listen to what the hell IETF , ARIN and other non profit organizations have to say .
And I agree with other comments here as well , him sitting on the Advisory Board for Nominum is disturbing .
I have never heard anybody saying anything good about Nominum since they helped with the development of Bind 9 about 10 years ago .
/Mr.75</tokentext>
<sentencetext>Protocols evolve and to new stuff that the original designers didn't think of.
That is just the way it is.
DNS does not have to be inline to be able to enforce a policy.
This makes it inexpensive for service providers to implement "value added services" in DNS.
The alternative is to do it with DPI boxes from Allot, Procera or Cisco and sit inline.
I rather have some NXDOMAIN responses that I can opt out from, than somebody that sniffs on all my traffic.Mr Vixie should know that service providers don't listen to what the hell IETF, ARIN and other non profit organizations have to say.
And I agree with other comments here as well, him sitting on the Advisory Board for Nominum is disturbing.
I have never heard anybody saying anything good about Nominum since they helped with the development of Bind 9 about 10 years ago.
/Mr.75</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017246</id>
	<title>facts</title>
	<author>epine</author>
	<datestamp>1257593040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Interesting echo from <a href="http://www.monotone.ca/wiki/FAQ/" title="monotone.ca">FAQ</a> [monotone.ca] which I read the other night.  The original contains a lot of italic I'm not going to replicate.</p><blockquote><div><p>An important fact about monotone's networking is that it deals in facts rather than operations. Networking simply informs the other party of some facts, and receives some facts from the other party. The netsync protocol determines which facts to send, based on an interactive analysis of "what is missing" on each end. No obligations, transactions, or commitments are made during networking. For all non-networking functions, monotone decides what to do by interpreting the facts it has on hand, rather than having specific conversations with other programs.</p></div></blockquote><p>The closer one lives to the foundation, the stronger the argument for a fact-based architecture.  DNS is about as foundational as one can get in internet security.  Interesting, the architecture of monotone is highly cryptographic, and somewhat reminiscent of DNSSEC from the 40,000 foot view.</p><p>The people who don't see the problem with mixing fact and policy are likely the same people who don't regard it as a big problem that your credit card numbers is widely distributed in plain text: to every vendor you do business with, many of their employees, the trash collectors out back, and their governing union.</p><p>Why is it that some guy on the GPS thread complained that the police are free to criminalize driving under the age of 18 (to collect more revenue) and effectively act as their own judge, jury, and executioner (in the corrupt towns where this practice becomes established), but there is generally less complaint about VISA architecting themselves the same powers?</p><p>If the police collected a 2\% slice of gasoline revenues and awarded bonus points for trips to Hawaii in any year where you keep your license clear and generally found other clever ways to rebate unpenalized drivers the 2\% (with enough hidden strings attached it doesn't ultimately cost them much), would they be as loved as the VISA company?  Just asking.</p><p><a href="http://www.ted.com/talks/dan\_ariely\_asks\_are\_we\_in\_control\_of\_our\_own\_decisions.html" title="ted.com">Dan Ariely asks, Are we in control of our own decisions?</a> [ted.com]</p><p>Turns out it depends on how you frame the question.  If the question is: do you want the DNS system to become so badly abused it might as well have been designed by a bank, you might get one answer.  If the question is: do you want DNS optimized so your porn streams with ten seconds less delay between clips, you probably get the other answer.</p><p>I vote for facts.  That said, I will say one thing in defense of Akamai: one can construe CDN as a fact based system, if the factoids you are dealing in that "this IP address can deliver the content you want".  Ideally, you already have a secure hash signature of the file you're seeking so it can't play too many games with the notion of "the file you want".</p><p>I don't see why DNS needs the facts to be so low level as "this is the same IP address everyone else gets for the same query".  There could be a good reason, but Vixie's excellent article fell short of providing it.</p><p>Ideally, the CDN problem would have been solved with another layer of delegation: the content you are seeking can be obtained from a vast array of different places, here's an authoritative address for a highly overloaded server; if you're in a hurry go talk to xxx.xxx.xxx.xxx to find a location near you.  Then the caching proxy can send a request with the header "I represent a client in the Pacific Northwest" rather than sending back to the client the name of the video store where client's attorney rents his own porn.</p></div>
	</htmltext>
<tokenext>Interesting echo from FAQ [ monotone.ca ] which I read the other night .
The original contains a lot of italic I 'm not going to replicate.An important fact about monotone 's networking is that it deals in facts rather than operations .
Networking simply informs the other party of some facts , and receives some facts from the other party .
The netsync protocol determines which facts to send , based on an interactive analysis of " what is missing " on each end .
No obligations , transactions , or commitments are made during networking .
For all non-networking functions , monotone decides what to do by interpreting the facts it has on hand , rather than having specific conversations with other programs.The closer one lives to the foundation , the stronger the argument for a fact-based architecture .
DNS is about as foundational as one can get in internet security .
Interesting , the architecture of monotone is highly cryptographic , and somewhat reminiscent of DNSSEC from the 40,000 foot view.The people who do n't see the problem with mixing fact and policy are likely the same people who do n't regard it as a big problem that your credit card numbers is widely distributed in plain text : to every vendor you do business with , many of their employees , the trash collectors out back , and their governing union.Why is it that some guy on the GPS thread complained that the police are free to criminalize driving under the age of 18 ( to collect more revenue ) and effectively act as their own judge , jury , and executioner ( in the corrupt towns where this practice becomes established ) , but there is generally less complaint about VISA architecting themselves the same powers ? If the police collected a 2 \ % slice of gasoline revenues and awarded bonus points for trips to Hawaii in any year where you keep your license clear and generally found other clever ways to rebate unpenalized drivers the 2 \ % ( with enough hidden strings attached it does n't ultimately cost them much ) , would they be as loved as the VISA company ?
Just asking.Dan Ariely asks , Are we in control of our own decisions ?
[ ted.com ] Turns out it depends on how you frame the question .
If the question is : do you want the DNS system to become so badly abused it might as well have been designed by a bank , you might get one answer .
If the question is : do you want DNS optimized so your porn streams with ten seconds less delay between clips , you probably get the other answer.I vote for facts .
That said , I will say one thing in defense of Akamai : one can construe CDN as a fact based system , if the factoids you are dealing in that " this IP address can deliver the content you want " .
Ideally , you already have a secure hash signature of the file you 're seeking so it ca n't play too many games with the notion of " the file you want " .I do n't see why DNS needs the facts to be so low level as " this is the same IP address everyone else gets for the same query " .
There could be a good reason , but Vixie 's excellent article fell short of providing it.Ideally , the CDN problem would have been solved with another layer of delegation : the content you are seeking can be obtained from a vast array of different places , here 's an authoritative address for a highly overloaded server ; if you 're in a hurry go talk to xxx.xxx.xxx.xxx to find a location near you .
Then the caching proxy can send a request with the header " I represent a client in the Pacific Northwest " rather than sending back to the client the name of the video store where client 's attorney rents his own porn .</tokentext>
<sentencetext>Interesting echo from FAQ [monotone.ca] which I read the other night.
The original contains a lot of italic I'm not going to replicate.An important fact about monotone's networking is that it deals in facts rather than operations.
Networking simply informs the other party of some facts, and receives some facts from the other party.
The netsync protocol determines which facts to send, based on an interactive analysis of "what is missing" on each end.
No obligations, transactions, or commitments are made during networking.
For all non-networking functions, monotone decides what to do by interpreting the facts it has on hand, rather than having specific conversations with other programs.The closer one lives to the foundation, the stronger the argument for a fact-based architecture.
DNS is about as foundational as one can get in internet security.
Interesting, the architecture of monotone is highly cryptographic, and somewhat reminiscent of DNSSEC from the 40,000 foot view.The people who don't see the problem with mixing fact and policy are likely the same people who don't regard it as a big problem that your credit card numbers is widely distributed in plain text: to every vendor you do business with, many of their employees, the trash collectors out back, and their governing union.Why is it that some guy on the GPS thread complained that the police are free to criminalize driving under the age of 18 (to collect more revenue) and effectively act as their own judge, jury, and executioner (in the corrupt towns where this practice becomes established), but there is generally less complaint about VISA architecting themselves the same powers?If the police collected a 2\% slice of gasoline revenues and awarded bonus points for trips to Hawaii in any year where you keep your license clear and generally found other clever ways to rebate unpenalized drivers the 2\% (with enough hidden strings attached it doesn't ultimately cost them much), would they be as loved as the VISA company?
Just asking.Dan Ariely asks, Are we in control of our own decisions?
[ted.com]Turns out it depends on how you frame the question.
If the question is: do you want the DNS system to become so badly abused it might as well have been designed by a bank, you might get one answer.
If the question is: do you want DNS optimized so your porn streams with ten seconds less delay between clips, you probably get the other answer.I vote for facts.
That said, I will say one thing in defense of Akamai: one can construe CDN as a fact based system, if the factoids you are dealing in that "this IP address can deliver the content you want".
Ideally, you already have a secure hash signature of the file you're seeking so it can't play too many games with the notion of "the file you want".I don't see why DNS needs the facts to be so low level as "this is the same IP address everyone else gets for the same query".
There could be a good reason, but Vixie's excellent article fell short of providing it.Ideally, the CDN problem would have been solved with another layer of delegation: the content you are seeking can be obtained from a vast array of different places, here's an authoritative address for a highly overloaded server; if you're in a hurry go talk to xxx.xxx.xxx.xxx to find a location near you.
Then the caching proxy can send a request with the header "I represent a client in the Pacific Northwest" rather than sending back to the client the name of the video store where client's attorney rents his own porn.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020682</id>
	<title>He is absolutly right !</title>
	<author>FrankDerKte</author>
	<datestamp>1257685980000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>It all comes down to thrust. If my ISP changes the answers of the root server for non existing adresses how do I know they don't do it for other adresses, too ? And if they use something like deep packet inspection to select my DNS requests and redirect them to their server, it's actually a man in the middle attack. Also known as DSN spoofing and used by many criminals to collect all sorts of information.</p><p>Seriously, we have to stop taking crap from those return of investment and cash flow management idiots, who think they can change the way everything works, because they own the infrastructure.</p><p>As slashdotters seem to like car analogies, would anyone of you use a navigation system which would give you any directions for not existing streets ? I would throw it out of my car.</p><p>Probably I should write a script which just asks for a bogus URL every ms. Also it would follow every link on this site. Let's see for how long this practice is being used if every DNS request is answered by a web site and all their advertisement contractors have to pay for "clicks" by a stoopid script ?</p></htmltext>
<tokenext>It all comes down to thrust .
If my ISP changes the answers of the root server for non existing adresses how do I know they do n't do it for other adresses , too ?
And if they use something like deep packet inspection to select my DNS requests and redirect them to their server , it 's actually a man in the middle attack .
Also known as DSN spoofing and used by many criminals to collect all sorts of information.Seriously , we have to stop taking crap from those return of investment and cash flow management idiots , who think they can change the way everything works , because they own the infrastructure.As slashdotters seem to like car analogies , would anyone of you use a navigation system which would give you any directions for not existing streets ?
I would throw it out of my car.Probably I should write a script which just asks for a bogus URL every ms. Also it would follow every link on this site .
Let 's see for how long this practice is being used if every DNS request is answered by a web site and all their advertisement contractors have to pay for " clicks " by a stoopid script ?</tokentext>
<sentencetext>It all comes down to thrust.
If my ISP changes the answers of the root server for non existing adresses how do I know they don't do it for other adresses, too ?
And if they use something like deep packet inspection to select my DNS requests and redirect them to their server, it's actually a man in the middle attack.
Also known as DSN spoofing and used by many criminals to collect all sorts of information.Seriously, we have to stop taking crap from those return of investment and cash flow management idiots, who think they can change the way everything works, because they own the infrastructure.As slashdotters seem to like car analogies, would anyone of you use a navigation system which would give you any directions for not existing streets ?
I would throw it out of my car.Probably I should write a script which just asks for a bogus URL every ms. Also it would follow every link on this site.
Let's see for how long this practice is being used if every DNS request is answered by a web site and all their advertisement contractors have to pay for "clicks" by a stoopid script ?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017264</id>
	<title>Re:Sorry we didn't stay in your box</title>
	<author>MightyMartian</author>
	<datestamp>1257593280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>But he has a point.  DNS is very good at what it does, but when companies start mucking about with it, it's reliability becomes much more questionable.  In the<nobr> <wbr></nobr>.com fiasco we had the DNS clearly abused with severe repercussions for general wide-scale network stability.</p></htmltext>
<tokenext>But he has a point .
DNS is very good at what it does , but when companies start mucking about with it , it 's reliability becomes much more questionable .
In the .com fiasco we had the DNS clearly abused with severe repercussions for general wide-scale network stability .</tokentext>
<sentencetext>But he has a point.
DNS is very good at what it does, but when companies start mucking about with it, it's reliability becomes much more questionable.
In the .com fiasco we had the DNS clearly abused with severe repercussions for general wide-scale network stability.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016270</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016312</id>
	<title>competition</title>
	<author>bugs2squash</author>
	<datestamp>1257627000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Maybe it's time for someone to set up a DNS system in competition to ICANN.

I don't think it's impossible to change your root servers list.</htmltext>
<tokenext>Maybe it 's time for someone to set up a DNS system in competition to ICANN .
I do n't think it 's impossible to change your root servers list .</tokentext>
<sentencetext>Maybe it's time for someone to set up a DNS system in competition to ICANN.
I don't think it's impossible to change your root servers list.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018224</id>
	<title>Re:what it is becoming</title>
	<author>Anonymous</author>
	<datestamp>1257602580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Looks like this article is more about, "what DNS is becoming but I don't like."</p></div></blockquote><p>What DNS is not is a mapping service or a mechanism for delivering policy-based information. DNS was designed to express facts, not policies.</p><p>Erm.. didn't Paul create MAPS to explicitly provide - and later monetize - the RBL? Wasn't the RBL a "directory service"? Didn't it map IPs to policy-based information?</p><p>I agree with the point he's <i>trying</i> to make; I hate NXDOMAIN hijacks too. I don't get the rant about CDNs, though; seems to me that as long as they're controlled by the domain owner, not a man-in-the-middle, there's no particular distinction between a CDN and plain old round-robin load-balancing.</p><p>Yep. It's just a rant on "ways to use DNS that Paul Vixie doesn't like".</p></div>
	</htmltext>
<tokenext>Looks like this article is more about , " what DNS is becoming but I do n't like .
" What DNS is not is a mapping service or a mechanism for delivering policy-based information .
DNS was designed to express facts , not policies.Erm.. did n't Paul create MAPS to explicitly provide - and later monetize - the RBL ?
Was n't the RBL a " directory service " ?
Did n't it map IPs to policy-based information ? I agree with the point he 's trying to make ; I hate NXDOMAIN hijacks too .
I do n't get the rant about CDNs , though ; seems to me that as long as they 're controlled by the domain owner , not a man-in-the-middle , there 's no particular distinction between a CDN and plain old round-robin load-balancing.Yep .
It 's just a rant on " ways to use DNS that Paul Vixie does n't like " .</tokentext>
<sentencetext>Looks like this article is more about, "what DNS is becoming but I don't like.
"What DNS is not is a mapping service or a mechanism for delivering policy-based information.
DNS was designed to express facts, not policies.Erm.. didn't Paul create MAPS to explicitly provide - and later monetize - the RBL?
Wasn't the RBL a "directory service"?
Didn't it map IPs to policy-based information?I agree with the point he's trying to make; I hate NXDOMAIN hijacks too.
I don't get the rant about CDNs, though; seems to me that as long as they're controlled by the domain owner, not a man-in-the-middle, there's no particular distinction between a CDN and plain old round-robin load-balancing.Yep.
It's just a rant on "ways to use DNS that Paul Vixie doesn't like".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30027306</id>
	<title>Re:what it is becoming</title>
	<author>mindstrm</author>
	<datestamp>1257689280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think it's a misunderstanding of context. He's not saying that it's wrong to serve policy information over DNS - but that it's wrong to have DNS making policy decisions as to what data to return.</p></htmltext>
<tokenext>I think it 's a misunderstanding of context .
He 's not saying that it 's wrong to serve policy information over DNS - but that it 's wrong to have DNS making policy decisions as to what data to return .</tokentext>
<sentencetext>I think it's a misunderstanding of context.
He's not saying that it's wrong to serve policy information over DNS - but that it's wrong to have DNS making policy decisions as to what data to return.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018224</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30052188</id>
	<title>Re:not only Verisign</title>
	<author>Hurricane78</author>
	<datestamp>1257850680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You have no soul, and I shall stab you in the heart, at first sight!</p><p>There is no worse type of human than a money servant. One who does everything for the completely pointless golden cow.</p><p>Becoming rich is not a goal in itself, never was, and never will be!</p><p>If someone tries to become rich to be able to do something with a point to it, that's another thing.</p><p>But just money? And then throwing it all out, or just putting it in a safe?<br>That way you would just remove yourself from the space-time continuum. Because in 3-4 generations, nobody would still know you ever existed.<br>So you could as well never have existed.</p></htmltext>
<tokenext>You have no soul , and I shall stab you in the heart , at first sight ! There is no worse type of human than a money servant .
One who does everything for the completely pointless golden cow.Becoming rich is not a goal in itself , never was , and never will be ! If someone tries to become rich to be able to do something with a point to it , that 's another thing.But just money ?
And then throwing it all out , or just putting it in a safe ? That way you would just remove yourself from the space-time continuum .
Because in 3-4 generations , nobody would still know you ever existed.So you could as well never have existed .</tokentext>
<sentencetext>You have no soul, and I shall stab you in the heart, at first sight!There is no worse type of human than a money servant.
One who does everything for the completely pointless golden cow.Becoming rich is not a goal in itself, never was, and never will be!If someone tries to become rich to be able to do something with a point to it, that's another thing.But just money?
And then throwing it all out, or just putting it in a safe?That way you would just remove yourself from the space-time continuum.
Because in 3-4 generations, nobody would still know you ever existed.So you could as well never have existed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016350</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30023166</id>
	<title>Re:competition</title>
	<author>Shark</author>
	<datestamp>1257704580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Or, as ICANN members, we could all submit/vote for a proposal to pull IP address blocks from companies who do such things.  That'll get some attention.  Submit it Vixie and I'll vote.</p></htmltext>
<tokenext>Or , as ICANN members , we could all submit/vote for a proposal to pull IP address blocks from companies who do such things .
That 'll get some attention .
Submit it Vixie and I 'll vote .</tokentext>
<sentencetext>Or, as ICANN members, we could all submit/vote for a proposal to pull IP address blocks from companies who do such things.
That'll get some attention.
Submit it Vixie and I'll vote.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016312</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30032856</id>
	<title>Re:News to me</title>
	<author>BZ</author>
	<datestamp>1257782400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; Is Mozilla actually participating in that nonsense?</p><p>No.  I have no idea where Mr. Vixie got that misinformation, nor do I know why he's spreading it.</p></htmltext>
<tokenext>&gt; Is Mozilla actually participating in that nonsense ? No .
I have no idea where Mr. Vixie got that misinformation , nor do I know why he 's spreading it .</tokentext>
<sentencetext>&gt; Is Mozilla actually participating in that nonsense?No.
I have no idea where Mr. Vixie got that misinformation, nor do I know why he's spreading it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020278</id>
	<title>Re:News to me</title>
	<author>jonadab</author>
	<datestamp>1257679320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt; Which browsers actually do this? Is Mozilla actually participating in that nonsense?<br><br>Yeah, I was wondering that as well.  Personally, I would not willingly use a browser that I believe does this.</htmltext>
<tokenext>&gt; Which browsers actually do this ?
Is Mozilla actually participating in that nonsense ? Yeah , I was wondering that as well .
Personally , I would not willingly use a browser that I believe does this .</tokentext>
<sentencetext>&gt; Which browsers actually do this?
Is Mozilla actually participating in that nonsense?Yeah, I was wondering that as well.
Personally, I would not willingly use a browser that I believe does this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30038750</id>
	<title>Kaminsky bug - Blame Mockapetris, not Vixie</title>
	<author>billstewart</author>
	<datestamp>1257763440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You're blaming the wrong Paul. The Kaminsky bug works because DNS usually uses UDP and only has a 16-bit query ID field, so it's easy to overwhelm at current network speeds (it was a bit tougher when the ARPAnet backbone was 56kbps...)  and because you can birthday-attack the stuff if you're clever.</p><p>I've only waded as far back as RFC883 today, so it's possible that somebody other than Paul Mockapetris and presumably Jon Postel was responsible for picking the query id field size, but I doubt it was Paul Vixie.  If you want to blame him for how long it took to put query port randomization into BIND, I won't stand in your way, but even that's only a stopgap.</p></htmltext>
<tokenext>You 're blaming the wrong Paul .
The Kaminsky bug works because DNS usually uses UDP and only has a 16-bit query ID field , so it 's easy to overwhelm at current network speeds ( it was a bit tougher when the ARPAnet backbone was 56kbps... ) and because you can birthday-attack the stuff if you 're clever.I 've only waded as far back as RFC883 today , so it 's possible that somebody other than Paul Mockapetris and presumably Jon Postel was responsible for picking the query id field size , but I doubt it was Paul Vixie .
If you want to blame him for how long it took to put query port randomization into BIND , I wo n't stand in your way , but even that 's only a stopgap .</tokentext>
<sentencetext>You're blaming the wrong Paul.
The Kaminsky bug works because DNS usually uses UDP and only has a 16-bit query ID field, so it's easy to overwhelm at current network speeds (it was a bit tougher when the ARPAnet backbone was 56kbps...)  and because you can birthday-attack the stuff if you're clever.I've only waded as far back as RFC883 today, so it's possible that somebody other than Paul Mockapetris and presumably Jon Postel was responsible for picking the query id field size, but I doubt it was Paul Vixie.
If you want to blame him for how long it took to put query port randomization into BIND, I won't stand in your way, but even that's only a stopgap.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016494</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018754</id>
	<title>Re:CDNs are good thing</title>
	<author>John Hasler</author>
	<datestamp>1257609420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>&gt; For example, check out what www.google.com resolves to from different<br>&gt; countries or even at different times - depending on where you look it up from<br>&gt; and what network links are up, you will get a different set of IPs.</p><p>According to Google I spent the last two weeks of October jumping around between Japan, France, Spain, and Britain.</p><p>I never left Wisconsin.  And no, I was not using Tor or a VPN or any such thing.</p></htmltext>
<tokenext>&gt; For example , check out what www.google.com resolves to from different &gt; countries or even at different times - depending on where you look it up from &gt; and what network links are up , you will get a different set of IPs.According to Google I spent the last two weeks of October jumping around between Japan , France , Spain , and Britain.I never left Wisconsin .
And no , I was not using Tor or a VPN or any such thing .</tokentext>
<sentencetext>&gt; For example, check out what www.google.com resolves to from different&gt; countries or even at different times - depending on where you look it up from&gt; and what network links are up, you will get a different set of IPs.According to Google I spent the last two weeks of October jumping around between Japan, France, Spain, and Britain.I never left Wisconsin.
And no, I was not using Tor or a VPN or any such thing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30038750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016494
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016598
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016354
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30027306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020320
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016312
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016426
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016598
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30021034
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30019606
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020278
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30024752
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016802
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30032856
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30023166
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016312
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30038496
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016440
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020124
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016350
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016328
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020480
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016316
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017264
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016270
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30052188
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016350
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018296
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020402
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016948
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_07_199256_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30022572
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018614
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016228
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016312
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30023166
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016936
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016598
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017142
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017050
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016492
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018754
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016802
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020480
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018224
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020402
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30027306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30021034
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018296
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016460
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017256
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020320
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016948
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020682
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016440
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30038496
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018614
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30022572
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016494
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30038750
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30032856
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020278
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016274
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30019606
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016328
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016350
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30020124
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30052188
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016426
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30024752
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016794
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016354
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016316
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30016270
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017264
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30017246
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_07_199256.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_07_199256.30018214
</commentlist>
</conversation>
