<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: New Bell Canada CRTC submission</title>
	<atom:link href="http://www.p2pnet.net/story/16364/feed" rel="self" type="application/rss+xml" />
	<link>http://www.p2pnet.net/story/16364</link>
	<description>p2pnet.net - reader powered</description>
	<lastBuildDate>Sun, 08 Nov 2009 14:23:24 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Joel</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-608622</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Sun, 20 Jul 2008 17:35:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-608622</guid>
		<description>It looks like he&#039;s referring to &quot;application headers&quot; as the headers that get wrapped around the data as it passes through OSI layer 7.  Not that this helps him any since P2P protocols, HTTP, MSNP, etc. aren&#039;t defined at OSI layer 7 - they&#039;re all protocols that live outside the OSI stack and operate over TCP/UDP, which are both defined at OSI layer 4 (although they don&#039;t really fit completely in layer 4...).  A good pair of protocols for this sort of comparison are X.500 (DAP) and LDAP.  The X.500 protocol is defined at OSI layer 7, but LDAP (the lightweight replacement for DAP) simply runs over TCP.

Application headers aren&#039;t necessarily a fabrication, but the way Mr. 5% depicts them certainly is :)</description>
		<content:encoded><![CDATA[<p>It looks like he&#8217;s referring to &#8220;application headers&#8221; as the headers that get wrapped around the data as it passes through OSI layer 7.  Not that this helps him any since P2P protocols, HTTP, MSNP, etc. aren&#8217;t defined at OSI layer 7 &#8211; they&#8217;re all protocols that live outside the OSI stack and operate over TCP/UDP, which are both defined at OSI layer 4 (although they don&#8217;t really fit completely in layer 4&#8230;).  A good pair of protocols for this sort of comparison are X.500 (DAP) and LDAP.  The X.500 protocol is defined at OSI layer 7, but LDAP (the lightweight replacement for DAP) simply runs over TCP.</p>
<p>Application headers aren&#8217;t necessarily a fabrication, but the way Mr. 5% depicts them certainly is <img src='http://www.p2pnet.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jean-François Mezei</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-589389</link>
		<dc:creator>Jean-François Mezei</dc:creator>
		<pubDate>Mon, 14 Jul 2008 01:03:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-589389</guid>
		<description>I went through Bell&#039;s fantastic work of fiction yesterday and commented on it.
My comments can be found at:

http://www.dslreports.com/forum/r20780127-Bells-NEW-July-11th-CRTC-Submission

Al Gore may have invented the Internet, but Mirko Bibic has now invented &quot;application headers&quot;. :-) :-) :-)

Better yet, Bibic states that the IP header is part of the TCP packet ! Great work of fiction !

86 pages designed to confuse people, waste their time , in the hopes that after reading it, they will just decide to belive whatever Bell has been saying withough chceking for facts.

I would greatly hope that the CRTC would charge Bell canada with contempt of court for knowingly having submitted lies in its documents. You can&#039;t have a serious decision process when Bell lies in its submissions and expects the CRTC to just sit down , take it and believe everything Bell has stated.</description>
		<content:encoded><![CDATA[<p>I went through Bell&#8217;s fantastic work of fiction yesterday and commented on it.<br />
My comments can be found at:</p>
<p><a href="http://www.dslreports.com/forum/r20780127-Bells-NEW-July-11th-CRTC-Submission" rel="nofollow">http://www.dslreports.com/forum/r20780127-Bells-NEW-July-11th-CRTC-Submission</a></p>
<p>Al Gore may have invented the Internet, but Mirko Bibic has now invented &#8220;application headers&#8221;. <img src='http://www.p2pnet.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />  <img src='http://www.p2pnet.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />  <img src='http://www.p2pnet.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>Better yet, Bibic states that the IP header is part of the TCP packet ! Great work of fiction !</p>
<p>86 pages designed to confuse people, waste their time , in the hopes that after reading it, they will just decide to belive whatever Bell has been saying withough chceking for facts.</p>
<p>I would greatly hope that the CRTC would charge Bell canada with contempt of court for knowingly having submitted lies in its documents. You can&#8217;t have a serious decision process when Bell lies in its submissions and expects the CRTC to just sit down , take it and believe everything Bell has stated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reader's Write</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-588218</link>
		<dc:creator>Reader's Write</dc:creator>
		<pubDate>Sun, 13 Jul 2008 14:39:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-588218</guid>
		<description>google pays a ton to get online and pay a ton for B/W to their services.

The users pays a ton to access content.

The ISP wants to rape the user more and more and more for what is already paid for.</description>
		<content:encoded><![CDATA[<p>google pays a ton to get online and pay a ton for B/W to their services.</p>
<p>The users pays a ton to access content.</p>
<p>The ISP wants to rape the user more and more and more for what is already paid for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reader's Write</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-587809</link>
		<dc:creator>Reader's Write</dc:creator>
		<pubDate>Sun, 13 Jul 2008 11:15:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-587809</guid>
		<description>Network congestion and traffic management is a common problem for any network. To have low priority traffic bumping off high priority traffic is unacceptable, hence traffic management.

Here low priority traffic users (youtube foe example) is screaming bloody murder because their traffic is being managed regardless of other higher priority traffics. This is very self serving.

If Google wants unlimited bandwidth, why don&#039;t they spend the money, lay some fibres and set up a private network?</description>
		<content:encoded><![CDATA[<p>Network congestion and traffic management is a common problem for any network. To have low priority traffic bumping off high priority traffic is unacceptable, hence traffic management.</p>
<p>Here low priority traffic users (youtube foe example) is screaming bloody murder because their traffic is being managed regardless of other higher priority traffics. This is very self serving.</p>
<p>If Google wants unlimited bandwidth, why don&#8217;t they spend the money, lay some fibres and set up a private network?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Devil's Advocate</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-585959</link>
		<dc:creator>Devil's Advocate</dc:creator>
		<pubDate>Sat, 12 Jul 2008 19:49:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-585959</guid>
		<description>As expected, Bell&#039;s answer has been very carefully worded.
It still fails to address a few pretty key issues...

1) Bell frequently made sure it pointed out the difference in the P2P protocol, and are using that as a justification to continue INDEFINITELY its centering out and throttling of P2P.  Bell says over and over that P2P will &quot;always&quot; consume any new bandwidth supplied by upgrading the network, and that P2P activity is not &quot;time-sensitive&quot;.  It is, therefore, logical to assume that Bell is now setting the stage to have P2P &quot;legally&quot; consigned to a Slow Lane!  This does nothing to calm the cry for Net Neutrality.

2) Regardless of whether or not P2P is time-sensitive, why should Bell automatically get to assume the authority to make judgments about what is &quot;more important&quot;, and what transmissions to degrade?  I use P2P to exchange work-related projects, some ARE time-sensitive and require me to work on them and return a revised product.  Increasing numbers of people are doing this.  Bell cannot hope to make a protocol itself &quot;illegal&quot;.  Again, proving the need for Net Neutrality.

3) To help justify the &quot;management&quot; of the last mile, Bell continues to cite various CRTC tariffs that can&#039;t possibly be included in the written language of the GAS contracts, which were based on actual flat bandwidth rates.  (Contracts are supposed to trump all else.)

4) Bell states in a few places that the traffic management and launching of their own content services are unrelated and unconnected, yet there is really no explanation offered as to why it&#039;s supposed to be all right for them to consume their own bandwidth for their own purposes, while denying bandwidth to subscribers and 3rd party contracts.

Since when has this been &quot;Bell&#039;s Network&quot;??
If we give them this one, we&#039;ll be swallowing more shit in the future.
 
Whatever happened to the Common Carrier, anyway?...
...You know, the &quot;Dumb Pipe&quot;, that just passed along the information packets, without regard to what was in them?...
...The one that wasn&#039;t allowed to offer their own services, for fear of competition conflicts?...
...The one that kept telling you it didn&#039;t have the resources to even try to stop spam??!</description>
		<content:encoded><![CDATA[<p>As expected, Bell&#8217;s answer has been very carefully worded.<br />
It still fails to address a few pretty key issues&#8230;</p>
<p>1) Bell frequently made sure it pointed out the difference in the P2P protocol, and are using that as a justification to continue INDEFINITELY its centering out and throttling of P2P.  Bell says over and over that P2P will &#8220;always&#8221; consume any new bandwidth supplied by upgrading the network, and that P2P activity is not &#8220;time-sensitive&#8221;.  It is, therefore, logical to assume that Bell is now setting the stage to have P2P &#8220;legally&#8221; consigned to a Slow Lane!  This does nothing to calm the cry for Net Neutrality.</p>
<p>2) Regardless of whether or not P2P is time-sensitive, why should Bell automatically get to assume the authority to make judgments about what is &#8220;more important&#8221;, and what transmissions to degrade?  I use P2P to exchange work-related projects, some ARE time-sensitive and require me to work on them and return a revised product.  Increasing numbers of people are doing this.  Bell cannot hope to make a protocol itself &#8220;illegal&#8221;.  Again, proving the need for Net Neutrality.</p>
<p>3) To help justify the &#8220;management&#8221; of the last mile, Bell continues to cite various CRTC tariffs that can&#8217;t possibly be included in the written language of the GAS contracts, which were based on actual flat bandwidth rates.  (Contracts are supposed to trump all else.)</p>
<p>4) Bell states in a few places that the traffic management and launching of their own content services are unrelated and unconnected, yet there is really no explanation offered as to why it&#8217;s supposed to be all right for them to consume their own bandwidth for their own purposes, while denying bandwidth to subscribers and 3rd party contracts.</p>
<p>Since when has this been &#8220;Bell&#8217;s Network&#8221;??<br />
If we give them this one, we&#8217;ll be swallowing more shit in the future.</p>
<p>Whatever happened to the Common Carrier, anyway?&#8230;<br />
&#8230;You know, the &#8220;Dumb Pipe&#8221;, that just passed along the information packets, without regard to what was in them?&#8230;<br />
&#8230;The one that wasn&#8217;t allowed to offer their own services, for fear of competition conflicts?&#8230;<br />
&#8230;The one that kept telling you it didn&#8217;t have the resources to even try to stop spam??!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robb Topolski</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-585732</link>
		<dc:creator>Robb Topolski</dc:creator>
		<pubDate>Sat, 12 Jul 2008 18:17:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-585732</guid>
		<description>#184 is an interesting and useful analogy, but it meant to trick you.  Bell **is** opening the postal envelope -- the one meant for the mailman to only see the outside of -- the one it is not supposed to open.  Bell conveniently fails to say that the layer-7 headers that it has to inspect to determine P2P are in the payload (the inside of the envelope) of the Internet Protocol header.  The payload was never intended for this, and examining it for the purposes of Network Management exceeds the purview of a Network Operator that is following the Internet Standards.</description>
		<content:encoded><![CDATA[<p>#184 is an interesting and useful analogy, but it meant to trick you.  Bell **is** opening the postal envelope &#8212; the one meant for the mailman to only see the outside of &#8212; the one it is not supposed to open.  Bell conveniently fails to say that the layer-7 headers that it has to inspect to determine P2P are in the payload (the inside of the envelope) of the Internet Protocol header.  The payload was never intended for this, and examining it for the purposes of Network Management exceeds the purview of a Network Operator that is following the Internet Standards.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reader's Write</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-585525</link>
		<dc:creator>Reader's Write</dc:creator>
		<pubDate>Sat, 12 Jul 2008 16:26:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-585525</guid>
		<description>Did Bell Canada (or the company) actually read any data submitted? Or did they just read the complaints and allegations and substitute everyone else Data with their own Bell Canada&#039;s (or the company&#039;s)..
I really wish this would have been included with the Bell response, they mention &quot;Vaxination Informatique (Vaxination), 4 April 2008 and 3 July 2008&quot; and this is another submission in response to Bell but apparently The gentleman had a problem with efile not working for him so it got files in a different manner.. 
http://www.vaxination.ca/crtc/jfmezei_crtc_2.pdf
http://www.dslreports.com/forum/r20740344-My-humble-contribution-against-Bell</description>
		<content:encoded><![CDATA[<p>Did Bell Canada (or the company) actually read any data submitted? Or did they just read the complaints and allegations and substitute everyone else Data with their own Bell Canada&#8217;s (or the company&#8217;s)..<br />
I really wish this would have been included with the Bell response, they mention &#8220;Vaxination Informatique (Vaxination), 4 April 2008 and 3 July 2008&#8243; and this is another submission in response to Bell but apparently The gentleman had a problem with efile not working for him so it got files in a different manner..<br />
<a href="http://www.vaxination.ca/crtc/jfmezei_crtc_2.pdf" rel="nofollow">http://www.vaxination.ca/crtc/jfmezei_crtc_2.pdf</a><br />
<a href="http://www.dslreports.com/forum/r20740344-My-humble-contribution-against-Bell" rel="nofollow">http://www.dslreports.com/forum/r20740344-My-humble-contribution-against-Bell</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reader's Write</title>
		<link>http://www.p2pnet.net/story/16364/comment-page-1#comment-585374</link>
		<dc:creator>Reader's Write</dc:creator>
		<pubDate>Sat, 12 Jul 2008 14:56:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.p2pnet.net/story/16364#comment-585374</guid>
		<description>NICE!

Thanks for sharing this!</description>
		<content:encoded><![CDATA[<p>NICE!</p>
<p>Thanks for sharing this!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
