ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Re: net neutrality


I won my bet !!!! I was afraid Stephane would not send this mail (I would have lost 5 euro), but at last he did, exactly like I foresaw: what is obvious to everyone is a lie, and I prove it in quoting the text which obviously support what I say, so everyone is confused.

Thank's Stephane!

Now, for those who want to understand. RFC 4646 is a Trojan Horse.

RFC 4646 describes an application area system, of interest to search engines, libraries, and user profiling systems. As such it is in violation of most of the existing privacy regulations. This is not the case in the USA since such regulation does not exist. However, as for the Whois or the IDNA application, their promoters want to use the entire network as their own application walled garden. Creating the illusion that their project is not from the Applications but from the Network area. This constitutes a universal Security concern. However, this prepares an interoperability between the various market leaders and the smaller prey they want to buy or to "serve", and most of all "shape the world" in an US Network Centric way. This uses adequately the War on Terror: everyone is profiled as terrorist (for the DoD) or as commercial prospect (for the DoC).

Very recently the EU Commission contributed a document that formerly opposes this. As usual the problem becomes difficult for those non-US people who have to choose between their regional and national interests (and common sense) and their target in life, i.e; to contradict me to hide that I am correct, to protect the interests of their employers, or to abide by the sectarian mission assigned to the IETF by RFC 3935.

This mission can be summarised as (you can read the whole RFC): the IETF is to publish documents to "influence the way people design, use, manage" the Internet along the decisions of its leaders, not according what is technically possible, but according to the IETF core values [decentralised, no millde-box, etc. ]). This protects a technical status-quo beneficiary to (dominant) stakeholders and a few egos against the necessary evolution. This evolution is towards a distributed network of mostly free smart internet virtual engines. Its impact is starting to affect everything nowadays at the IAB/IETF level.

The commercial origin of the Internet R&D funding, and its catastrophic consequences have been documented by the IAB in RFC 3869 (again read it). One understands why the champions of our financially dominant Godfathers adopted their attitude and methods (some detailed in RFC 3774, worth to read). Since the US Government's response to IAB's has been the Tunis agreement rearengement, there will be no US money for the Internet R&D but a strategy to lock the Legacy and to take-over the "emerging" Internet, as part of the US contribution to the WSIS agreed but not yet defined "Enhanced Cooperation". Purposedly or not, RFC 4646 has become its best tool. All what is NOT in the security section is its trigger.

At 12:41 26/03/2007, Stephane Bortzmeyer wrote:
On Fri, Mar 23, 2007 at 05:26:02PM +0100,
 JFC Morfin <jefsey@xxxxxxxxxxxxxxxx> wrote
 a message of 100 lines which said:

> IETF, IESG, and IAB formally refused to include a warning in the
> security section about it.

Pure lie. RFC 4646 Security Considerations section says:

   Language tags used in content negotiation, like any other information
   exchanged on the Internet, might be a source of concern because they
   might be used to infer the nationality of the sender, and thus
   identify potential targets for surveillance.

   This is a special case of the general problem that anything sent is
   visible to the receiving party and possibly to third parties as well.
   It is useful to be aware that such concerns can exist in some cases.

   The evaluation of the exact magnitude of the threat, and any possible
   countermeasures, is left to each application protocol (see BCP 72
   [RFC3552] for best current practice guidance on security threats and
   defenses).

An application protocol such as RFC 4646 cannot be used by other application protocols without conflicting with network protocols and creating a non scalable rigidity. This is like if the DNS was to go by the Whois rules. In case of interest, IETF generalises the application concept through a framework. This is the case of the DDDS. They generalise a general concept of which the DNS is an implementation. DDDS could be a very promising avenue due to the resilience and the flexibility to the DNS.


This is why I have first requested a Multilingualisation Framework to modelise where the text and terminology oriented RFC 4646 fits in. In order to permit users to decide if they want to use that application, or not, or another one better addressing their own needs, within that Framework.

The real problem we meet is that the consitution of the Internet we use is in the code, that is in the IETF RFCs, and no structural entity controls the ethic, user interest, the market adequation of the IETF solutions, except "the market" (i.e. manufacturers and commercial services). That is one of the primary mission of the @larges. A mission ICANN and IETF try to block for years.

I started practising such a "User Q.A." at the IETF in order to save 10 or 15 years in this process (look at the IDNA and the IPv6 messes). Obviously the most stubborn and conservative resent me, all the more when I win what I wanted, when I wanted it, ias for RFC 4646 (they now need to violate :-)) .

This may even happen with excelent techies like Stephane.
jfc





<<< Chronological Index >>>    <<< Thread Index >>>