From jefsey@jefsey.com Sun Nov 6 15:06:28 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD221F8490; Sun, 6 Nov 2011 15:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.09 X-Spam-Level: X-Spam-Status: No, score=-102.09 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ728LbR0qeD; Sun, 6 Nov 2011 15:06:28 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF1621F845D; Sun, 6 Nov 2011 15:06:28 -0800 (PST) Received: from 225.218-227-89.dsl.completel.net ([89.227.218.225]:57756 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RNBnF-0007t9-3A; Sun, 06 Nov 2011 15:06:25 -0800 Message-Id: <7.0.1.0.2.20111106173524.05efc1e0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 07 Nov 2011 00:13:59 +0100 To: Michelle Cotton From: JFC Morfin In-Reply-To: References: <01O80WVRJLZS00XBUL@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: "happiana@ietf.org" , iucg@ietf.org Subject: Re: [iucg] [happiana] Focusing on happy X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 23:06:28 -0000 At 01:33 05/11/2011, Michelle Cotton wrote: >Ned, > >I think some of the conversation got derailed (at least I thought it did - >not sure others agree). I was just trying to get back to specific things to >be fixed, label them simple/more complex....I need to go back to my >developer with a list of things to change/fix. Figure out what changes can >be made without any RFC revisions/etc. Michelle, There actually are two classes of people to make happy: - the IETF information registrants - on this IETF list they should have the priority. - the IANA users who may include non-IETF registrants since the IANA charter is not limited to IETF registries. I am not competent to discuss the first class. I am definitly pionneering the second one with the IUCG as the "Internet, IETF, IANA users contributing group": people targeted by RFC 6417. To fully understand what our/their needs are, along with the Internet common way, we have to discuss, experiment and propose. To that end I started keeping updated a IANA WinHTTrack copy with the files linked on external sites. This currently represents : - 23,143 files (of which 4962 have an IANA URL). - 3,793,589,988 bytes (of which 28,370,696 comes from the IANA server). (I can send you a copy of my findings as a table or a csv file, for comparison). Attracting researchers and lead users to the IETF (RFC 6147) calls for matching their culture. They will want accessible, reliable registries they and their applications can directly interact with and use for additional registries (statistics, tests, etc.). They will therefore demand a stable and enforced documentation on the IANA file directories, logic, content, file format, etc.. The main contention I had during the RFC 4646 saga was the size of the langtag tables and the lack of end-user update system; except a complete download of the table. This would quickly double the whole internet traffic in just accessing the IANA if every user requested a daily update (full table download) to be sure his/her smartphone is linguistically up to date. This is why I think the best solution would be : - to conceive an independent intermediate documented stable IANA structure - to publish a formated daily reports, applications might use to request urgent updates - for everyone to be able to maintain his/her own tables - the inner IANA system freely evoluate only having a fixed information structure. At this stage I am interested in (on an experimental basis): - understanding which directories (IANA directories and external sites) the IANA really represents. - experimenting their stability and interfacing their format. - building a single base that can be zipped (probably as an SQLite file) on AKAMAI, with a reader and an updater for futher local copies distribution. - exploring the best/cheapest way to keep its information updated at million sites. - adding global, specialized and private use registries. - documenting the whole set. I whish to know: - if this is acceptable to your strategy. - your comments. - how your team could help. jfc >On 11/4/11 1:53 PM, "Ned Freed" wrote: > > >> Will this group be meeting in Taipei? > > > > What would be the point? We've made essentially no progress in > either previous > > meetings or via email. Lists of specific changes to consider have > been posted > > by both Mark and myself; discussion of both lists died out almost > immediately. > > <01O4OSHQRWC400VHKR@mauve.mrochek.com> is my suggestion list plus some > > additions; <01O559KSSS5800VHKR@mauve.mrochek.com> is my response to Mark's > > list. > > > > We also have an active draft revising media type registrations > that urgently > > needs review; reviews which were promised by September and aside from one > > editorial review, have not materialized. > > >I have read the document and will send you my comments/questions for the >document. > > >> Perhaps to discuss what bits of improvements/clarifications from > this group > >> can go in 5226bis and also to discuss other action items? > > > > And here I was thinking the goal was to figure out how to > streamline existing > > registration processes. It's news to me that a revision of 5226 > was ever the > > goal here. It wasn't mentioned as a goal in the announcement of > the purpose of > > this list. > > > >This was not the goal of this group. Improvements in general both on the >submission of requests/transparency of status/etc were the goals...I think. > >However, it seemed based on some of the email conversations some of what is >being suggested would fit into the revision of 5226 rather than having a >separate document. > >Goal: Make some improvements, hopefully making people happy > >I'm still up for meeting in Taiwan to make a concrete list of actions. > >--Michelle > > > Ned > >_______________________________________________ >happiana mailing list >happiana@ietf.org >https://www.ietf.org/mailman/listinfo/happiana From jmabdp@gmail.com Sun Nov 6 16:39:08 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BCA21F86A0; Sun, 6 Nov 2011 16:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN7g6T1BBdV1; Sun, 6 Nov 2011 16:39:07 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0DF21F8509; Sun, 6 Nov 2011 16:39:06 -0800 (PST) Received: by wyg30 with SMTP id 30so4679348wyg.31 for ; Sun, 06 Nov 2011 16:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZnkJj/XBaZXvDshLdobKNjW+xI7ftua+ri2Iy0Ds5Jg=; b=OSnbaG3wOgtFdGM31Oq5VKQlsUcPcVWIrJ9NgKzyvlHrMQZU2Kpf+OAie9IrEkKFCD BWCHTXETuYjZgfg2zlNkjgC7rl5c5zZfZivt6fQGiT1f9CGt3AoitYZKt2K96UorfbWQ Gb3N8OchnKyvvZm7yZIVn/x4A9lz9cWSvGjM8= MIME-Version: 1.0 Received: by 10.227.208.147 with SMTP id gc19mr10772301wbb.25.1320626344438; Sun, 06 Nov 2011 16:39:04 -0800 (PST) Received: by 10.227.35.195 with HTTP; Sun, 6 Nov 2011 16:39:04 -0800 (PST) In-Reply-To: <7.0.1.0.2.20111106173524.05efc1e0@jefsey.com> References: <01O80WVRJLZS00XBUL@mauve.mrochek.com> <7.0.1.0.2.20111106173524.05efc1e0@jefsey.com> Date: Mon, 7 Nov 2011 01:39:04 +0100 Message-ID: From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=0015174c3b80242bd404b11a488b Cc: Michelle Cotton , "happiana@ietf.org" Subject: Re: [iucg] [happiana] Focusing on happy X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 00:39:08 -0000 --0015174c3b80242bd404b11a488b Content-Type: text/plain; charset=ISO-8859-1 Jefsey, I looked at the initial table you produced. the work ahead seems to be consequent. Moreover if there is no warranty of a stable format from the IANA. Did you consider your "intermediary formated structure" as an test MDRS structure? Anyway what we would all need is an "insider" technical description of the IANA architecture, and a searchable file content database. This would also document the IANA team's experience. Does such a document exist? From your table, most of the IANA files are HTML only one PDF, so I guess not. There is nothing looking as a IANA developper manual or even a printed/maintaiend user information. Or should we try to document each of the 4962 "iana files" in the table? In such a case we should probably: - produce a .csv format - develop a program to extract this table and consider its evolution easily. I can have a look at an rdlab development. Best would be a cooperation with the IANA team. Portzamparc. 2011/11/7 JFC Morfin > At 01:33 05/11/2011, Michelle Cotton wrote: > >> Ned, >> >> I think some of the conversation got derailed (at least I thought it did - >> not sure others agree). I was just trying to get back to specific things >> to >> be fixed, label them simple/more complex....I need to go back to my >> developer with a list of things to change/fix. Figure out what changes >> can >> be made without any RFC revisions/etc. >> > > Michelle, > > There actually are two classes of people to make happy: > > - the IETF information registrants - on this IETF list they should have > the priority. > - the IANA users who may include non-IETF registrants since the IANA > charter is not limited to IETF registries. > > I am not competent to discuss the first class. > I am definitly pionneering the second one with the IUCG as the "Internet, > IETF, IANA users contributing group": people targeted by RFC 6417. To fully > understand what our/their needs are, along with the Internet common way, we > have to discuss, experiment and propose. > > To that end I started keeping updated a IANA WinHTTrack copy with the > files linked on external sites. > > This currently represents : > > - 23,143 files (of which 4962 have an IANA URL). > - 3,793,589,988 bytes (of which 28,370,696 comes from the IANA server). > > (I can send you a copy of my findings as a table or a csv file, for > comparison). > > Attracting researchers and lead users to the IETF (RFC 6147) calls for > matching their culture. They will want accessible, reliable registries they > and their applications can directly interact with and use for additional > registries (statistics, tests, etc.). They will therefore demand a stable > and enforced documentation on the IANA file directories, logic, content, > file format, etc.. > > The main contention I had during the RFC 4646 saga was the size of the > langtag tables and the lack of end-user update system; except a complete > download of the table. This would quickly double the whole internet traffic > in just accessing the IANA if every user requested a daily update (full > table download) to be sure his/her smartphone is linguistically up to date. > > This is why I think the best solution would be : > > - to conceive an independent intermediate documented stable IANA structure > - to publish a formated daily reports, applications might use to request > urgent updates > - for everyone to be able to maintain his/her own tables > - the inner IANA system freely evoluate only having a fixed information > structure. > > At this stage I am interested in (on an experimental basis): > > - understanding which directories (IANA directories and external sites) > the IANA really represents. > - experimenting their stability and interfacing their format. > - building a single base that can be zipped (probably as an SQLite file) > on AKAMAI, with a reader and an updater for futher local copies > distribution. > - exploring the best/cheapest way to keep its information updated at > million sites. > - adding global, specialized and private use registries. > - documenting the whole set. > > I whish to know: > > - if this is acceptable to your strategy. > - your comments. > - how your team could help. > > jfc > > > > On 11/4/11 1:53 PM, "Ned Freed" wrote: >> >> >> Will this group be meeting in Taipei? >> > >> > What would be the point? We've made essentially no progress in either >> previous >> > meetings or via email. Lists of specific changes to consider have been >> posted >> > by both Mark and myself; discussion of both lists died out almost >> immediately. >> > <01O4OSHQRWC400VHKR@mauve.**mrochek.com<01O4OSHQRWC400VHKR@mauve.mrochek.com>> >> is my suggestion list plus some >> > additions; <01O559KSSS5800VHKR@mauve.**mrochek.com<01O559KSSS5800VHKR@mauve.mrochek.com>> >> is my response to Mark's >> > list. >> > >> > We also have an active draft revising media type registrations that >> urgently >> > needs review; reviews which were promised by September and aside from >> one >> > editorial review, have not materialized. >> > >> I have read the document and will send you my comments/questions for the >> document. >> >> >> Perhaps to discuss what bits of improvements/clarifications from this >> group >> >> can go in 5226bis and also to discuss other action items? >> > >> > And here I was thinking the goal was to figure out how to streamline >> existing >> > registration processes. It's news to me that a revision of 5226 was >> ever the >> > goal here. It wasn't mentioned as a goal in the announcement of the >> purpose of >> > this list. >> > >> >> This was not the goal of this group. Improvements in general both on the >> submission of requests/transparency of status/etc were the goals...I >> think. >> >> However, it seemed based on some of the email conversations some of what >> is >> being suggested would fit into the revision of 5226 rather than having a >> separate document. >> >> Goal: Make some improvements, hopefully making people happy >> >> I'm still up for meeting in Taiwan to make a concrete list of actions. >> >> --Michelle >> >> > Ned >> >> ______________________________**_________________ >> happiana mailing list >> happiana@ietf.org >> https://www.ietf.org/mailman/**listinfo/happiana >> > > ______________________________**_________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/**listinfo/iucg > --0015174c3b80242bd404b11a488b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,

I looked at the initial table you produced.

the work = ahead seems to be consequent. Moreover if there is no warranty of a stable = format from the IANA.
Did you consider your "intermediary formated= structure" as an test MDRS structure?

Anyway what we would all need is an "insider" technical descr= iption of the IANA architecture, and a searchable file content database. Th= is would also document the IANA team's experience. Does such a document= exist? From your table, most of the IANA files are HTML only one PDF, so I= guess not. There is nothing looking as a IANA developper manual or even a = printed/maintaiend user information.

Or should we try to document each of the 4962 "iana files" in= the table? In such a case we should probably:
- produce a .csv format- develop a program to extract this table and consider its evolution easi= ly. I can have a look at an rdlab development.

Best would be a cooperation with the IANA team.
Portzamparc.

=
2011/11/7 JFC Morfin <jefsey@jefsey.com>
At 01:33 05/11/2011, Michelle Cotton wrote:
Ned,

I think some of the conversation got derailed (at least I thought it did -<= br> not sure others agree). =A0I was just trying to get back to specific things= to
be fixed, label them simple/more complex....I need to go back to my
developer with a list of things to change/fix. =A0Figure out what changes c= an
be made without any RFC revisions/etc.

Michelle,

There actually are two classes of people to make happy:

- the IETF information registrants - on this IETF list they should have the= priority.
- the IANA users who may include non-IETF registrants since the IANA charte= r is not limited to =A0IETF registries.

I am not competent to discuss the first class.
I am definitly pionneering the second one with the IUCG as the "Intern= et, IETF, IANA users contributing group": people targeted by RFC 6417.= To fully understand what our/their needs are, along with the Internet comm= on way, we have to discuss, experiment and propose.

To that end I started keeping updated a IANA =A0WinHTTrack copy =A0with the= files linked =A0on external sites.

This currently represents :

- 23,143 files (of which 4962 have an IANA URL).
- 3,793,589,988 bytes (of which 28,370,696 comes from the IANA server).

(I can send you a copy of my findings as a table or a csv file, for compari= son).

Attracting researchers and lead users to the IETF (RFC 6147) calls for matc= hing their culture. They will want accessible, reliable registries they and= their applications can directly interact with and use for additional regis= tries (statistics, tests, etc.). They will therefore demand a stable and en= forced documentation on the IANA file directories, logic, content, file for= mat, etc..

The main contention I had during the RFC 4646 saga was the size of the lang= tag tables and the lack of end-user update system; except a complete downlo= ad of the table. This would quickly double the whole internet traffic in ju= st accessing the IANA if every user requested a daily update (full table do= wnload) to be sure his/her smartphone is linguistically up to date.

This is why I think the best solution would be :

- to conceive an independent intermediate documented stable IANA structure<= br> - to publish a formated daily reports, applications might use to request ur= gent updates
- for everyone to be able to maintain his/her own tables
- the inner IANA system freely evoluate only having a fixed information str= ucture.

At this stage I am interested in (on an experimental basis):

- understanding which directories (IANA directories and external sites) the= IANA really represents.
- experimenting their stability and interfacing their format.
- building a single base that can be zipped (probably as an SQLite file) on= AKAMAI, with a reader and an updater for futher local copies distribution.=
- exploring the best/cheapest way to keep its information updated at millio= n sites.
- adding global, specialized and private use registries.
- documenting the whole set.

I whish to know:

- if this is acceptable to your strategy.
- your comments.
- how your team could help.

jfc



On 11/4/11 1:53 PM, "Ned Freed" <ned.freed@mrochek.com> wrote:

>> Will this group be meeting in Taipei?
>
> What would be the point? We've made essentially no progress in eit= her previous
> meetings or via email. Lists of specific changes to consider have been= posted
> by both Mark and myself; discussion of both lists died out almost imme= diately.
> <01O4OSHQRWC400VHKR@mauve.mrochek.com> is my suggestio= n list plus some
> additions; <01O559KSSS5800VHKR@mauve.mrochek.com> is m= y response to Mark's
> list.
>
> We also have an active draft revising media type registrations that ur= gently
> needs review; reviews which were promised by September and aside from = one
> editorial review, have not materialized.
>
I have read the document and will send you my comments/questions for the document.

>> Perhaps to discuss what bits of improvements/clarifications from t= his group
>> can go in 5226bis and also to discuss other action items?
>
> And here I was thinking the goal was to figure out how to streamline e= xisting
> registration processes. It's news to me that a revision of 5226 wa= s ever the
> goal here. It wasn't mentioned as a goal in the announcement of th= e purpose of
> this list.
>

This was not the goal of this group. =A0Improvements in general both on the=
submission of requests/transparency of status/etc were the goals...I think.=

However, it seemed based on some of the email conversations some of what is=
being suggested would fit into the revision of 5226 rather than having a separate document.

Goal: Make some improvements, hopefully making people happy

I'm still up for meeting in Taiwan to make a concrete list of actions.<= br>
--Michelle

> Ned

_______________________________________________
happiana mailing list
happiana@ietf.org
https://www.ietf.org/mailman/listinfo/happiana

_______________________________________________
iucg mailing list
iucg@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/iucg

--0015174c3b80242bd404b11a488b-- From jefsey@jefsey.com Mon Nov 7 06:01:00 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC89E21F8BEC; Mon, 7 Nov 2011 06:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfuSshj1i2CO; Mon, 7 Nov 2011 06:00:59 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id AF60621F8BE9; Mon, 7 Nov 2011 06:00:59 -0800 (PST) Received: from 225.218-227-89.dsl.completel.net ([89.227.218.225]:58389 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RNPkw-0007vF-As; Mon, 07 Nov 2011 06:00:58 -0800 Message-Id: <7.0.1.0.2.20111107104651.05efc5b8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 07 Nov 2011 15:08:31 +0100 To: internet users contributing group From: JFC Morfin In-Reply-To: References: <01O80WVRJLZS00XBUL@mauve.mrochek.com> <7.0.1.0.2.20111106173524.05efc1e0@jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: Michelle Cotton , "happiana@ietf.org" , ca@linguasphere.info Subject: [iucg] Focusing on happy X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:01:00 -0000 Jean-Michel, This is the crux for us, and for the Internet. At 01:39 07/11/2011, jean-michel bernier de portzamparc wrote: >Jefsey, > >I looked at the initial table you produced. > >the work ahead seems to be consequent. Moreover if there is no >warranty of a stable format from the IANA. >Did you consider your "intermediary formated structure" as an test >MDRS structure? > >Anyway what we would all need is an "insider" technical description >of the IANA architecture, and a searchable file content database. >This would also document the IANA team's experience. Does such a >document exist? From your table, most of the IANA files are HTML >only one PDF, so I guess not. There is nothing looking as a IANA >developper manual or even a printed/maintaiend user information. > >Or should we try to document each of the 4962 "iana files" in the >table? In such a case we should probably: >- produce a .csv format >- develop a program to extract this table and consider its evolution >easily. I can have a look at an rdlab development. The general issue, as I perceive it from the different inputs on the happiana mailing list, results from Peter Saint-Andre's impossible targeted task. I'll quote him here: >We're not here with a clean slate to rewrite RFC 5226 or core >IANA procedures. Instead, we're here to improve the interface to the >IANA for both IETF participants and other SDOs (the primary SDO that >gave rise to this discussion was the W3C because the Applications ADs >tend to help process standards tree registrations for web technologies, >but there might be other SDOs in the mix). This is to say: I want a very nice, wide car, doing what I want on the road, security for my family, impress my neighborhood, be able to transport all of my friends, etc. but all I have is a bunch of bikes and I do not have the money for any other vehicle. I want to focus on being happy, and not on the work that is to make it happen. So, as a result: >As I wrote yesterday to the >ietf@ietf.org list, as part of our work here we might collaborate on >"bis" documents regarding registration procedures for URI schemes (RFC >4395), link relations (RFC 5988), media types (RFC 4288), header fields >(RFC 3864) primarily for HTTP, and perhaps others. I'll let IANA folks >talk share their thoughts, but one idea that's been floated is to >improve visibility into the IANA ticketing system so that registrants >from, say, the W3C could see their request as it moves through the >process without needing to pester the relevant Area Director. This means that one can only (too complicated otherwise) plaster patches on the bikes and tell people how to use them as if they were a big, nice car. >I'm out of time for now but just wanted to make sure that we have a >broadly similar set of expecations about what we're trying to accomplish >here. What we need is a clear description of the IANA engine for all the seasons, the way it works and the way that it is to be used, and the IANA specifications that are to be approved by the IESG as the exact program for that IANA engine to run along the RFC, i.e. its user manual. This really means a clean slate approach. Either this is engaged by the IETF for the Internet, written by the IANA team and documented for its clients (including the IETF), or it is designed elsewhere. This problem is a recurrent problem that I have faced for 35 years: to jointly document the network to peers, so that they can themselves document it to their users. From this I identified the need for a distributed system permitting everyone to document everything to the attention of everyone who needs it and of his/her machines. I called that system MDRS, which stands for Meta-Data Registry/Multilingual Distributed Referential System. This turned out to be the Intersem Internet-IANA architectural equivalent (and probable extension/continuation). Until now, I have only tried to avoid complicating the resolution of this complex issue, in particular in the multiglobal area (multilingual, multitechnology, international, national strategies, cultures, transdisciplinary exploration, etc.). I hoped Peter's effort can be a basis for a step ahead. I am afraid, from reading the happianna mailing list that the only solution is for the IUsers (Interdigital ecosystem users) emerging community to do this for themselves, based on the existing IANA, ISO, Linguasphere, etc. material, our passed Intlnet and JTC1, IETF DDDS/DNS deployment experience, and Intersem under the exploration requirements. Now, the issue we also have to match, towards good and robust MDRS specifications, is simplifying complexity. This means understanding in a practical manner what complexity and simplicity are and how to computer assist them in the best way, which means to equally master meta-complexity and meta-simplicity. This may seem somewhat esoteric at this stage, but it is necessary when considering the seed of the system to actually structure the semantic layer of communications. Understand that for the sole Internet (passive content strata) there are 96 different IANA related RFCs, if you add ISO 3166 and 639 etc., ISO 11179 series, Linguasphere open source elements, it becomes which is, actually, way too much. >Best would be a cooperation with the IANA team. >Portzamparc. Up to them to decide. jfc From jefsey@jefsey.com Wed Nov 9 19:45:09 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5531F11E8098; Wed, 9 Nov 2011 19:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.01 X-Spam-Level: X-Spam-Status: No, score=-101.01 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZzuTiYcuho9; Wed, 9 Nov 2011 19:45:08 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF3311E8097; Wed, 9 Nov 2011 19:45:08 -0800 (PST) Received: from 103.140-227-89.dsl.completel.net ([89.227.140.103]:53444 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1ROLZZ-00006g-8a; Wed, 09 Nov 2011 19:45:05 -0800 Message-Id: <7.0.1.0.2.20111110041952.10781900@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 10 Nov 2011 04:52:32 +0100 To: Bjoern Hoehrmann ,happiana@ietf.org From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: [iucg] USG position on the IANA nature. X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 03:45:09 -0000 Bjoern, the issue is currently actively discussed on my lists in France. The reason why is the nature of the IANA as it results from : https://www.fbo.gov/index?s=opportunity&mode=form&id=5c2ed0cd9584c5fb886574826f39ca40&tab=core The main issues are : 1. the legal definition given to the IANA as : >"services to maintain the continuity and stability of services >related to certain interdependent Internet technical management >functions, known collectively as the Internet Assigned Numbers >Authority (IANA)." Because it says "certain" and not "some" or "the". The services are particular and/or specific. 2. the govermental constraint which specifies in what they are particular : >The Contractor shall be: > >a) a wholly U.S. owned and operated firm or fully accredited U.S. >university or college operating in one of the 50 states of the >United States or District of Columbia; >b) incorporated within one of the fifty (50) states of the United >States or District of Columbia; and >c) organized under the laws of a state of the United States or >District of Columbia. > >The Contractor shall perform the primary IANA functions of the >Contract in the United States and possess and maintain, throughout >the performance of this Contract, a physical address within the >United States. The Contractor must be able to demonstrate that all >primary operations and systems will remain within the Unites States >(including the District of Columbia). 3. the fact that the IANA service is considered as a good US citizen pro bono service. This plainly establish that this is an US service, by American interests, for American users that other people may use. This was something we never considered since for us the IANA was hosting the IETF registries. IETF is not mentionned in the USG tender and this raises questions about the IETF nationality. All this seems to mean that other governments should do the same - and actually have the duty to do the same (I refer to the recent Indian Gov. proposition supported by Brazil, and to the AFRAC (http://afrac.org) organization we tested a few years ago towards a French IANA, with national security concerns in mind). In such a case the problem is the data consistency between the different national IANAs. I think this is an issue for this list. This is why I started documenting the work we engaged. I hope I can come in the coming weeks with more data and comments. It seems that the emerging IUse community tends to consensually consider that the size of the Internet makes it a universal that should abide by the cosmological principle in order to stay indefinitly coherent, efficient and neutral. In such a case the IANA should actually be an US (since the US Gov wants its this way) instantiation of the multiglobal referential layer necessary to operate the Internet. In any case, we will report our findings and projects to Nelly Kroes, the EC Commissioner for Digital Agenda. jfc At 03:17 10/11/2011, Bjoern Hoehrmann wrote: >Hi, > > Some time ago I wondered about mirroring the registry details from the >IANA web site in some public revision control system, so you could, for >instance, subscribe to some Recent Changes feed, or run statistical ana- >lysis tools on the data, like to report on how frequent changes are or >how long it takes for entries to show up. > >I encountered mainly three problems: the first is that the FTP site does >not include all the data; I would have to look up examples, but I recall >some large seemingly XML-driven registry with "sub-directories" on the >web site but no corresponding sub-directories in the FTP data. The other >two problems are legal: can I actually set this up without any copyright >concerns? And how to handle confidentiality and privacy breaches (IANA >might accidentally publish information it shouldn't have, removes it the >next day, but the mirror might hold the information forever; how should >a mirror be organized to minimize problems that may result from this?) > >regards, From pouzin@gmail.com Thu Nov 10 04:16:14 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899AE21F8B47 for ; Thu, 10 Nov 2011 04:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.076 X-Spam-Level: X-Spam-Status: No, score=-0.076 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Xxl8NQFVrw for ; Thu, 10 Nov 2011 04:16:13 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A12421F8B3B for ; Thu, 10 Nov 2011 04:16:08 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so2715336bkb.31 for ; Thu, 10 Nov 2011 04:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=F12C08vLGtGy3YxccGTrLQwRk90XMgneE2h13JI81cY=; b=CM0lD3yAl6LBjXdznYrTCvo9nRLapDo/JIXVSv9LPnytEAfsFdr0LAJauRtugFL8OQ ydRdJ2fXbH+LF0/jc9Y6IMe3x6N69Jc8h5WCVF5ERK6N/PW9eJZkRzRZ00wUY+n8UKcd f+iZjNIBVwmebxiMRIniLlAe5WXqmGQZ7RUkU= Received: by 10.204.9.205 with SMTP id m13mr4872861bkm.32.1320927367311; Thu, 10 Nov 2011 04:16:07 -0800 (PST) MIME-Version: 1.0 Sender: pouzin@gmail.com Received: by 10.204.11.1 with HTTP; Thu, 10 Nov 2011 04:15:46 -0800 (PST) In-Reply-To: <7.0.1.0.2.20100324095451.071506f0@jefsey.com> References: <661ab3ba1003230332v1ef90e04k3e71801b381c73b3@mail.gmail.com> <661ab3ba1003232010v5a18a50akbd87e9ebd17cd966@mail.gmail.com> <7.0.1.0.2.20100324095451.071506f0@jefsey.com> From: Louis Pouzin Date: Thu, 10 Nov 2011 13:15:46 +0100 X-Google-Sender-Auth: kaaohnvWvEVa0DOHVOpARViTGio Message-ID: To: comptoir@cafedu.com Content-Type: multipart/alternative; boundary=0015175caebe80b22a04b1605e8f X-Mailman-Approved-At: Thu, 10 Nov 2011 16:41:45 -0800 Cc: =?ISO-8859-1?Q?Kav=E9_Salamatian?= , iucg@ietf.org, pouzin@enst.fr Subject: [iucg] =?iso-8859-1?q?=5Bcomptoir_1051=5D_cloud_computing=2C_un_m?= =?iso-8859-1?q?irage_=E0_la_mode?= X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pouzin@enst.fr, internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:23:03 -0000 --0015175caebe80b22a04b1605e8f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Graduellement le buzz du nuage =E9volue de la b=E9atification =E0 l'inqui= =E9tude, du bleu au gris: http://citizenlab.org/wp-content/uploads/2011/10/g20cannes2011-deibert.pdf On confie son argent =E0 des banques, ses actions =E0 des courtiers, ses ti= tres de propri=E9t=E9s =E0 des notaires. On sait o=F9 les trouver. Ils sont stri= ctement r=E9glement=E9s, et couverts mutuellement ou par l'=C9tat. Malgr=E9 tout il= arrive que des fraudes, gestions hasardeuses, ou escroqueries ruinent des soci=E9t= =E9s et des particuliers. Rien n'est r=E9glement=E9 dans le nuage. On y met n'importe quoi en totale inconscience, et =E0 l'insu des clients. Autrement dit, un Fukushima garant= i. --0015175caebe80b22a04b1605e8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Graduellement le buzz du nuage =E9volue de la b=E9atification =E0 l'inq= ui=E9tude, du bleu au gris:

http://cit= izenlab.org/wp-content/uploads/2011/10/g20cannes2011-deibert.pdf

On confie son argent =E0 des banques, ses actions =E0 des courtiers, se= s titres de propri=E9t=E9s =E0 des notaires. On sait o=F9 les trouver. Ils = sont strictement r=E9glement=E9s, et couverts mutuellement ou par l'=C9= tat. Malgr=E9 tout il arrive que des fraudes, gestions hasardeuses, ou escr= oqueries ruinent des soci=E9t=E9s et des particuliers.

Rien n'est r=E9glement=E9 dans le nuage. On y met n'importe quo= i en totale inconscience, et =E0 l'insu des clients. Autrement dit, un = Fukushima garanti.
--0015175caebe80b22a04b1605e8f-- From jefsey@jefsey.com Mon Nov 14 17:37:47 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF921F8EB1 for ; Mon, 14 Nov 2011 17:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.159 X-Spam-Level: X-Spam-Status: No, score=-98.159 tagged_above=-999 required=5 tests=[AWL=-3.493, BAYES_95=3, FRT_EXPERIENCE=2.333, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQZeSyR3kUCl for ; Mon, 14 Nov 2011 17:37:45 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id E769F21F8EAE for ; Mon, 14 Nov 2011 17:37:45 -0800 (PST) Received: from 140.0-227-89.dsl.completel.net ([89.227.0.140]:58899 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RQ7y3-0007qJ-N8; Mon, 14 Nov 2011 17:37:44 -0800 Message-Id: <7.0.1.0.2.20111114203041.060e4e88@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 15 Nov 2011 02:45:32 +0100 To: maaya@funredes.org From: jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_393321373==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: "comptoir@cafedu.com" , iucg@ietf.org Subject: [iucg] IDNA, capacitation linguistique, ICANN et Bulgarie X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:37:47 -0000 --=====================_393321373==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Daniel, je te remercie et me tiens à la disposition de ton interlocteur. Différents mails directs me sont parvenus au sujet de l'IDNccTLD bulgare. Une certaine confusion risque de se développer quant aux niveaux de ce qui est en jeu et de ce qui se passe. Il ne faut pas se tromper de combat. L'ICANN n'est pas l'ennemi, elle est un partenaire que l'on doit conduire à agir dans notre intérêt commun. . Le contexte est la "mécanisation linguistique" : l'interface sémiotique homme/machine (la langues que nous ferons nous parler nos machines et que nous copierons nécessairement) dans le contexte de la coexistance multilingue des langues sur les mêmes machines/réseaux. Et donc le contexte de la question fondamentale : qui doit être le référent ultime du développement technologique des mécalangues : l'homme ou la machine. L'honnête homme du XXIè ou le Client de Google+. La décision se fait sans doute irréversiblement sur les "IDNccTLD", pour la simple raison que le DNS est le moteur de recherche le plus utilisé dans le monde et que tous les autres s'accordent sur son approche. J'explique pourquoi en Post-Scriptum jfc ==== La bataille de la diversité linguistique dans l'espace numérique. La multilinguisation a l'image de coûter cher et de réduire les possibilités de rationnalisation tentées par la Dominance industrielle de l'Internet, est toujours le même : - introduire des solutions prémâchées qui semblent devoir être irréversibles en raison de la taille et de l'argent des protagonistes et de l'opacité du processus de décision. - l'affirmer par la défaite des opposants culturels/linguistiques sur quelques cas précis par l'impossibilité pratique de faire entendre raison à qui n'écoute pas. - opposer aux autres cas que la solution a déjà été consensuellement arrétée et mise en opération. Elle a été suivie en particulier pour IDNA2003 (les noms de domaine linguistiques, solution dépendant d'Unicode), engagée pour les langtags (ségrégation commerciale automatique des langues), le contrôle des écritures par les ingénieurs de l'IETF, ici le contrôle des cultures par les économico-juristes de l'ICANN, la proposition IDNA2008 initiale (pour se dégager d'Unicode), etc. L'expérience a montré comment contrer cette stratégie. J'ai appris avec IDNA2003 et j'ai demandé en vain du secours J'ai donc entrepris seul et adopté un modus operandi qui marche : Phase 1 : donner du temps au temps par une stratégie initiale de faible au fort pour déstabiliser techniquement la proposition "mécaniste" et obliger à un approfondissement architectural. Phase 2 : utiliser l'architecture pour une proposition expérimentale "humaniste" concrète de fort à fort par les risques économiques qui en résulteront sur la position mécaniste, Phase 3 : faire prévaloir une exploration commune de bon sens où les marchands comprennent que l'innovation technique dans le respect des cultures va servir et bénéficier à tous. Situation actuelle C'est ainsi que IDNA2003 a conduit à sa refonte en IDNA2008, que les langtags sont restés acceptables, que IDNA2008 a introduit la réponse architecturale nécessaire qui était absente de l'Internet (couche "présentation" OSI), que l'intelligence subsidiaire nécessaire à l'Intersem à venir (Internet sémiotique/sémantique multilingue) peut être investiguée. Toutefois il ne faut jamais céder dans les escarmouches comme l'épisode bulgare. Il faut sans cesse les replacer dans une tactique de guerilla, de bras de fer ou d'ouverture générale selon la phase où l'on reste toujours et partout dans le contexte du but général visé et ne pas se faire enfermer dans le détail des cas (que la dominance utilise comme pièges à retarder, jouant sur la pérennité des états de fait). Les protagonistes Tous sont des experts dévoués à leur cause. - Unicode se bat pour sa prééminence commerciale, - l'IETF se bat pour le contrôle normatif de l'Internet, - l'ICANN se bat pour les intérêts des Etats-(et de son staff)-Unis. Unicode est en phase 1, mais est tenu par certains de ses Membres (Google, Microsoft) dont les responsables sont entre les phases 2 et 3. L'IAB est en phase 3. L'IETF est en phase 2. L'ICANN est en phase 1, car elle n'est opposée que par des "ack-tivistes" (société civile, @largesà qui acceptent ses règles du jeu : il faut qu'elle sente le poids de la phase 2 et s'adapte pour passer en phase 3. Pour cela il faut lui montrer pourquoi elle ne survivra pas - au moins dans sa situation vis-à-vis des USA - dans sa configuration actuelle si elle ne modifie pas son attitude. Est-ce possible ? Ce n'était pas possible jusqu'à présent. Cela l'est à partir de janvier 2012, car elle a fait l'erreur de se mettre dans une situation de concurrence avec ses propres utilisateurs (nouveaux TLD). Cette situation est très facile à attiser par la technologie (le fichier racine unique réel [tenu à jour par l'ICANN] devenant virtuel et multiple, en totale conformité avec les RFC et logiciels existants pour bien plus de services et d'autonomie à moindre coût pour les utilisateurs). Or l'ICANN n'est justifié que par l'unicité physique du contenu de ce fichier. Dans le cas de la Bulgarie, cela passe par l'acceptation par l'ICANN que le droit qu'elle s'arroge de l'inscription ou non dans son fichier racine soit appelable (mon expérience répétée à l'IETF montre que même dans la pire des oppositions apparentes, l'on peut finalement non seulement s'accorder, mais se faire mutuellement progresser). Sinon, l'appel se fera par la décision des utilisateurs et donc par leur désintérêt plus ou moins rapide pour l'ICANN. Notre but Nous ne voulons pas que la Bulgarie négocie. Nous voulons à cette occasion voire établies les conditions structurelles du dialogue sur chacun des cas qui peut se produire/ jfc --=====================_393321373==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Daniel,
je te remercie et me tiens à la disposition de ton interlocteur.

Différents mails directs me sont parvenus au sujet de l'IDNccTLD bulgare. Une certaine confusion risque de se développer quant aux niveaux de ce qui est en jeu et de ce qui se passe. Il ne faut pas se tromper de combat. L'ICANN n'est pas l'ennemi, elle est un partenaire que l'on doit conduire à agir dans notre intérêt commun. .

Le contexte est la "mécanisation linguistique" : l'interface sémiotique homme/machine (la langues que nous ferons nous parler nos machines et que nous copierons nécessairement) dans le contexte de la coexistance multilingue des langues sur les mêmes machines/réseaux. Et donc le contexte de la question fondamentale : qui doit être le référent ultime du développement technologique des mécalangues : l'homme ou la machine. L'honnête homme du XXIè ou le Client de Google+.

La décision se fait sans doute irréversiblement sur les "IDNccTLD", pour la simple raison que le DNS est le moteur de recherche le plus utilisé dans le monde et que tous les autres s'accordent sur son approche.

J'explique pourquoi en Post-Scriptum
jfc


====

La bataille de la diversité linguistique dans l'espace numérique.


La multilinguisation a l'image de coûter cher et de réduire les possibilités de rationnalisation tentées par la Dominance industrielle de l'Internet, est toujours le même :

- introduire des solutions prémâchées qui semblent devoir être irréversibles en raison de la taille et de l'argent des protagonistes et de l'opacité du processus de décision.
- l'affirmer par la défaite des opposants culturels/linguistiques sur quelques cas précis par l'impossibilité pratique de faire entendre raison à qui n'écoute pas.
- opposer aux autres cas que la solution a déjà été consensuellement arrétée et mise en opération.

Elle a été suivie en particulier pour IDNA2003 (les noms de domaine linguistiques, solution dépendant d'Unicode), engagée pour les langtags (ségrégation commerciale automatique des langues), le contrôle des écritures par les ingénieurs de l'IETF, ici le contrôle des cultures par les économico-juristes de l'ICANN, la proposition IDNA2008 initiale (pour se dégager d'Unicode), etc.

L'expérience a montré comment contrer cette stratégie.

J'ai appris avec IDNA2003 et j'ai demandé en vain du secours J'ai donc entrepris seul et adopté un modus operandi qui marche :
Phase 1 : donner du temps au temps par une stratégie initiale de faible au fort pour déstabiliser techniquement la proposition "mécaniste" et obliger à un approfondissement architectural.
Phase 2 : utiliser l'architecture pour une proposition expérimentale "humaniste" concrète de fort à fort par les risques économiques qui en résulteront sur la position mécaniste,
Phase 3 : faire prévaloir une exploration commune de bon sens où les marchands comprennent que l'innovation technique dans le respect des cultures va servir et bénéficier à tous.

Situation actuelle

C'est ainsi que IDNA2003 a conduit à sa refonte en IDNA2008, que les langtags sont restés acceptables, que IDNA2008 a introduit la réponse architecturale nécessaire qui était absente de l'Internet (couche "présentation" OSI), que l'intelligence subsidiaire nécessaire à l'Intersem à venir (Internet sémiotique/sémantique multilingue) peut être investiguée. Toutefois il ne faut jamais céder dans les escarmouches comme l'épisode bulgare. Il faut sans cesse les replacer dans une tactique de guerilla, de bras de fer ou d'ouverture générale selon la phase où l'on reste toujours et partout dans le contexte du but général visé et ne pas se faire enfermer dans le détail des cas (que la dominance utilise comme pièges à retarder, jouant sur la pérennité des états de fait).

Les protagonistes

Tous sont des experts dévoués à leur cause.
- Unicode se bat pour sa prééminence commerciale,
- l'IETF se bat pour le contrôle normatif de l'Internet,
- l'ICANN se bat pour les intérêts des Etats-(et de son staff)-Unis.

Unicode est en phase 1, mais est tenu par certains de ses Membres (Google, Microsoft) dont les responsables sont entre les phases 2 et 3.  L'IAB est en phase 3. L'IETF est en phase 2.
L'ICANN est en phase 1, car elle n'est opposée que par des "ack-tivistes" (société civile, @largesà qui acceptent ses règles du jeu : il faut qu'elle sente le poids de la phase 2 et s'adapte pour passer en phase 3. Pour cela il faut lui montrer pourquoi elle ne survivra pas - au moins dans sa situation vis-à-vis des USA - dans sa configuration actuelle si elle ne modifie pas son attitude.

Est-ce possible ?

Ce n'était pas possible jusqu'à présent. Cela l'est à partir de janvier 2012, car elle a fait l'erreur de se mettre dans une situation de concurrence avec ses propres utilisateurs (nouveaux TLD). Cette situation est très facile à attiser par la technologie (le fichier racine unique réel [tenu à jour par l'ICANN] devenant virtuel et multiple, en totale conformité avec les RFC et logiciels existants pour bien plus de services et d'autonomie à moindre coût pour les utilisateurs). Or l'ICANN n'est justifié que par l'unicité physique du contenu de ce fichier.

Dans le cas de la Bulgarie, cela passe par l'acceptation par l'ICANN que le droit qu'elle s'arroge de l'inscription ou non dans son fichier racine soit appelable (mon expérience répétée à l'IETF montre que même dans la pire des oppositions apparentes, l'on peut finalement non seulement s'accorder, mais se faire mutuellement progresser). Sinon, l'appel se fera par la décision des utilisateurs et donc par leur désintérêt plus ou moins rapide pour l'ICANN.

Notre but

Nous ne voulons pas que la Bulgarie négocie. Nous voulons à cette occasion voire établies les conditions structurelles du dialogue sur chacun des cas qui peut se produire/

jfc




--=====================_393321373==.ALT-- From jefsey@jefsey.com Tue Nov 15 05:27:48 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F244421F8A7A for ; Tue, 15 Nov 2011 05:27:47 -0800 (PST) X-Quarantine-ID: <6jPhG5jWkPw2> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E0 hex): Subject: ... 1051] cloud computing, un\n mira ge \340 la mode X-Spam-Flag: NO X-Spam-Score: -100.325 X-Spam-Level: X-Spam-Status: No, score=-100.325 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SUBJECT_NEEDS_ENCODING=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jPhG5jWkPw2 for ; Tue, 15 Nov 2011 05:27:43 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id CE2CD21F893C for ; Tue, 15 Nov 2011 05:27:43 -0800 (PST) Received: from 140.0-227-89.dsl.completel.net ([89.227.0.140]:61806 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RQJ33-0004dR-36; Tue, 15 Nov 2011 05:27:38 -0800 Message-Id: <7.0.1.0.2.20111115043213.060e5260@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 15 Nov 2011 14:35:23 +0100 To: comptoir@cafedu.com,pouzin@enst.fr,comptoir@cafedu.com From: JFC Morfin Subject: Re: [comptoir 1518] Re: [comptoir 1051] cloud computing, un mira ge à la mode In-Reply-To: <4B00109A-E729-4E20-A9DC-0CBD035B243B@gmail.com> References: <661ab3ba1003230332v1ef90e04k3e71801b381c73b3@mail.gmail.com> <661ab3ba1003232010v5a18a50akbd87e9ebd17cd966@mail.gmail.com> <7.0.1.0.2.20100324095451.071506f0@jefsey.com> <4B00109A-E729-4E20-A9DC-0CBD035B243B@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_435913125==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: Kavé Salamatian , iucg@ietf.org X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:27:48 -0000 --=====================_435913125==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 19:40 14/11/2011, Kavé Salamatian wrote: >Bonjour Louis > >effectivement, que peut on attendre d'un monde sans régulation, où >la seule loi est celle de l'offre de la demande. Rajouté à cela un >zeste de loi anti-terroriste, un peu de piratage chinois, du >stuxnet, .... et on a un cocktail explosif appelé Internet :-). > >Voici ce que j'ai trouvé sur le site site du départment of homeland >security américain. > >Traffic.pdf>http://dhsnnw.org/HNAPDocs/NNW-HNAP-How%20To%20Sniff%20Wireless%20Traffic.pdf > >Big Brothers dans toute sa splendeur. Alors quand on est pas en >sécurité chez soi, tu imagines sur un nuage :-) Tout cela c'est un ou dix ordres de grandeur plus fou que le timesharing, etc. Mais il n'y avait pas grand chose à faire avec un réseau centralisant. Pendant longtemps j'ai cru qu'il n'y avait qu'une solution structurée (QNX) existante pour répondre à ma vision (chacun usant de sa machine comme centre du réseau et de ses resources en ligne) et l'internet étant lui-même inapproprié (question sécurité, routage, gateways). Mais : - QNX (utilisé par CISCO) avait le défaut d'être propriétaire, non simplifié et non particulièrement protégé. Jusqu'à ce que je tombe par hasard sur Inferno, un port open source de Plan 9. - et jusqu'à ma surprise du consensus que nous avons pu trouver sur IDNA2008 et donc le support possible par l'Internet de mon modèle OSI très etendu. Plan 9/Inferno c'est : - la suite distribuée (en "nuage" hyper-simple et protégé) d'un Unix volatil (OS or Machine Virtuelle) avec une variation de C à la Java (Limbo) - par les auteurs d'Unix et de C Bell Labs. Je crois que cela vaud le coup de se pencher dessus et d'en faire le reverse engineering pour le comprendre et de voir si on peut y intégrer un (ML-)DNS IDNA2008, un routeur open source, etc. pour en faire une plateforme "interno" sur la quelle travailler. Au moins de manière prototype. Ce qui est intéressant est que cela fonctionne en antémachine autonome sur Windows, Linux, Android, etc. etc. Peut-être des membres de cette liste seraient intéressés. Je pense que l'on va monter une petit centre d'expertise à Montpellier et songer à un BOFcamp cet année pour ceux que cela intéresserait. Commentaires bien venus. jfc --=====================_435913125==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 19:40 14/11/2011, Kavé Salamatian wrote:
Bonjour Louis

effectivement, que peut on attendre d'un monde sans régulation, où la seule loi est celle de l'offre de la demande. Rajouté à cela un zeste de loi anti-terroriste, un peu de piratage chinois, du stuxnet, ....  et on a un cocktail explosif appelé Internet :-).

Voici ce que j'ai trouvé sur le site site du départment of homeland security américain.

http://dhsnnw.org/HNAPDocs/NNW-HNAP-How%20To%20Sniff%20Wireless%20Traffic.pdf

Big Brothers dans toute sa splendeur. Alors quand on est pas en sécurité chez soi, tu imagines sur un nuage :-)

Tout cela c'est un ou dix ordres de grandeur plus fou que le timesharing, etc.

Mais il n'y avait pas grand chose à faire avec un réseau centralisant. Pendant longtemps j'ai cru qu'il n'y avait qu'une solution structurée (QNX) existante pour répondre à ma vision (chacun usant de sa machine comme centre du réseau et de ses resources en ligne) et l'internet étant lui-même inapproprié (question sécurité, routage, gateways). Mais :

- QNX (utilisé par CISCO) avait le défaut d'être propriétaire, non simplifié et non particulièrement protégé. Jusqu'à ce que je tombe par hasard sur Inferno, un port open source de Plan 9.
- et jusqu'à ma surprise du consensus que nous avons pu trouver sur IDNA2008 et donc le support possible par l'Internet de mon modèle OSI très etendu.

Plan 9/Inferno c'est :
- la suite distribuée (en "nuage" hyper-simple et protégé) d'un Unix volatil (OS or Machine Virtuelle) avec une variation de C à la Java (Limbo)
- par les auteurs d'Unix et de C Bell Labs.

Je crois que cela vaud le coup de se pencher dessus et d'en faire le reverse engineering pour le comprendre et de voir si on peut y intégrer un (ML-)DNS IDNA2008, un routeur open source, etc. pour en faire une plateforme "interno" sur la quelle travailler. Au moins de manière prototype. Ce qui est intéressant est que cela fonctionne en antémachine autonome sur Windows, Linux, Android, etc. etc.

Peut-être des membres de cette liste seraient intéressés. Je pense que l'on va monter une petit centre d'expertise à Montpellier et songer à un BOFcamp cet année pour ceux que cela intéresserait. Commentaires bien venus.

jfc --=====================_435913125==.ALT-- From pyeu@the-incubator.com Mon Nov 14 08:55:33 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46D11E82D9 for ; Mon, 14 Nov 2011 08:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHbE0pc5liSh for ; Mon, 14 Nov 2011 08:55:29 -0800 (PST) Received: from mail-3d.bbox.fr (mail-3d.bbox.fr [194.158.122.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01D11E82DC for ; Mon, 14 Nov 2011 08:55:28 -0800 (PST) Received: from mbpatrick-2.home (89-93-188-221.hfc.dyn.abo.bbox.fr [89.93.188.221]) by mail-3d.bbox.fr (Postfix) with ESMTP id DAC0E69; Mon, 14 Nov 2011 17:55:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6213E41-0449-41C6-9EBA-1CA0AC0D6169" From: Patrick Yeu In-Reply-To: Date: Mon, 14 Nov 2011 17:55:22 +0100 Message-Id: <4685220B-D785-4DC6-A349-048B9B25ECD5@the-incubator.com> References: <661ab3ba1003230332v1ef90e04k3e71801b381c73b3@mail.gmail.com> <661ab3ba1003232010v5a18a50akbd87e9ebd17cd966@mail.gmail.com> <7.0.1.0.2.20100324095451.071506f0@jefsey.com> To: pouzin@enst.fr, comptoir@cafedu.com X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Tue, 15 Nov 2011 09:13:35 -0800 Cc: =?iso-8859-1?Q?Kav=E9_Salamatian?= , iucg@ietf.org Subject: Re: [iucg] =?iso-8859-1?q?=5Bcomptoir__1513=5D_=5Bcomptoir_1051=5D_cl?= =?iso-8859-1?q?oud_computing=2C_un_mirage_=E0_la_mode?= X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 16:55:33 -0000 --Apple-Mail=_B6213E41-0449-41C6-9EBA-1CA0AC0D6169 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Bonjour Louis,=20 Tu n'es as le seul =E0 te soucier du d=E9ploiement b=E9at du Net. A = lire: = http://www.nytimes.com/2011/11/14/technology/arista-networks-founders-aim-= to-alter-how-computers-connect.html?_r=3D1&nl=3Dtodaysheadlines&emc=3Dtha2= 6 Bien =E0 toi, Patrick=20 Le 10 nov. 2011 =E0 13:15, Louis Pouzin a =E9crit : > Graduellement le buzz du nuage =E9volue de la b=E9atification =E0 = l'inqui=E9tude, du bleu au gris: >=20 > = http://citizenlab.org/wp-content/uploads/2011/10/g20cannes2011-deibert.pdf= >=20 > On confie son argent =E0 des banques, ses actions =E0 des courtiers, = ses titres de propri=E9t=E9s =E0 des notaires. On sait o=F9 les trouver. = Ils sont strictement r=E9glement=E9s, et couverts mutuellement ou par = l'=C9tat. Malgr=E9 tout il arrive que des fraudes, gestions hasardeuses, = ou escroqueries ruinent des soci=E9t=E9s et des particuliers. >=20 > Rien n'est r=E9glement=E9 dans le nuage. On y met n'importe quoi en = totale inconscience, et =E0 l'insu des clients. Autrement dit, un = Fukushima garanti. > _______________________________________________ > comptoir mailing list > comptoir@cafedu.com > http://cafedu.com/mailman/listinfo/comptoir_cafedu.com --Apple-Mail=_B6213E41-0449-41C6-9EBA-1CA0AC0D6169 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 http://www.nytimes.com/2011/11/14/technology/arista-net= works-founders-aim-to-alter-how-computers-connect.html?_r=3D1&nl=3Dtod= aysheadlines&emc=3Dtha26

Bien =E0 = toi,

Patrick 

Le = 10 nov. 2011 =E0 13:15, Louis Pouzin a =E9crit :

Graduellement le buzz du nuage =E9volue de la = b=E9atification =E0 l'inqui=E9tude, du bleu au gris:

http://citizenlab.org/wp-content/uploads/2011/10/g20cann= es2011-deibert.pdf

On confie son argent =E0 des banques, ses actions =E0 des courtiers, = ses titres de propri=E9t=E9s =E0 des notaires. On sait o=F9 les trouver. = Ils sont strictement r=E9glement=E9s, et couverts mutuellement ou par = l'=C9tat. Malgr=E9 tout il arrive que des fraudes, gestions hasardeuses, = ou escroqueries ruinent des soci=E9t=E9s et des particuliers.

Rien n'est r=E9glement=E9 dans le nuage. On y met n'importe quoi en = totale inconscience, et =E0 l'insu des clients. Autrement dit, un = Fukushima garanti.
_______________________________________________
comptoir mailing = list
comptoir@cafedu.com
http://cafe= du.com/mailman/listinfo/comptoir_cafedu.com

= --Apple-Mail=_B6213E41-0449-41C6-9EBA-1CA0AC0D6169-- From kave.salamatian@gmail.com Mon Nov 14 10:40:44 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E04311E82D9 for ; Mon, 14 Nov 2011 10:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPzZC7yHeGq1 for ; Mon, 14 Nov 2011 10:40:43 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3346711E81B0 for ; Mon, 14 Nov 2011 10:40:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8DBABD930B; Mon, 14 Nov 2011 19:40:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TmD+wL55XuQr; Mon, 14 Nov 2011 19:40:31 +0100 (MET) Received: from [192.168.1.45] (fer01-1-78-234-66-232.fbx.proxad.net [78.234.66.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: salamatm) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E1B4ED9309; Mon, 14 Nov 2011 19:40:30 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_FA3EFB53-E12D-4AA9-ADE2-CCAAEF5A4BE9" From: =?iso-8859-1?Q?Kav=E9_Salamatian?= In-Reply-To: Date: Mon, 14 Nov 2011 19:40:29 +0100 Message-Id: <4B00109A-E729-4E20-A9DC-0CBD035B243B@gmail.com> References: <661ab3ba1003230332v1ef90e04k3e71801b381c73b3@mail.gmail.com> <661ab3ba1003232010v5a18a50akbd87e9ebd17cd966@mail.gmail.com> <7.0.1.0.2.20100324095451.071506f0@jefsey.com> To: pouzin@enst.fr, comptoir@cafedu.com X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Tue, 15 Nov 2011 09:13:35 -0800 Cc: =?iso-8859-1?Q?Kav=E9_Salamatian?= , iucg@ietf.org Subject: Re: [iucg] =?iso-8859-1?q?=5Bcomptoir__1513=5D_=5Bcomptoir_1051=5D_cl?= =?iso-8859-1?q?oud_computing=2C_un_mirage_=E0_la_mode?= X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:41:54 -0000 --Apple-Mail=_FA3EFB53-E12D-4AA9-ADE2-CCAAEF5A4BE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Bonjour Louis effectivement, que peut on attendre d'un monde sans r=E9gulation, o=F9 = la seule loi est celle de l'offre de la demande. Rajout=E9 =E0 cela un = zeste de loi anti-terroriste, un peu de piratage chinois, du stuxnet, = .... et on a un cocktail explosif appel=E9 Internet :-).=20 Voici ce que j'ai trouv=E9 sur le site site du d=E9partment of homeland = security am=E9ricain.=20 = http://dhsnnw.org/HNAPDocs/NNW-HNAP-How%20To%20Sniff%20Wireless%20Traffic.= pdf Big Brothers dans toute sa splendeur. Alors quand on est pas en s=E9curit=E9= chez soi, tu imagines sur un nuage :-) A+ Kv Le 10 nov. 2011 =E0 13:15, Louis Pouzin a =E9crit : > Graduellement le buzz du nuage =E9volue de la b=E9atification =E0 = l'inqui=E9tude, du bleu au gris: >=20 > = http://citizenlab.org/wp-content/uploads/2011/10/g20cannes2011-deibert.pdf= >=20 > On confie son argent =E0 des banques, ses actions =E0 des courtiers, = ses titres de propri=E9t=E9s =E0 des notaires. On sait o=F9 les trouver. = Ils sont strictement r=E9glement=E9s, et couverts mutuellement ou par = l'=C9tat. Malgr=E9 tout il arrive que des fraudes, gestions hasardeuses, = ou escroqueries ruinent des soci=E9t=E9s et des particuliers. >=20 > Rien n'est r=E9glement=E9 dans le nuage. On y met n'importe quoi en = totale inconscience, et =E0 l'insu des clients. Autrement dit, un = Fukushima garanti. > _______________________________________________ > comptoir mailing list > comptoir@cafedu.com > http://cafedu.com/mailman/listinfo/comptoir_cafedu.com --Apple-Mail=_FA3EFB53-E12D-4AA9-ADE2-CCAAEF5A4BE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 http://dhsnnw.org/HNAPDocs/NNW-HNAP-How%20To%20Sniff%20Wirele= ss%20Traffic.pdf

Big Brothers dans toute sa = splendeur. Alors quand on est pas en s=E9curit=E9 chez soi, tu imagines = sur un nuage = :-)

A+


Kv=



Le 10 = nov. 2011 =E0 13:15, Louis Pouzin a =E9crit :

Graduellement le buzz du nuage =E9volue de la = b=E9atification =E0 l'inqui=E9tude, du bleu au gris:

http://citizenlab.org/wp-content/uploads/2011/10/g20cann= es2011-deibert.pdf

On confie son argent =E0 des banques, ses actions =E0 des courtiers, = ses titres de propri=E9t=E9s =E0 des notaires. On sait o=F9 les trouver. = Ils sont strictement r=E9glement=E9s, et couverts mutuellement ou par = l'=C9tat. Malgr=E9 tout il arrive que des fraudes, gestions hasardeuses, = ou escroqueries ruinent des soci=E9t=E9s et des particuliers.

Rien n'est r=E9glement=E9 dans le nuage. On y met n'importe quoi en = totale inconscience, et =E0 l'insu des clients. Autrement dit, un = Fukushima garanti.
_______________________________________________
comptoir mailing = list
comptoir@cafedu.com
http://cafe= du.com/mailman/listinfo/comptoir_cafedu.com

= --Apple-Mail=_FA3EFB53-E12D-4AA9-ADE2-CCAAEF5A4BE9-- From jefsey@jefsey.com Sun Nov 27 07:38:54 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7221F8B6F; Sun, 27 Nov 2011 07:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdqJDOcxL6Yt; Sun, 27 Nov 2011 07:38:53 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0621F8B64; Sun, 27 Nov 2011 07:38:53 -0800 (PST) Received: from 68.213-227-89.dsl.completel.net ([89.227.213.68]:51591 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RUgob-000170-P0; Sun, 27 Nov 2011 07:38:50 -0800 Message-Id: <7.0.1.0.2.20111127142006.067711a8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 27 Nov 2011 16:47:39 +0100 To: Suresh Krishnan From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: ietf-privacy@ietf.org, "Joel M. Halpern" , int-area@ietf.org, iucg@ietf.org, Joe Touch Subject: Re: [iucg] [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 15:38:54 -0000 Suresh, May I suggest that once again Witgestein is right: we are confronted to a "philosophical" issue through a technical problem (and vice-versa), and the reason why is that the problem cannot be solved in the way it is posed and therefore discussed. This is the IETF. So the question is to understand what (network) "privacy" specifically is at the IETF layer (not what it may mean in general to IETF people in particular). Then to make sure that this (presupposed: I suppose that no one opposes?) mandatory "IETF privacy support" is insured at IETF layers in a cooperative way with layers below and above, and that the adopted strategy is documented in a "privacy section". The IAB draft is a draft. The Int-area debate is an experimental case for that I_D. And reprocically. I understand that Francis only want a waste of time, the need for an exhausting opposition and a further demotivation if the debate does not engage in a direction where the European prerequisite (which has equivalent throughout the whole world) can be respected The ietf-privacy non-WG mailing list (Issues related to privacy that cut across multiple groups and areas. The initial goal of this discussion is to investigate privacy and related identity management terminology) has the draft: http://tools.ietf.org/html/draft-hansen-privacy-terminology-03 with changes interesting to consider from its http://tools.ietf.org/html/draft-hansen-privacy-terminology-02 previous version. What I feel from the pieces I gathered for IUCG discussion at http://iucg.org/wiki/Privacy is that security - as IETF understands it - is end to end oriented, while privacy is content oriented. This may mean that a privacy section could result from two subsections (network, content) of the security section. I would not be JFC if I did not add that a third "impermeability" (to context) subsection should consider the multilingual, architectural, interapplication, etc. aspects that might possibly interfere. A connex security/privacy/permeability issue is "neutrality". I checked: the string "neutra" neither appears in the tables of: - WG list: http://datatracker.ietf.org/wg/, - non-WG list: http://www.ietf.org/list/nonwg.html - nor in the concluded WG list: http://www.ietf.org/wg/concluded/. I tend to define network neutrality as the end to end/fringe to fringe service staying unchanged by the change of its component, I feel there are many ways in which neutrality may concur to network security, privacy and impermeability. jfc At 08:23 27/11/2011, Suresh Krishnan wrote: >I think part of the confusion surrounding this draft arises because >of the apparent discrepancy between the stated goal of the draft and >the text currently in the draft. Since some of the solutions being >analyzed in the draft have not been proposed in any other draft, it >seems natural for this draft to discuss the privacy implications of >those solutions. Alissa has volunteered to take a look at the draft >and propose some text to be added. That should help us figure out >exactly what additional privacy implications this draft would have, >if any, over simply exposing an IP address without any address >sharing between different subscribers. > >Thanks >Suresh > >"Joel M. Halpern" wrote: > >Joe, > I am missing something. > There is an observation that the behavior described in this document >has privacy implications. >Either that statement is true, or it is not. If it is not true, then >there is no need to do anything. >However, it appears likely the statement is true. > > If it is true that this document has privacy implications, then the >general rule that says that we should document what we know about would >seem to come into play. It would seem sensible to include a description >of known privacy implications in the document. > > This seems to be the case even if the absence of any document from >anyone, with or without IETF consensus, on the more general issue of >looking for privacy issues. > >Yours, >Joel > >On 11/26/2011 8:40 PM, Joe Touch wrote: > > > > > > On Nov 26, 2011, at 10:21 AM, Francis > Dupont wrote: > > > >> In your previous mail you wrote: > >> > >> If and when a document describing the privacy considerations > >> requirements has passed IETF review, sure. > >> > >> => to wait this document is published as a RFC to add a privacy > >> consideration section to the nat-reveal I-D is no more reasonable > >> to block all documents related to privacy until it is published... > > > > That has not been yet requested. If it were, I would be glad to > raise it as a process issue. > > > > Again, stop holding this doc to requirements that gave not been > agereed by the IETF as a whole. > > > >> Right now, that document is an individual submission with no track. > >> > >> => perhaps you are not about the same 'that document' than me, cf > >> draft-iab-privacy-considerations-01.txt which is far to be an > >> individual submission without a clear future. > > > > Is hasn't been last called either. And its core definitions refer > to a induvidual submission. > > > >> It is quite premature to be holding up this document on an issue > >> that the IETF has not yet decided on. > >> > >> => as there is a solution proposed by a third party and I wish to > >> leave the possible announce to him I moved to offline... > > > > Based on input from a directorate that is proposed in a doc that > is still a draft. > > > > This isn't useful. > > > > The privacy considerations IAB doc is misguided IMO. We don't > need a required section for every squeaky wheel. These are security > issues and not sufficiently agreed at this time to establish requirements IMO. > > > > Joe > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From jefsey@jefsey.com Sun Nov 27 08:36:09 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2821F8B9E; Sun, 27 Nov 2011 08:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.854 X-Spam-Level: X-Spam-Status: No, score=-101.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HMaCucSP9R8; Sun, 27 Nov 2011 08:36:09 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id ED3EA21F8479; Sun, 27 Nov 2011 08:36:08 -0800 (PST) Received: from 68.213-227-89.dsl.completel.net ([89.227.213.68]:52532 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RUhi2-0001oP-6a; Sun, 27 Nov 2011 08:36:08 -0800 Message-Id: <7.0.1.0.2.20111127174405.067712f0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 27 Nov 2011 17:44:56 +0100 To: Suresh Krishnan From: JFC Morfin In-Reply-To: <7.0.1.0.2.20111127142006.067711a8@jefsey.com> References: <7.0.1.0.2.20111127142006.067711a8@jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: ietf-privacy@ietf.org, int-area@ietf.org, iucg@ietf.org Subject: Re: [iucg] [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 16:36:09 -0000 Sorry, I obviously meant that Francis does *not* want a waste of time ... etc. jfc From jefsey@jefsey.com Mon Nov 28 02:25:58 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CCB21F8CC1; Mon, 28 Nov 2011 02:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afJGjZldh0Lr; Mon, 28 Nov 2011 02:25:57 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4521F8CBF; Mon, 28 Nov 2011 02:25:57 -0800 (PST) Received: from 68.213-227-89.dsl.completel.net ([89.227.213.68]:55463 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RUyPK-0005Sr-9X; Mon, 28 Nov 2011 02:25:54 -0800 Message-Id: <7.0.1.0.2.20111128110809.06771438@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Nov 2011 11:34:43 +0100 To: Andrew Sullivan ,int-area@ietf.org From: JFC Morfin In-Reply-To: <20111128041336.GB43536@shinkuro.com> References: <20111125212432.GB26104@shinkuro.com> <201111261844.pAQIiqPT057860@givry.fdupont.fr> <20111128041336.GB43536@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: Re: [iucg] [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 10:25:58 -0000 At 05:13 28/11/2011, Andrew Sullivan wrote: > > => it is in the European Convention on Human Rights as a legal > > principle so there is at least a basis but I am afraid it won't really > > help. As a (French) lawyer explained to me one day, a legal text must be > > as less accurate as possible so it can be applied to more than one > > particular case so a legal principle... > >You appear to be claiming the in above that we are suppose to write >"Privacy Considerations" without a clear definition of what could >possibly be covered, except maybe "everything". Andrew, we are to reach a rough consensus. One cannot build a consensus in opposing some of the members. Whatever their motivations. Now, how to do it? The need is not to cover everything, but to cover everything in our bailywick that may affect everything as defined by the obligations of the various national legal cultures. So, the point seems rather simple: to cover our tracks. Whatever privacy may be, the technical matter is about not giving away/leaking undisclosed (meta)data through what we permit to do. So the Internet works better (RFC 3935) not worse. Questions: 1. which information do we use? 2. which information do we introduce? 3. in which way do/canwe expose them? 4. which steps do we already take not to (over)expose them? 5. are there additional step we could consider to cover our tracks? If the responses do not gain the support of every people (for whatever reason) there will not be a consensus and nothing will be published. jfc >Ok, here's more boilerplate for you: > > Privacy Considerations > > This document may affect the privacy of someone on the Internet, > according to the definition of privacy in your jurisdiction. You > are encouraged to consider that. > >That's all we can say, AFAICT from your response. > > > PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights > > (see the article 8 about privacy). > >Yes, of course. We should base new policies on the official opinion >of all the people who can be bothered to work on Wikipedia articles. > >Best, > >A > >-- >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area