ICANN/GNSO GNSO Email List Archives

[ga]


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

Re: [ga] Re: net neutrality


Jefsey, Stephane and all,

  Again we must all bare in mind that RFC's are not standards,
but "Requests for comments".  RFC's are also not "Laws"
nor have any real legal standing, but are useful to one degree
or another in influencing how aspects of IT "Can" be accomplished.
They do not represent working code necessarily.s

  From my observation and activity with the IETF and IAB,
their activities have been over the past 5 years more
politically motivated than technically grounded in order to
set some direction in discribing a particular set of social
values by technical means.  This sort of social engenering
is dangerous on many levels and should be discontinued.

JFC Morfin wrote:

> 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

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402
E-Mail jwkckid1@xxxxxxxxxxxxx
 Registered Email addr with the USPS
Contact Number: 214-244-4827





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