http://iuwg.net/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=IUWG - New pages [en]2024-03-29T12:58:17ZFrom IUWGMediaWiki 1.23.3http://iuwg.net/index.php/International_Covenant_on_Civil_and_Political_RightsInternational Covenant on Civil and Political Rights2017-04-09T21:21:56Z<p>Sysop: /* PART V */</p>
<hr />
<div><br/><br />
<br />
Adopted and opened for signature, ratification and accession by General Assembly resolution 2200A (XXI) of 16 December 1966 - entry into force 23 March 1976, in accordance with Article 49.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
==== Preamble ====<br />
<br />
The States Parties to the present Covenant, <br />
<br />
Considering that, in accordance with the principles proclaimed in the Charter of the United Nations, recognition of the inherent dignity and of the equal and inalienable rights of all members of the human family is the foundation of freedom, justice and peace in the world, <br />
<br />
Recognizing that these rights derive from the inherent dignity of the human person, <br />
<br />
Recognizing that, in accordance with the Universal Declaration of Human Rights, the ideal of free human beings enjoying civil and political freedom and freedom from fear and want can only be achieved if conditions are created whereby everyone may enjoy his civil and political rights, as well as his economic, social and cultural rights, <br />
<br />
Considering the obligation of States under the Charter of the United Nations to promote universal respect for, and observance of, human rights and freedoms, <br />
<br />
Realizing that the individual, having duties to other individuals and to the community to which he belongs, is under a responsibility to strive for the promotion and observance of the rights recognized in the present Covenant, <br />
<br />
Agree upon the following articles: <br />
<br />
==<br/> PART I ==<br />
<br />
==== Article 1 ====<br />
<br />
1. All peoples have the right of self-determination. By virtue of that right they freely determine their political status and freely pursue their economic, social and cultural development. <br />
<br />
2. All peoples may, for their own ends, freely dispose of their natural wealth and resources without prejudice to any obligations arising out of international economic co-operation, based upon the principle of mutual benefit, and international law. In no case may a people be deprived of its own means of subsistence. <br />
<br />
3. The States Parties to the present Covenant, including those having responsibility for the administration of Non-Self-Governing and Trust Territories, shall promote the realization of the right of self-determination, and shall respect that right, in conformity with the provisions of the Charter of the United Nations.<br />
<br />
==<br/> PART II ==<br />
<br />
==== Article 2 ====<br />
<br />
1. Each State Party to the present Covenant undertakes to respect and to ensure to all individuals within its territory and subject to its jurisdiction the rights recognized in the present Covenant, without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status. <br />
<br />
2. Where not already provided for by existing legislative or other measures, each State Party to the present Covenant undertakes to take the necessary steps, in accordance with its constitutional processes and with the provisions of the present Covenant, to adopt such laws or other measures as may be necessary to give effect to the rights recognized in the present Covenant. <br />
<br />
3. Each State Party to the present Covenant undertakes: <br />
<br />
: (a) To ensure that any person whose rights or freedoms as herein recognized are violated shall have an effective remedy, notwithstanding that the violation has been committed by persons acting in an official capacity; <br />
<br />
: (b) To ensure that any person claiming such a remedy shall have his right thereto determined by competent judicial, administrative or legislative authorities, or by any other competent authority provided for by the legal system of the State, and to develop the possibilities of judicial remedy; <br />
<br />
: (c) To ensure that the competent authorities shall enforce such remedies when granted. <br />
<br />
==== Article 3 ====<br />
<br />
The States Parties to the present Covenant undertake to ensure the equal right of men and women to the enjoyment of all civil and political rights set forth in the present Covenant. <br />
<br />
==== Article 4 ====<br />
<br />
1 . In time of public emergency which threatens the life of the nation and the existence of which is officially proclaimed, the States Parties to the present Covenant may take measures derogating from their obligations under the present Covenant to the extent strictly required by the exigencies of the situation, provided that such measures are not inconsistent with their other obligations under international law and do not involve discrimination solely on the ground of race, colour, sex, language, religion or social origin. <br />
<br />
2. No derogation from articles 6, 7, 8 (paragraphs I and 2), 11, 15, 16 and 18 may be made under this provision. <br />
<br />
3. Any State Party to the present Covenant availing itself of the right of derogation shall immediately inform the other States Parties to the present Covenant, through the intermediary of the Secretary-General of the United Nations, of the provisions from which it has derogated and of the reasons by which it was actuated. A further communication shall be made, through the same intermediary, on the date on which it terminates such derogation. <br />
<br />
==== Article 5 ====<br />
<br />
1. Nothing in the present Covenant may be interpreted as implying for any State, group or person any right to engage in any activity or perform any act aimed at the destruction of any of the rights and freedoms recognized herein or at their limitation to a greater extent than is provided for in the present Covenant. <br />
<br />
2. There shall be no restriction upon or derogation from any of the fundamental human rights recognized or existing in any State Party to the present Covenant pursuant to law, conventions, regulations or custom on the pretext that the present Covenant does not recognize such rights or that it recognizes them to a lesser extent.<br />
[[File:Example.jpg]]<br />
<br />
==<br/> PART III ==<br />
<br />
==== Article 6 ====<br />
<br />
1. Every human being has the inherent right to life. This right shall be protected by law. No one shall be arbitrarily deprived of his life. <br />
<br />
2. In countries which have not abolished the death penalty, sentence of death may be imposed only for the most serious crimes in accordance with the law in force at the time of the commission of the crime and not contrary to the provisions of the present Covenant and to the Convention on the Prevention and Punishment of the Crime of Genocide. This penalty can only be carried out pursuant to a final judgement rendered by a competent court. <br />
<br />
3. When deprivation of life constitutes the crime of genocide, it is understood that nothing in this article shall authorize any State Party to the present Covenant to derogate in any way from any obligation assumed under the provisions of the Convention on the Prevention and Punishment of the Crime of Genocide. <br />
<br />
4. Anyone sentenced to death shall have the right to seek pardon or commutation of the sentence. Amnesty, pardon or commutation of the sentence of death may be granted in all cases. <br />
<br />
5. Sentence of death shall not be imposed for crimes committed by persons below eighteen years of age and shall not be carried out on pregnant women. <br />
<br />
6. Nothing in this article shall be invoked to delay or to prevent the abolition of capital punishment by any State Party to the present Covenant. <br />
<br />
==== Article 7 ====<br />
<br />
No one shall be subjected to torture or to cruel, inhuman or degrading treatment or punishment. In particular, no one shall be subjected without his free consent to medical or scientific experimentation. <br />
<br />
==== Article 8 ====<br />
<br />
1. No one shall be held in slavery; slavery and the slave-trade in all their forms shall be prohibited. <br />
<br />
2. No one shall be held in servitude. <br />
<br />
3. <br />
<br />
: (a) No one shall be required to perform forced or compulsory labour; <br />
<br />
: (b) Paragraph 3 (a) shall not be held to preclude, in countries where imprisonment with hard labour may be imposed as a punishment for a crime, the performance of hard labour in pursuance of a sentence to such punishment by a competent court; <br />
<br />
: (c) For the purpose of this paragraph the term "forced or compulsory labour" shall not include: <br />
<br />
: (i) Any work or service, not referred to in subparagraph (b), normally required of a person who is under detention in consequence of a lawful order of a court, or of a person during conditional release from such detention; <br />
<br />
: (ii) Any service of a military character and, in countries where conscientious objection is recognized, any national service required by law of conscientious objectors; <br />
<br />
: (iii) Any service exacted in cases of emergency or calamity threatening the life or well-being of the community; <br />
<br />
: (iv) Any work or service which forms part of normal civil obligations. <br />
<br />
==== Article 9 ====<br />
<br />
1. Everyone has the right to liberty and security of person. No one shall be subjected to arbitrary arrest or detention. No one shall be deprived of his liberty except on such grounds and in accordance with such procedure as are established by law. <br />
<br />
2. Anyone who is arrested shall be informed, at the time of arrest, of the reasons for his arrest and shall be promptly informed of any charges against him. <br />
<br />
3. Anyone arrested or detained on a criminal charge shall be brought promptly before a judge or other officer authorized by law to exercise judicial power and shall be entitled to trial within a reasonable time or to release. It shall not be the general rule that persons awaiting trial shall be detained in custody, but release may be subject to guarantees to appear for trial, at any other stage of the judicial proceedings, and, should occasion arise, for execution of the judgement. <br />
<br />
4. Anyone who is deprived of his liberty by arrest or detention shall be entitled to take proceedings before a court, in order that that court may decide without delay on the lawfulness of his detention and order his release if the detention is not lawful. <br />
<br />
5. Anyone who has been the victim of unlawful arrest or detention shall have an enforceable right to compensation. <br />
<br />
==== Article 10 ====<br />
<br />
1. All persons deprived of their liberty shall be treated with humanity and with respect for the inherent dignity of the human person. <br />
<br />
2. <br />
<br />
: (a) Accused persons shall, save in exceptional circumstances, be segregated from convicted persons and shall be subject to separate treatment appropriate to their status as unconvicted persons; <br />
<br />
: (b) Accused juvenile persons shall be separated from adults and brought as speedily as possible for adjudication. <br />
<br />
3. The penitentiary system shall comprise treatment of prisoners the essential aim of which shall be their reformation and social rehabilitation. Juvenile offenders shall be segregated from adults and be accorded treatment appropriate to their age and legal status. <br />
<br />
==== Article 11 ====<br />
No one shall be imprisoned merely on the ground of inability to fulfil a contractual obligation. <br />
<br />
==== Article 12 ====<br />
<br />
1. Everyone lawfully within the territory of a State shall, within that territory, have the right to liberty of movement and freedom to choose his residence. <br />
<br />
2. Everyone shall be free to leave any country, including his own. <br />
<br />
3. The above-mentioned rights shall not be subject to any restrictions except those which are provided by law, are necessary to protect national security, public order (ordre public), public health or morals or the rights and freedoms of others, and are consistent with the other rights recognized in the present Covenant. <br />
<br />
4. No one shall be arbitrarily deprived of the right to enter his own country. <br />
<br />
==== Article 13 ====<br />
<br />
An alien lawfully in the territory of a State Party to the present Covenant may be expelled therefrom only in pursuance of a decision reached in accordance with law and shall, except where compelling reasons of national security otherwise require, be allowed to submit the reasons against his expulsion and to have his case reviewed by, and be represented for the purpose before, the competent authority or a person or persons especially designated by the competent authority. <br />
<br />
==== Article 14 ====<br />
<br />
1. All persons shall be equal before the courts and tribunals. In the determination of any criminal charge against him, or of his rights and obligations in a suit at law, everyone shall be entitled to a fair and public hearing by a competent, independent and impartial tribunal established by law. The press and the public may be excluded from all or part of a trial for reasons of morals, public order (ordre public) or national security in a democratic society, or when the interest of the private lives of the parties so requires, or to the extent strictly necessary in the opinion of the court in special circumstances where publicity would prejudice the interests of justice; but any judgement rendered in a criminal case or in a suit at law shall be made public except where the interest of juvenile persons otherwise requires or the proceedings concern matrimonial disputes or the guardianship of children. <br />
<br />
2. Everyone charged with a criminal offence shall have the right to be presumed innocent until proved guilty according to law. <br />
<br />
3. In the determination of any criminal charge against him, everyone shall be entitled to the following minimum guarantees, in full equality: (a) To be informed promptly and in detail in a language which he understands of the nature and cause of the charge against him; <br />
<br />
: (b) To have adequate time and facilities for the preparation of his defence and to communicate with counsel of his own choosing; <br />
<br />
: (c) To be tried without undue delay; <br />
<br />
: (d) To be tried in his presence, and to defend himself in person or through legal assistance of his own choosing; to be informed, if he does not have legal assistance, of this right; and to have legal assistance assigned to him, in any case where the interests of justice so require, and without payment by him in any such case if he does not have sufficient means to pay for it; <br />
<br />
: (e) To examine, or have examined, the witnesses against him and to obtain the attendance and examination of witnesses on his behalf under the same conditions as witnesses against him; <br />
<br />
: (f) To have the free assistance of an interpreter if he cannot understand or speak the language used in court; <br />
<br />
: (g) Not to be compelled to testify against himself or to confess guilt. <br />
4. In the case of juvenile persons, the procedure shall be such as will take account of their age and the desirability of promoting their rehabilitation. <br />
<br />
5. Everyone convicted of a crime shall have the right to his conviction and sentence being reviewed by a higher tribunal according to law. <br />
<br />
6. When a person has by a final decision been convicted of a criminal offence and when subsequently his conviction has been reversed or he has been pardoned on the ground that a new or newly discovered fact shows conclusively that there has been a miscarriage of justice, the person who has suffered punishment as a result of such conviction shall be compensated according to law, unless it is proved that the non-disclosure of the unknown fact in time is wholly or partly attributable to him. <br />
<br />
7. No one shall be liable to be tried or punished again for an offence for which he has already been finally convicted or acquitted in accordance with the law and penal procedure of each country. <br />
<br />
==== Article 15 ====<br />
<br />
1 . No one shall be held guilty of any criminal offence on account of any act or omission which did not constitute a criminal offence, under national or international law, at the time when it was committed. Nor shall a heavier penalty be imposed than the one that was applicable at the time when the criminal offence was committed. If, subsequent to the commission of the offence, provision is made by law for the imposition of the lighter penalty, the offender shall benefit thereby. <br />
<br />
2. Nothing in this article shall prejudice the trial and punishment of any person for any act or omission which, at the time when it was committed, was criminal according to the general principles of law recognized by the community of nations. <br />
<br />
==== Article 16 ====<br />
<br />
Everyone shall have the right to recognition everywhere as a person before the law. <br />
<br />
==== Article 17 ====<br />
<br />
1. No one shall be subjected to arbitrary or unlawful interference with his privacy, family, home or correspondence, nor to unlawful attacks on his honour and reputation. <br />
<br />
2. Everyone has the right to the protection of the law against such interference or attacks. <br />
<br />
==== Article 18 ====<br />
<br />
1. Everyone shall have the right to freedom of thought, conscience and religion. This right shall include freedom to have or to adopt a religion or belief of his choice, and freedom, either individually or in community with others and in public or private, to manifest his religion or belief in worship, observance, practice and teaching. <br />
<br />
2. No one shall be subject to coercion which would impair his freedom to have or to adopt a religion or belief of his choice. <br />
<br />
3. Freedom to manifest one's religion or beliefs may be subject only to such limitations as are prescribed by law and are necessary to protect public safety, order, health, or morals or the fundamental rights and freedoms of others. <br />
<br />
4. The States Parties to the present Covenant undertake to have respect for the liberty of parents and, when applicable, legal guardians to ensure the religious and moral education of their children in conformity with their own convictions. <br />
<br />
==== Article 19 ====<br />
<br />
1. Everyone shall have the right to hold opinions without interference. <br />
<br />
2. Everyone shall have the right to freedom of expression; this right shall include freedom to seek, receive and impart information and ideas of all kinds, regardless of frontiers, either orally, in writing or in print, in the form of art, or through any other media of his choice. <br />
<br />
3. The exercise of the rights provided for in paragraph 2 of this article carries with it special duties and responsibilities. It may therefore be subject to certain restrictions, but these shall only be such as are provided by law and are necessary: <br />
<br />
: (a) For respect of the rights or reputations of others; <br />
<br />
: (b) For the protection of national security or of public order (ordre public), or of public health or morals. <br />
<br />
==== Article 20 ====<br />
<br />
1. Any propaganda for war shall be prohibited by law. <br />
<br />
2. Any advocacy of national, racial or religious hatred that constitutes incitement to discrimination, hostility or violence shall be prohibited by law. <br />
<br />
==== Article 21 ====<br />
<br />
The right of peaceful assembly shall be recognized. No restrictions may be placed on the exercise of this right other than those imposed in conformity with the law and which are necessary in a democratic society in the interests of national security or public safety, public order (ordre public), the protection of public health or morals or the protection of the rights and freedoms of others. <br />
<br />
==== Article 22 ====<br />
<br />
1. Everyone shall have the right to freedom of association with others, including the right to form and join trade unions for the protection of his interests. <br />
<br />
2. No restrictions may be placed on the exercise of this right other than those which are prescribed by law and which are necessary in a democratic society in the interests of national security or public safety, public order (ordre public), the protection of public health or morals or the protection of the rights and freedoms of others. This article shall not prevent the imposition of lawful restrictions on members of the armed forces and of the police in their exercise of this right. <br />
<br />
3. Nothing in this article shall authorize States Parties to the International Labour Organisation Convention of 1948 concerning Freedom of Association and Protection of the Right to Organize to take legislative measures which would prejudice, or to apply the law in such a manner as to prejudice, the guarantees provided for in that Convention. <br />
<br />
==== Article 23 ====<br />
<br />
1. The family is the natural and fundamental group unit of society and is entitled to protection by society and the State. <br />
<br />
2. The right of men and women of marriageable age to marry and to found a family shall be recognized. <br />
<br />
3. No marriage shall be entered into without the free and full consent of the intending spouses. <br />
<br />
4. States Parties to the present Covenant shall take appropriate steps to ensure equality of rights and responsibilities of spouses as to marriage, during marriage and at its dissolution. In the case of dissolution, provision shall be made for the necessary protection of any children. <br />
<br />
==== Article 24 ====<br />
<br />
1. Every child shall have, without any discrimination as to race, colour, sex, language, religion, national or social origin, property or birth, the right to such measures of protection as are required by his status as a minor, on the part of his family, society and the State. <br />
<br />
2. Every child shall be registered immediately after birth and shall have a name. <br />
<br />
3. Every child has the right to acquire a nationality. <br />
<br />
==== Article 25 ====<br />
<br />
Every citizen shall have the right and the opportunity, without any of the distinctions mentioned in article 2 and without unreasonable restrictions: <br />
<br />
: (a) To take part in the conduct of public affairs, directly or through freely chosen representatives; <br />
<br />
: (b) To vote and to be elected at genuine periodic elections which shall be by universal and equal suffrage and shall be held by secret ballot, guaranteeing the free expression of the will of the electors; <br />
<br />
: (c) To have access, on general terms of equality, to public service in his country. <br />
<br />
==== Article 26 ====<br />
<br />
All persons are equal before the law and are entitled without any discrimination to the equal protection of the law. In this respect, the law shall prohibit any discrimination and guarantee to all persons equal and effective protection against discrimination on any ground such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status. <br />
<br />
==== Article 27 ====<br />
<br />
In those States in which ethnic, religious or linguistic minorities exist, persons belonging to such minorities shall not be denied the right, in community with the other members of their group, to enjoy their own culture, to profess and practise their own religion, or to use their own language.<br />
<br />
==<br/> PART IV ==<br />
<br />
==== Article 28 ====<br />
<br />
1. There shall be established a Human Rights Committee (hereafter referred to in the present Covenant as the Committee). It shall consist of eighteen members and shall carry out the functions hereinafter provided. <br />
<br />
2. The Committee shall be composed of nationals of the States Parties to the present Covenant who shall be persons of high moral character and recognized competence in the field of human rights, consideration being given to the usefulness of the participation of some persons having legal experience. <br />
<br />
3. The members of the Committee shall be elected and shall serve in their personal capacity. <br />
<br />
==== Article 29 ====<br />
<br />
1. The members of the Committee shall be elected by secret ballot from a list of persons possessing the qualifications prescribed in article 28 and nominated for the purpose by the States Parties to the present Covenant. <br />
<br />
2. Each State Party to the present Covenant may nominate not more than two persons. These persons shall be nationals of the nominating State. <br />
<br />
3. A person shall be eligible for renomination. <br />
<br />
==== Article 30 ====<br />
<br />
1. The initial election shall be held no later than six months after the date of the entry into force of the present Covenant. <br />
<br />
2. At least four months before the date of each election to the Committee, other than an election to fill a vacancy declared in accordance with article 34, the Secretary-General of the United Nations shall address a written invitation to the States Parties to the present Covenant to submit their nominations for membership of the Committee within three months. <br />
<br />
3. The Secretary-General of the United Nations shall prepare a list in alphabetical order of all the persons thus nominated, with an indication of the States Parties which have nominated them, and shall submit it to the States Parties to the present Covenant no later than one month before the date of each election. <br />
<br />
4. Elections of the members of the Committee shall be held at a meeting of the States Parties to the present Covenant convened by the Secretary General of the United Nations at the Headquarters of the United Nations. At that meeting, for which two thirds of the States Parties to the present Covenant shall constitute a quorum, the persons elected to the Committee shall be those nominees who obtain the largest number of votes and an absolute majority of the votes of the representatives of States Parties present and voting. <br />
<br />
==== Article 31 ====<br />
<br />
1. The Committee may not include more than one national of the same State. <br />
<br />
2. In the election of the Committee, consideration shall be given to equitable geographical distribution of membership and to the representation of the different forms of civilization and of the principal legal systems. <br />
<br />
==== Article 32 ====<br />
1. The members of the Committee shall be elected for a term of four years. They shall be eligible for re-election if renominated. However, the terms of nine of the members elected at the first election shall expire at the end of two years; immediately after the first election, the names of these nine members shall be chosen by lot by the Chairman of the meeting referred to in article 30, paragraph 4. <br />
<br />
2. Elections at the expiry of office shall be held in accordance with the preceding articles of this part of the present Covenant. <br />
<br />
==== Article 33 ====<br />
<br />
1. If, in the unanimous opinion of the other members, a member of the Committee has ceased to carry out his functions for any cause other than absence of a temporary character, the Chairman of the Committee shall notify the Secretary-General of the United Nations, who shall then declare the seat of that member to be vacant. <br />
<br />
2. In the event of the death or the resignation of a member of the Committee, the Chairman shall immediately notify the Secretary-General of the United Nations, who shall declare the seat vacant from the date of death or the date on which the resignation takes effect. <br />
<br />
==== Article 34 ====<br />
<br />
1. When a vacancy is declared in accordance with article 33 and if the term of office of the member to be replaced does not expire within six months of the declaration of the vacancy, the Secretary-General of the United Nations shall notify each of the States Parties to the present Covenant, which may within two months submit nominations in accordance with article 29 for the purpose of filling the vacancy. <br />
<br />
2. The Secretary-General of the United Nations shall prepare a list in alphabetical order of the persons thus nominated and shall submit it to the States Parties to the present Covenant. The election to fill the vacancy shall then take place in accordance with the relevant provisions of this part of the present Covenant. <br />
<br />
3. A member of the Committee elected to fill a vacancy declared in accordance with article 33 shall hold office for the remainder of the term of the member who vacated the seat on the Committee under the provisions of that article. <br />
<br />
==== Article 35 ====<br />
<br />
The members of the Committee shall, with the approval of the General Assembly of the United Nations, receive emoluments from United Nations resources on such terms and conditions as the General Assembly may decide, having regard to the importance of the Committee's responsibilities. <br />
<br />
==== Article 36 ====<br />
<br />
The Secretary-General of the United Nations shall provide the necessary staff and facilities for the effective performance of the functions of the Committee under the present Covenant. <br />
<br />
==== Article 37 ====<br />
<br />
1. The Secretary-General of the United Nations shall convene the initial meeting of the Committee at the Headquarters of the United Nations. <br />
<br />
2. After its initial meeting, the Committee shall meet at such times as shall be provided in its rules of procedure. <br />
<br />
3. The Committee shall normally meet at the Headquarters of the United Nations or at the United Nations Office at Geneva. <br />
<br />
==== Article 38 ====<br />
<br />
Every member of the Committee shall, before taking up his duties, make a solemn declaration in open committee that he will perform his functions impartially and conscientiously. <br />
<br />
==== Article 39 ====<br />
<br />
1. The Committee shall elect its officers for a term of two years. They may be re-elected. <br />
<br />
2. The Committee shall establish its own rules of procedure, but these rules shall provide, inter alia, that: <br />
<br />
: (a) Twelve members shall constitute a quorum; <br />
<br />
: (b) Decisions of the Committee shall be made by a majority vote of the members present. <br />
<br />
==== Article 40 ====<br />
<br />
1. The States Parties to the present Covenant undertake to submit reports on the measures they have adopted which give effect to the rights recognized herein and on the progress made in the enjoyment of those rights: (a) Within one year of the entry into force of the present Covenant for the States Parties concerned; <br />
<br />
: (b) Thereafter whenever the Committee so requests. <br />
<br />
2. All reports shall be submitted to the Secretary-General of the United Nations, who shall transmit them to the Committee for consideration. Reports shall indicate the factors and difficulties, if any, affecting the implementation of the present Covenant. <br />
<br />
3. The Secretary-General of the United Nations may, after consultation with the Committee, transmit to the specialized agencies concerned copies of such parts of the reports as may fall within their field of competence. <br />
<br />
4. The Committee shall study the reports submitted by the States Parties to the present Covenant. It shall transmit its reports, and such general comments as it may consider appropriate, to the States Parties. The Committee may also transmit to the Economic and Social Council these comments along with the copies of the reports it has received from States Parties to the present Covenant. <br />
<br />
5. The States Parties to the present Covenant may submit to the Committee observations on any comments that may be made in accordance with paragraph 4 of this article. <br />
<br />
==== Article 41 ====<br />
<br />
1. A State Party to the present Covenant may at any time declare under this article that it recognizes the competence of the Committee to receive and consider communications to the effect that a State Party claims that another State Party is not fulfilling its obligations under the present Covenant. Communications under this article may be received and considered only if submitted by a State Party which has made a declaration recognizing in regard to itself the competence of the Committee. No communication shall be received by the Committee if it concerns a State Party which has not made such a declaration. Communications received under this article shall be dealt with in accordance with the following procedure: <br />
<br />
: (a) If a State Party to the present Covenant considers that another State Party is not giving effect to the provisions of the present Covenant, it may, by written communication, bring the matter to the attention of that State Party. Within three months after the receipt of the communication the receiving State shall afford the State which sent the communication an explanation, or any other statement in writing clarifying the matter which should include, to the extent possible and pertinent, reference to domestic procedures and remedies taken, pending, or available in the matter; <br />
<br />
: (b) If the matter is not adjusted to the satisfaction of both States Parties concerned within six months after the receipt by the receiving State of the initial communication, either State shall have the right to refer the matter to the Committee, by notice given to the Committee and to the other State; <br />
<br />
: (c) The Committee shall deal with a matter referred to it only after it has ascertained that all available domestic remedies have been invoked and exhausted in the matter, in conformity with the generally recognized principles of international law. This shall not be the rule where the application of the remedies is unreasonably prolonged; <br />
<br />
: (d) The Committee shall hold closed meetings when examining communications under this article; <br />
<br />
: (e) Subject to the provisions of subparagraph (c), the Committee shall make available its good offices to the States Parties concerned with a view to a friendly solution of the matter on the basis of respect for human rights and fundamental freedoms as recognized in the present Covenant; <br />
<br />
: (f) In any matter referred to it, the Committee may call upon the States Parties concerned, referred to in subparagraph (b), to supply any relevant information; <br />
<br />
: (g) The States Parties concerned, referred to in subparagraph (b), shall have the right to be represented when the matter is being considered in the Committee and to make submissions orally and/or in writing; <br />
<br />
: (h) The Committee shall, within twelve months after the date of receipt of notice under subparagraph (b), submit a report: <br />
<br />
: (i) If a solution within the terms of subparagraph (e) is reached, the Committee shall confine its report to a brief statement of the facts and of the solution reached; <br />
<br />
: (ii) If a solution within the terms of subparagraph (e) is not reached, the Committee shall confine its report to a brief statement of the facts; the written submissions and record of the oral submissions made by the States Parties concerned shall be attached to the report. In every matter, the report shall be communicated to the States Parties concerned. <br />
<br />
2. The provisions of this article shall come into force when ten States Parties to the present Covenant have made declarations under paragraph I of this article. Such declarations shall be deposited by the States Parties with the Secretary-General of the United Nations, who shall transmit copies thereof to the other States Parties. A declaration may be withdrawn at any time by notification to the Secretary-General. Such a withdrawal shall not prejudice the consideration of any matter which is the subject of a communication already transmitted under this article; no further communication by any State Party shall be received after the notification of withdrawal of the declaration has been received by the Secretary-General, unless the State Party concerned has made a new declaration. <br />
<br />
==== Article 42 ====<br />
<br />
1. <br />
<br />
: (a) If a matter referred to the Committee in accordance with article 41 is not resolved to the satisfaction of the States Parties concerned, the Committee may, with the prior consent of the States Parties concerned, appoint an ad hoc Conciliation Commission (hereinafter referred to as the Commission). The good offices of the Commission shall be made available to the States Parties concerned with a view to an amicable solution of the matter on the basis of respect for the present Covenant; <br />
<br />
: (b) The Commission shall consist of five persons acceptable to the States Parties concerned. If the States Parties concerned fail to reach agreement within three months on all or part of the composition of the Commission, the members of the Commission concerning whom no agreement has been reached shall be elected by secret ballot by a two-thirds majority vote of the Committee from among its members. <br />
<br />
2. The members of the Commission shall serve in their personal capacity. They shall not be nationals of the States Parties concerned, or of a State not Party to the present Covenant, or of a State Party which has not made a declaration under article 41. <br />
<br />
3. The Commission shall elect its own Chairman and adopt its own rules of procedure. <br />
<br />
4. The meetings of the Commission shall normally be held at the Headquarters of the United Nations or at the United Nations Office at Geneva. However, they may be held at such other convenient places as the Commission may determine in consultation with the Secretary-General of the United Nations and the States Parties concerned. <br />
<br />
5. The secretariat provided in accordance with article 36 shall also service the commissions appointed under this article. <br />
<br />
6. The information received and collated by the Committee shall be made available to the Commission and the Commission may call upon the States Parties concerned to supply any other relevant information. <br />
<br />
7. When the Commission has fully considered the matter, but in any event not later than twelve months after having been seized of the matter, it shall submit to the Chairman of the Committee a report for communication to the States Parties concerned: <br />
<br />
: (a) If the Commission is unable to complete its consideration of the matter within twelve months, it shall confine its report to a brief statement of the status of its consideration of the matter; <br />
<br />
: (b) If an amicable solution to the matter on tie basis of respect for human rights as recognized in the present Covenant is reached, the Commission shall confine its report to a brief statement of the facts and of the solution reached; <br />
<br />
: (c) If a solution within the terms of subparagraph (b) is not reached, the Commission's report shall embody its findings on all questions of fact relevant to the issues between the States Parties concerned, and its views on the possibilities of an amicable solution of the matter. This report shall also contain the written submissions and a record of the oral submissions made by the States Parties concerned; <br />
<br />
: (d) If the Commission's report is submitted under subparagraph (c), the States Parties concerned shall, within three months of the receipt of the report, notify the Chairman of the Committee whether or not they accept the contents of the report of the Commission. <br />
<br />
8. The provisions of this article are without prejudice to the responsibilities of the Committee under article 41. <br />
<br />
9. The States Parties concerned shall share equally all the expenses of the members of the Commission in accordance with estimates to be provided by the Secretary-General of the United Nations. <br />
<br />
10. The Secretary-General of the United Nations shall be empowered to pay the expenses of the members of the Commission, if necessary, before reimbursement by the States Parties concerned, in accordance with paragraph 9 of this article. <br />
<br />
==== Article 43 ====<br />
<br />
The members of the Committee, and of the ad hoc conciliation commissions which may be appointed under article 42, shall be entitled to the facilities, privileges and immunities of experts on mission for the United Nations as laid down in the relevant sections of the Convention on the Privileges and Immunities of the United Nations. <br />
<br />
==== Article 44 ====<br />
<br />
The provisions for the implementation of the present Covenant shall apply without prejudice to the procedures prescribed in the field of human rights by or under the constituent instruments and the conventions of the United Nations and of the specialized agencies and shall not prevent the States Parties to the present Covenant from having recourse to other procedures for settling a dispute in accordance with general or special international agreements in force between them. <br />
<br />
==== Article 45 ====<br />
<br />
The Committee shall submit to the General Assembly of the United Nations, through the Economic and Social Council, an annual report on its activities.<br />
<br />
==<br/> PART V ==<br />
<br />
==== Article 46 ====<br />
<br />
Nothing in the present Covenant shall be interpreted as impairing the provisions of the Charter of the United Nations and of the constitutions of the specialized agencies which define the respective responsibilities of the various organs of the United Nations and of the specialized agencies in regard to the matters dealt with in the present Covenant. <br />
<br />
==== Article 47 ====<br />
<br />
Nothing in the present Covenant shall be interpreted as impairing the inherent right of all peoples to enjoy and utilize fully and freely their natural wealth and resources.<br />
<br />
==<br/> PART VI ==<br />
<br />
==== Article 48 ====<br />
<br />
1. The present Covenant is open for signature by any State Member of the United Nations or member of any of its specialized agencies, by any State Party to the Statute of the International Court of Justice, and by any other State which has been invited by the General Assembly of the United Nations to become a Party to the present Covenant. <br />
<br />
2. The present Covenant is subject to ratification. Instruments of ratification shall be deposited with the Secretary-General of the United Nations. <br />
<br />
3. The present Covenant shall be open to accession by any State referred to in paragraph 1 of this article. <br />
<br />
4. Accession shall be effected by the deposit of an instrument of accession with the Secretary-General of the United Nations. <br />
<br />
5. The Secretary-General of the United Nations shall inform all States which have signed this Covenant or acceded to it of the deposit of each instrument of ratification or accession. <br />
<br />
==== Article 49 ====<br />
<br />
1. The present Covenant shall enter into force three months after the date of the deposit with the Secretary-General of the United Nations of the thirty-fifth instrument of ratification or instrument of accession. <br />
<br />
2. For each State ratifying the present Covenant or acceding to it after the deposit of the thirty-fifth instrument of ratification or instrument of accession, the present Covenant shall enter into force three months after the date of the deposit of its own instrument of ratification or instrument of accession. <br />
<br />
==== Article 50 ====<br />
<br />
The provisions of the present Covenant shall extend to all parts of federal States without any limitations or exceptions. <br />
<br />
==== Article 51 ====<br />
<br />
1. Any State Party to the present Covenant may propose an amendment and file it with the Secretary-General of the United Nations. The Secretary-General of the United Nations shall thereupon communicate any proposed amendments to the States Parties to the present Covenant with a request that they notify him whether they favour a conference of States Parties for the purpose of considering and voting upon the proposals. In the event that at least one third of the States Parties favours such a conference, the Secretary-General shall convene the conference under the auspices of the United Nations. Any amendment adopted by a majority of the States Parties present and voting at the conference shall be submitted to the General Assembly of the United Nations for approval. <br />
<br />
2. Amendments shall come into force when they have been approved by the General Assembly of the United Nations and accepted by a two-thirds majority of the States Parties to the present Covenant in accordance with their respective constitutional processes. 3. When amendments come into force, they shall be binding on those States Parties which have accepted them, other States Parties still being bound by the provisions of the present Covenant and any earlier amendment which they have accepted. <br />
<br />
==== Article 52 ====<br />
<br />
1. Irrespective of the notifications made under article 48, paragraph 5, the Secretary-General of the United Nations shall inform all States referred to in paragraph I of the same article of the following particulars: <br />
<br />
: (a) Signatures, ratifications and accessions under article 48; <br />
<br />
: (b) The date of the entry into force of the present Covenant under article 49 and the date of the entry into force of any amendments under article 51. <br />
<br />
==== Article 53 ====<br />
<br />
1. The present Covenant, of which the Chinese, English, French, Russian and Spanish texts are equally authentic, shall be deposited in the archives of the United Nations. <br />
<br />
2. The Secretary-General of the United Nations shall transmit certified copies of the present Covenant to all States referred to in article 48.<br />
<br />
<br/></div>Sysophttp://iuwg.net/index.php/The_Universal_Declaration_of_Human_RightsThe Universal Declaration of Human Rights2017-04-09T21:18:46Z<p>Sysop: </p>
<hr />
<div><br/><br />
The Universal Declaration of Human Rights (UDHR) is a milestone document in the history of human rights. Drafted by representatives with different legal and cultural backgrounds from all regions of the world, the Declaration was proclaimed by the United Nations General Assembly in Paris on 10 December 1948 General Assembly resolution 217 A as a common standard of achievements for all peoples and all nations. It sets out, for the first time, fundamental human rights to be universally protected. <br />
<br />
<br />
__TOC__<br />
<br />
<br />
==== Preamble ====<br />
<br />
Whereas recognition of the inherent dignity and of the equal and inalienable rights of all members of the human family is the foundation of freedom, justice and peace in the world, <br />
<br />
Whereas disregard and contempt for human rights have resulted in barbarous acts which have outraged the conscience of mankind, and the advent of a world in which human beings shall enjoy freedom of speech and belief and freedom from fear and want has been proclaimed as the highest aspiration of the common people, <br />
<br />
Whereas it is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law, <br />
<br />
Whereas it is essential to promote the development of friendly relations between nations, <br />
<br />
Whereas the peoples of the United Nations have in the Charter reaffirmed their faith in fundamental human rights, in the dignity and worth of the human person and in the equal rights of men and women and have determined to promote social progress and better standards of life in larger freedom, <br />
<br />
Whereas Member States have pledged themselves to achieve, in co-operation with the United Nations, the promotion of universal respect for and observance of human rights and fundamental freedoms, <br />
<br />
Whereas a common understanding of these rights and freedoms is of the greatest importance for the full realization of this pledge, <br />
<br />
Now, Therefore THE GENERAL ASSEMBLY proclaims THIS UNIVERSAL DECLARATION OF HUMAN RIGHTS as a common standard of achievement for all peoples and all nations, to the end that every individual and every organ of society, keeping this Declaration constantly in mind, shall strive by teaching and education to promote respect for these rights and freedoms and by progressive measures, national and international, to secure their universal and effective recognition and observance, both among the peoples of Member States themselves and among the peoples of territories under their jurisdiction. <br />
<br />
==== Article 1. ====<br />
<br />
All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. <br />
<br />
==== Article 2. ====<br />
<br />
Everyone is entitled to all the rights and freedoms set forth in this Declaration, without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status. Furthermore, no distinction shall be made on the basis of the political, jurisdictional or international status of the country or territory to which a person belongs, whether it be independent, trust, non-self-governing or under any other limitation of sovereignty. <br />
<br />
==== Article 3. ====<br />
<br />
Everyone has the right to life, liberty and security of person. <br />
<br />
==== Article 4. ====<br />
<br />
No one shall be held in slavery or servitude; slavery and the slave trade shall be prohibited in all their forms. <br />
<br />
==== Article 5. ====<br />
<br />
No one shall be subjected to torture or to cruel, inhuman or degrading treatment or punishment. <br />
<br />
==== Article 6. ====<br />
<br />
Everyone has the right to recognition everywhere as a person before the law. <br />
<br />
==== Article 7. ====<br />
<br />
All are equal before the law and are entitled without any discrimination to equal protection of the law. All are entitled to equal protection against any discrimination in violation of this Declaration and against any incitement to such discrimination. <br />
<br />
==== Article 8. ====<br />
<br />
Everyone has the right to an effective remedy by the competent national tribunals for acts violating the fundamental rights granted him by the constitution or by law. <br />
<br />
==== Article 9. ====<br />
<br />
No one shall be subjected to arbitrary arrest, detention or exile. <br />
<br />
==== Article 10. ====<br />
<br />
Everyone is entitled in full equality to a fair and public hearing by an independent and impartial tribunal, in the determination of his rights and obligations and of any criminal charge against him. <br />
<br />
==== Article 11. ====<br />
<br />
: (1) Everyone charged with a penal offence has the right to be presumed innocent until proved guilty according to law in a public trial at which he has had all the guarantees necessary for his defence. <br />
: (2) No one shall be held guilty of any penal offence on account of any act or omission which did not constitute a penal offence, under national or international law, at the time when it was committed. Nor shall a heavier penalty be imposed than the one that was applicable at the time the penal offence was committed. <br />
<br />
==== Article 12. ====<br />
<br />
No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks. <br />
<br />
==== Article 13. ====<br />
<br />
: (1) Everyone has the right to freedom of movement and residence within the borders of each state. <br />
: (2) Everyone has the right to leave any country, including his own, and to return to his country. <br />
<br />
==== Article 14. ====<br />
<br />
: (1) Everyone has the right to seek and to enjoy in other countries asylum from persecution. <br />
: (2) This right may not be invoked in the case of prosecutions genuinely arising from non-political crimes or from acts contrary to the purposes and principles of the United Nations. <br />
<br />
==== Article 15. ====<br />
<br />
: (1) Everyone has the right to a nationality. <br />
: (2) No one shall be arbitrarily deprived of his nationality nor denied the right to change his nationality. <br />
<br />
==== Article 16. ====<br />
<br />
: (1) Men and women of full age, without any limitation due to race, nationality or religion, have the right to marry and to found a family. They are entitled to equal rights as to marriage, during marriage and at its dissolution. <br />
: (2) Marriage shall be entered into only with the free and full consent of the intending spouses. <br />
: (3) The family is the natural and fundamental group unit of society and is entitled to protection by society and the State. <br />
<br />
==== Article 17. ====<br />
<br />
: (1) Everyone has the right to own property alone as well as in association with others. <br />
: (2) No one shall be arbitrarily deprived of his property. <br />
<br />
==== Article 18. ====<br />
<br />
Everyone has the right to freedom of thought, conscience and religion; this right includes freedom to change his religion or belief, and freedom, either alone or in community with others and in public or private, to manifest his religion or belief in teaching, practice, worship and observance. <br />
<br />
==== Article 19. ====<br />
<br />
Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers. <br />
<br />
==== Article 20. ====<br />
<br />
: (1) Everyone has the right to freedom of peaceful assembly and association. <br />
: (2) No one may be compelled to belong to an association. <br />
<br />
==== Article 21. ====<br />
<br />
: (1) Everyone has the right to take part in the government of his country, directly or through freely chosen representatives. <br />
: (2) Everyone has the right of equal access to public service in his country. <br />
: (3) The will of the people shall be the basis of the authority of government; this will shall be expressed in periodic and genuine elections which shall be by universal and equal suffrage and shall be held by secret vote or by equivalent free voting procedures. <br />
<br />
==== Article 22. ====<br />
<br />
Everyone, as a member of society, has the right to social security and is entitled to realization, through national effort and international co-operation and in accordance with the organization and resources of each State, of the economic, social and cultural rights indispensable for his dignity and the free development of his personality. <br />
<br />
==== Article 23. ====<br />
<br />
: (1) Everyone has the right to work, to free choice of employment, to just and favourable conditions of work and to protection against unemployment. <br />
: (2) Everyone, without any discrimination, has the right to equal pay for equal work. <br />
: (3) Everyone who works has the right to just and favourable remuneration ensuring for himself and his family an existence worthy of human dignity, and supplemented, if necessary, by other means of social protection. <br />
: (4) Everyone has the right to form and to join trade unions for the protection of his interests. <br />
<br />
==== Article 24. ====<br />
<br />
Everyone has the right to rest and leisure, including reasonable limitation of working hours and periodic holidays with pay. <br />
<br />
==== Article 25. ====<br />
<br />
: (1) Everyone has the right to a standard of living adequate for the health and well-being of himself and of his family, including food, clothing, housing and medical care and necessary social services, and the right to security in the event of unemployment, sickness, disability, widowhood, old age or other lack of livelihood in circumstances beyond his control. <br />
: (2) Motherhood and childhood are entitled to special care and assistance. All children, whether born in or out of wedlock, shall enjoy the same social protection. <br />
<br />
==== Article 26. ====<br />
<br />
: (1) Everyone has the right to education. Education shall be free, at least in the elementary and fundamental stages. Elementary education shall be compulsory. Technical and professional education shall be made generally available and higher education shall be equally accessible to all on the basis of merit. <br />
: (2) Education shall be directed to the full development of the human personality and to the strengthening of respect for human rights and fundamental freedoms. It shall promote understanding, tolerance and friendship among all nations, racial or religious groups, and shall further the activities of the United Nations for the maintenance of peace. <br />
: (3) Parents have a prior right to choose the kind of education that shall be given to their children. <br />
<br />
==== Article 27. ====<br />
<br />
: (1) Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits. <br />
: (2) Everyone has the right to the protection of the moral and material interests resulting from any scientific, literary or artistic production of which he is the author. <br />
<br />
==== Article 28. ====<br />
<br />
Everyone is entitled to a social and international order in which the rights and freedoms set forth in this Declaration can be fully realized. <br />
<br />
==== Article 29. ====<br />
<br />
<br />
: (1) Everyone has duties to the community in which alone the free and full development of his personality is possible. <br />
: (2) In the exercise of his rights and freedoms, everyone shall be subject only to such limitations as are determined by law solely for the purpose of securing due recognition and respect for the rights and freedoms of others and of meeting the just requirements of morality, public order and the general welfare in a democratic society. <br />
: (3) These rights and freedoms may in no case be exercised contrary to the purposes and principles of the United Nations. <br />
<br />
==== Article 30. ====<br />
<br />
Nothing in this Declaration may be interpreted as implying for any State, group or person any right to engage in any activity or to perform any act aimed at the destruction of any of the rights and freedoms set forth herein.<br />
<br />
<br/></div>Sysophttp://iuwg.net/index.php/HRPC-Draft-reasearch_AnnotationsHRPC-Draft-reasearch Annotations2017-04-09T20:43:48Z<p>Sysop: Sysop moved page HRPC-Draft-reasearch Annotations to Commented HRPC-Draft-reasearch</p>
<hr />
<div>This documents aims to document the relation between Internet<br />
protocols and the right to freedom of assembly and association. The<br />
Internet increasingly mediates our lives and thus the ability to<br />
excercise human rights. Since Internet protocols play a central role<br />
in the management, development and use of the Internet the relation<br />
between the two should be documented and adverse impacts on this<br />
human right should be mitigated. On the other hand there have also<br />
been methods of protest, a form of freedom of assembly, on the<br />
Internet that have been harmful to Internet connectivity and the<br />
Internet infrastructure, such as DDoS attacks. This document aims to<br />
document forms of protest, association and assembly that do not have<br />
a negative impact on the Internet infrastructure.<br />
<br />
{{ann}} Have been introduced two types of comments. Those originating from WG/HRPC members and those originating from XLIBRE members. They have been identified in the header of the annotate.<br />
<br />
<br />
__TOC__<br />
<br />
==<br/> 1. Introduction ==<br />
<br />
Freedom of assembly and freedom of association are two human rights<br />
that protect and enable collective action and expression [UDHR]<br />
[ICCPR]. This is important because causes and opinions take more<br />
force within a group of people that come together for the same means<br />
[Tocqueville].<br />
<br />
The difference between the freedom of assembly and the freedom of<br />
associotiation is merely gradual one. An assembly is an intentional<br />
and temporary gathering of a collective in a private or public space<br />
for a specific purpose: demonstrations, inside meetings, strikes,<br />
processions, rallies or even sits-in [UNHRC]. The right to protest<br />
is one of the rights encompassed by freedom of assembly, but also<br />
exercised along with freedom of expression and the right to hold an<br />
opinion. Nonetheless, protest unlike assembly, implies an element of<br />
dissent that can be exercised individually, where as assembly always<br />
has a collective component [ARTICLE19].<br />
<br />
Association on the other hand has a more formal nature. It refers to<br />
a group of individuals or any legal entities brought together in<br />
order to collectively act, express, promote, pursue or defend a field<br />
of common interests [UNGA]. This means civil society organizations,<br />
clubs, cooperatives, NGOs, religious associations, political parties,<br />
trade unions, foundations or even online associations as the Internet<br />
has been instrumental, for instance, in 'facilitating active citizen<br />
participation in building democratic societies' [UNHRC].<br />
<br />
In less democratic or authoritarian countries, online association and<br />
assembly has been crucial to mobilise groups and people, where<br />
physical gatherings have been impossible or dangerous [APC]. Both<br />
rights protect the right to join or leave a group of choice. Thus<br />
any collective, gathered for peaceful purposes, is protected by these<br />
rights.<br />
<br />
In draft-irtf-hrpc-research the relationship between human rights and<br />
Internet protocols has been shown, and guidelines for considerations<br />
of human rights impact in protocol design have been provided.<br />
<br />
Further research is needed to understand the exact shape, extend and<br />
form of Internet protocols on human rights. This document aims to<br />
break down the relationship between Internet protocols and the right<br />
to freedom of assembly and association.<br />
<br />
The right to privacy and the right to freedom of expression are the<br />
most discussed human rights when it comes to the Internet. Still we<br />
must recognize that communities, collaboration and joint action lie<br />
at the heart of the Internet.<br />
<br />
Even at at linguistical level, the words "networks" and<br />
"associations" are close synonyms. Both interconnected groups and<br />
association of persons depend on "links" and "relationships" [Swire].<br />
<br />
One could even argue that as a whole, the networked internet<br />
constitutes a big collective, and thus an assembly and an<br />
association.<br />
<br />
On the other hand, IETF itself, defined as a 'open global community'<br />
of network designers, operators, vendors, and researchers, is also<br />
protected by freedom of assembly and association [RFC3233].<br />
<br />
Discussion, comments and consensus around RFCs are possible because<br />
of the collective expression that freedom of association and assembly<br />
allow. The very word "protocol" found its way into the language of<br />
computer networking based on the need for collective agreement among<br />
network users [HafnerandLyon].<br />
<br />
Throughtout the world -from the Arab Spring to Latin American student<br />
movements- the Internet has also played a crucial role by providing a<br />
means for the fast dissemination of information that was otherwise<br />
mediated by broadcast media, or even forbidden by the government<br />
[Pensado]. According to Hussain and Howard the Internet helped to<br />
'build solidarity networks and identification of collective<br />
identities and goals', facilitate protest, 'extend the range of local<br />
coverage to international broadcast networks' and as platform for<br />
contestation for the future of 'the future of civil society and<br />
information infrastructure' [HussainHoward].<br />
<br />
However, some of these examples go beyond the use of Internet<br />
protocols and flow over into the applications layer or association in<br />
the offline world, whereas we'll focus on the Internet protocols and<br />
architecture.<br />
<br />
This can be contrasted with the example of association on the<br />
infrastructure level (albeit one can contest wether this is<br />
'peaceful') of Distributed Denial of Service Attacks (DDoS) in which<br />
the infrastructure of the Internet is used to express discontent with<br />
a specific cause [Abibil] [GreenMovement]. Unfortunately more of<br />
than not DDoS are used to stifle freedom of expression, complicate<br />
the ability of independent media and human rights organizations to<br />
exercise their right to (online) freedom of association, while<br />
facilitating the ability of governments to censor dissent. This is<br />
one of the reasons protocols should seek to mitigate DDoS attacks<br />
[BCP72].<br />
<br />
This document will further seek to map how the internet architecture<br />
impacts freedom of association and assembly.<br />
<br />
==<br/> 2. Vocabulary used ==<br />
<br />
Anonymity The condition of an identity being unknown or concealed.<br />
<br />
[RFC4949]<br />
Censorship resistance Methods and measures to mitigate Internet<br />
censorship.<br />
<br />
Connectivity The extent to which a device or network is able to<br />
reach other devices or networks to exchange data. The Internet is<br />
the tool for providing global connectivity [RFC1958]. Different<br />
types of connectivity are further specified in [RFC4084]. The<br />
combination of the end-to-end principle, interoperability,<br />
distributed architecture, resilience, reliability and robustness<br />
are the enabling factors that result in connectivity to and on the<br />
Internet.<br />
<br />
Decentralization Implementation or deployment of standards,<br />
protocols or systems without one single point of control.<br />
<br />
Pseudonymity The ability to disguise one's identity online with a<br />
different name than the "real" one, allowing for diverse degrees<br />
of disguised identity and privacy. It is strengthened when less<br />
personal data can be linked to the pseudonym; when the same<br />
pseudonym is used less often and across fewer contexts; and when<br />
independently chosen pseudonyms are more frequently used for new<br />
actions (making them, from an observer's or attacker's<br />
perspective, unlinkable)." [RFC6973]<br />
<br />
==<br/> 3. Research questions ==<br />
<br />
How does the internet architecture enables and/or inhibits freedom of<br />
association and assembly.<br />
<br />
==<br/> 4. Cases and examples ==<br />
<br />
=== 4.1. Communicating ===<br />
<br />
==== 4.1.1. Mailinglists ====<br />
<br />
Since the beginning of the Internet mailing lists have been a key<br />
site of assembly and association [RFC0155] [RFC1211]. In fact,<br />
mailing lists were one of the Internet's first functionalities<br />
[HafnerandLyon].<br />
<br />
In 1971, four years after the invention of email, the first mailing<br />
list was created to discuss the idea of using Arpanet for discussion.<br />
<br />
By this time, what had initially propelled the Arpanet project<br />
forward as a resource sharing platform was gradually replaced by the<br />
idea of a network as a means of bringing people together [Abbate].<br />
<br />
More than 45 years after, mailing lists are pervasive and help<br />
communities to engage, have discussion, share information, ask<br />
questions, and build ties. Even as social media and discussion<br />
forums grew, mailing lists continue to be widely used<br />
[AckermannKargerZhang]. They are a crucial tool to organise groups<br />
and individuals around themes and causes [APC].<br />
<br />
==== 4.1.2. Multi party video conferencing and risks ====<br />
<br />
'Beginning in early 2008, Iranian security entities have engaged in<br />
operations to identify and arrest administrators of "illicit"<br />
websites and social media groups. In recent years, the detention and<br />
interrogation of members of online communities has been publicized by<br />
state media for propaganda purposes. However, the heavy-handedness<br />
of the government has also inadvertently created a situation where<br />
Iranian users are better positioned than others to avoid some<br />
surveillance activities - increasing the burden of finding<br />
pseudonymous users.' [AndersonGuarnieri].<br />
<br />
'The WebRTC protocol was designed to enable responsive real-time<br />
communications over the Internet, and is instrumental in allowing<br />
streaming video and conferencing applications to run in the browser.<br />
<br />
In order to easily facilitate direct connections between computers<br />
(bypassing the need for a central server to act as a gatekeeper),<br />
WebRTC provides functionality to automatically collect the local and<br />
public IP addresses of Internet users (ICE or STUN). These functions<br />
do not require consent from the user, and can be instantiated by<br />
sites that a user visits without their awareness. The potential<br />
privacy implications of this aspect of WebRTC are well documented,<br />
and certain browsers have provided options to limit its behavior.'<br />
[AndersonGuarnieri].<br />
<br />
'The disclosure of network addresses presents a specific risk to<br />
individuals that use privacy tools to conceal their real IP address<br />
to sites that they visit. Typically, when a user browses the<br />
Internet over a VPN, the only address that should be recorded by<br />
sites they visit would be that of the VPN provider itself. Using the<br />
WebRTC STUN function allows a site to additionally enumerate the<br />
addresses that are associated with the computer that the visitor is<br />
using - rather than those of intermediaries. This means that if a<br />
user is browsing the Internet on an ADSL connection over a VPN, a<br />
malicious site they visit could potentially surreptitious record the<br />
home address of the user.' [AndersonGuarnieri].<br />
<br />
==== 4.1.3. Reaching out ====<br />
<br />
In the 1990s as the internet became more and more commercial, spam<br />
came to be defined as irrelevant or unsolicited messages that were<br />
porsted many times to multiple news groups or mailing lists [Marcus].<br />
<br />
Here the question of consent is crucial. In the 2000s a large part<br />
of the discussion revolved around the fact that certain corporations<br />
-protected by the right to freedom of association- considered spam to<br />
be a form of "comercial speech", thus encompassed by free expression<br />
rights [Marcus]. Nonetheless, if we consider that the rights to<br />
assembly and association also mean that "no one may be compelled to<br />
belong to an association" [UDHR], spam infringes both rights if an<br />
op-out mechanism is not provided and people are obliged to receive<br />
unwanted information, or be reached by people they do not know.<br />
<br />
<br />
This leaves us with an interesting case: spam is currently handled<br />
mostly by mailproviders on behalf of the user, next to that countries<br />
are increasingly adopting opt-in regimes for mailinglists and<br />
commercial e-mail, with a possibility of serious fines in case of<br />
violation.<br />
<br />
This protects the user from being confronted with unwanted messages,<br />
but it also makes it legally and technically very difficult to<br />
communite a message to someone who did not explicitly ask for this.<br />
<br />
In the public offline spaces we regularly get exposed to flyers,<br />
invitations or demonstrations where our opinions get challenged, or<br />
we are invited to consider different viewpoints. There is no<br />
equivalent on the Internet with the technical and legal regime that<br />
currently operates in it. In other words, it is nearly impossible<br />
impossibility to provide information, in a proportionate manner, that<br />
someone is not explicility expecting or asking for. This reinforces<br />
a concept that is regularly discussed on the application level,<br />
called 'filter bubble': "The proponents of personalization offer a<br />
vision of a custom-tailored world, every facet of which fits us<br />
perfectly. It's a cozy place, populated by our favorite people and<br />
things and ideas." [Pariser]. "The filter bubble's costs are both<br />
personal and cultural. There are direct consequences for those of us<br />
who use personalized filters. And then there are societal<br />
consequences, which emerge when masses of people begin to live a<br />
filter bubbled-life (...). Left to their own devices,<br />
personalization filters serve up a kind of invisible autopropaganda,<br />
indoctrinating us with our own ideas, amplifying our desire for<br />
things that are familiar and leaving us oblivious to the dangers<br />
lurking in the dark territory of the uknown." [Pariser]. It seem<br />
that the 'filter bubble'-effect can also be observed at the<br />
infrastructure level, which actually strenghtens the impact and thus<br />
hampers the effect of collective expression.<br />
<br />
There have been creative alternative for this problem, such as when a<br />
message was distributed to the server logs of millons of servers<br />
through the 'masscan'-tool [Cox].<br />
<br />
=== 4.2. Working together (peer production) ===<br />
<br />
At the organizational level, peer production is one of the most<br />
relevant innovations from Internet mediated social practices.<br />
<br />
According to Benkler, it implies 'open collaborative innovation and<br />
creation, performed by diverse, decentralized groups organized<br />
principally by neither price signals nor organizational hierarchy,<br />
harnessing heterogeneous motivations, and governed and managed based<br />
on principles other than the residual authority of ownership<br />
implemented through contract.' [Benkler].<br />
<br />
<br />
==== 4.2.1. Version control ====<br />
<br />
Ever since developers needed to collaboratively write, maintain and<br />
discuss large code basis for the Internet there have been different<br />
approaches of doing so. One approach is discussing code through<br />
mailing lists, but this has proven to be hard in case of maintaining<br />
the most recent versions. There are many different versions and<br />
characteristics of version control systems.<br />
<br />
Centralization - differences (and gradients) between free (as in<br />
beer) and free (as in freedom). Git vs Github.<br />
<br />
=== 4.3. Grouping together (identities) ===<br />
<br />
Collective identities are also protected by freedom of association<br />
and assembly rights. Acording to Melucci these are 'shared<br />
definitions produced by several interacting individuals who are<br />
concerned with the orientation of their action as well as the field<br />
of opportunities and constraints in which their action takes place.'<br />
[Melucci]<br />
<br />
==== 4.3.1. DNS ====<br />
<br />
Advantages and disadvantages<br />
<br />
==== 4.3.2. ISPs ====<br />
Access, diversity and forced association<br />
<br />
==<br/> 5. Acknowledgements ==<br />
<br />
==<br/> 6. Security Considerations ==<br />
As this draft concerns a research document, there are no security<br />
considerations.<br />
<br />
==<br/> 7. IANA Considerations ==<br />
This document has no actions for IANA.<br />
<br />
==<br/> 8. Research Group Information ==<br />
The discussion list for the IRTF Human Rights Protocol Considerations<br />
Research Group is located at the e-mail address hrpc@ietf.org [1].<br />
<br />
Information on the group and information on how to subscribe to the<br />
list is at https://www.irtf.org/mailman/listinfo/hrpc<br />
Archives of the list can be found at: https://www.irtf.org/mail-<br />
archive/web/hrpc/current/index.html<br />
<br />
==<br/> 9. References ==<br />
<br />
=== 9.1. Informative References ===<br />
[Abbate] Janet Abbate, ., "Inventing the Internet", Cambridge: MIT<br />
Press (2013): 11. , 2013, <https://mitpress.mit.edu/books/<br />
inventing-internet>.<br />
<br />
[Abibil] Danchev, D., "Dissecting 'Operation Ababil' - an OSINT<br />
Analysis", 2012, <http://ddanchev.blogspot.be/2012/09/<br />
dissecting-operation-ababil-osint.html>.<br />
<br />
[AckermannKargerZhang]<br />
Ackerman, M., Karger, D., and A. Zhang, "Mailing Lists:<br />
<br />
Why Are They Still Here, What's Wrong With Them, and How<br />
Can We Fix Them?", Mit. edu (2017): 1. , 2017,<br />
<https://people.csail.mit.edu/axz/papers/<br />
mailinglists.pdf>.<br />
<br />
[AndersonGuarnieri]<br />
Anderson, C. and C. Guarnieri, "Fictitious Profiles and<br />
webRTC's Privacy Leaks Used to Identify Iranian<br />
Activists", 2016,<br />
<https://iranthreats.github.io/resources/webrtc-<br />
deanonymization/>.<br />
<br />
[APC] Association for Progressive Communications and . Gayathry<br />
Venkiteswaran, "Freedom of assembly and association online<br />
in India, Malaysia and Pakistan. Trends, challenges and<br />
recommendations.", 2016,<br />
<https://www.apc.org/es/system/files/<br />
FOAA_online_IndiaMalaysiaPakistan.pdf>.<br />
<br />
[ARTICLE19]<br />
ARTICLE 19, "The Right to Protest Principles: Background<br />
Paper", 2016,<br />
<https://www.article19.org/data/files/medialibrary/38581/<br />
Protest-Background-paper-Final-April-2016.pdf page 7>.<br />
<br />
[BCP72] IETF, "Guidelines for Writing RFC Text on Security<br />
Considerations", 2003, <https://datatracker.ietf.org/doc/<br />
bcp72/>.<br />
<br />
[Benkler] Benkler, Y., "Peer Production and Cooperation", 2009,<br />
<http://www.benkler.org/<br />
Peer%20production%20and%20cooperation%2009.pdf>.<br />
<br />
[Cox] Cox, J., "Chaos Communication Congress Hackers Invaded<br />
Millions of Servers With a Poem", 2016,<br />
<https://motherboard.vice.com/en_us/article/chaos-<br />
communication-congress-hackers-invaded-millions-of-<br />
servers-with-a-poem>.<br />
<br />
[GreenMovement]<br />
Villeneuve, N., "Iran DDoS", 2009,<br />
<https://www.nartv.org/2009/06/16/iran-ddos/>.<br />
<br />
[HafnerandLyon]<br />
Hafnerand, K. and M. Lyon, "Where Wizards Stay Up Late.<br />
<br />
The Origins of the Internet", First Touchstone Edition<br />
(1998): 93. , 1998, <https://doi.org/10.1111/misr.12020>.<br />
<br />
[HussainHoward]<br />
Hussain, M. and P. Howard, "What Best Explains Successful<br />
Protest Cascades? ICTs and the Fuzzy Causes of the Arab<br />
Spring", Int Stud Rev (2013) 15 (1): 48-66. , 2013,<br />
<https://doi.org/10.1111/misr.12020>.<br />
<br />
[ICCPR] United Nations General Assembly, "International Covenant<br />
on Civil and Political Rights", 1976,<br />
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/<br />
CCPR.aspx>.<br />
<br />
[Marcus] Marcus, J., "Commercial Speech on the Internet: Spam and<br />
the first amendment", 1998, <http://www.cardozoaelj.com/<br />
wp-content/uploads/2013/02/Marcus.pdf>.<br />
<br />
[Melucci] Melucci, A., "The Process of Collective Identity", Temple<br />
University Press, Philadelphia , 1995.<br />
<br />
[Pariser] Pariser, E., "The Filter Bubble: How the New Personalized<br />
Web Is Changing What We Read and How We Think", Peguin<br />
Books, London. , 2012.<br />
<br />
[Pensado] Jaime Pensado, ., "Student Activism. Utopian Dreams.",<br />
ReVista. Harvard Review of Latin America (2012). , 2012,<br />
<http://revista.drclas.harvard.edu/book/student-activism>.<br />
<br />
[RFC0155] North, J., "ARPA Network mailing lists", RFC 155,<br />
DOI 10.17487/RFC0155, May 1971,<br />
<http://www.rfc-editor.org/info/rfc155>.<br />
<br />
[RFC1211] Westine, A. and J. Postel, "Problems with the maintenance<br />
of large mailing lists", RFC 1211, DOI 10.17487/RFC1211,<br />
March 1991, <http://www.rfc-editor.org/info/rfc1211>.<br />
<br />
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the<br />
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,<br />
<http://www.rfc-editor.org/info/rfc1958>.<br />
<br />
[RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,<br />
RFC 3233, DOI 10.17487/RFC3233, February 2002,<br />
<http://www.rfc-editor.org/info/rfc3233>.<br />
<br />
[RFC4084] Klensin, J., "Terminology for Describing Internet<br />
Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084,<br />
May 2005, <http://www.rfc-editor.org/info/rfc4084>.<br />
<br />
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",<br />
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,<br />
<http://www.rfc-editor.org/info/rfc4949>.<br />
<br />
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,<br />
Morris, J., Hansen, M., and R. Smith, "Privacy<br />
Considerations for Internet Protocols", RFC 6973,<br />
DOI 10.17487/RFC6973, July 2013,<br />
<http://www.rfc-editor.org/info/rfc6973>.<br />
<br />
[Swire] Peter Swire, ., "Social Networks, Privacy, and Freedom of<br />
Association: Data Empowerment vs. Data Protection", North<br />
Carolina Law Review (2012) 90 (1): 104. , 2012,<br />
<https://ssrn.com/abstract=1989516 or<br />
http://dx.doi.org/10.2139/ssrn.1989516>.<br />
<br />
[Tocqueville]<br />
de Tocqueville, A., "Democracy in America", n.d., <http://<br />
classiques.uqac.ca/classiques/De_tocqueville_alexis/<br />
democracy_in_america_historical_critical_ed/<br />
democracy_in_america_vol_2.pdf p. 304>.<br />
<br />
[UDHR] United Nations General Assembly, "The Universal<br />
Declaration of Human Rights", 1948,<br />
<http://www.un.org/en/documents/udhr/>.<br />
<br />
[UNGA] Hina Jilani, ., "Human rights defenders", A/59/401 , 2004,<br />
<http://www.un.org/en/ga/search/<br />
view_doc.asp?symbol=A/59/401 para. 46>.<br />
<br />
[UNHRC] Maina Kiai, ., "Report of the Special Rapporteur on the<br />
rights to freedom of peaceful assembly and of<br />
association", A/HRC/20/27 , 2012,<br />
<http://freeassembly.net/wp-content/uploads/2013/10/<br />
A-HRC-20-27_en-annual-report-May-2012.pdf>.<br />
<br />
=== 9.2. URIs ===<br />
<br />
:[1] mailto:hrpc@ietf.org<br />
:Niels ten Oever<br />
:ARTICLE 19<br />
:EMail: niels@article19.org<br />
<br />
:Gisela Perez de Acha<br />
:Derechos Digitales<br />
:EMail: gisela@derechosdigitales.org<br />
<br />
<br/></div>Sysophttp://iuwg.net/index.php/Commented_RFC_6973Commented RFC 69732016-02-11T20:44:09Z<p>Sysop: Created page with "<br/> This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Inte..."</p>
<hr />
<div><br/><br />
This document offers guidance for developing privacy considerations<br />
for inclusion in protocol specifications. It aims to make designers,<br />
implementers, and users of Internet protocols aware of privacy-<br />
related design choices. It suggests that whether any individual RFC<br />
warrants a specific privacy considerations section will depend on the<br />
document's content.<br />
<br />
<br />
This document is not an Internet Standards Track specification; it is<br />
published for informational purposes.<br />
<br />
This document is a product of the Internet Architecture Board (IAB)<br />
and represents information that the IAB has deemed valuable to<br />
provide for permanent record. It represents the consensus of the<br />
Internet Architecture Board (IAB). Documents approved for<br />
publication by the IAB are not a candidate for any level of Internet<br />
Standard; see Section 2 of RFC 5741.<br />
<br />
<br />
__TOC__<br />
<br />
==<br/> 1. Introduction ==<br />
[RFC3552] provides detailed guidance to protocol designers about both<br />
how to consider security as part of protocol design and how to inform<br />
readers of protocol specifications about security issues. This<br />
document intends to provide a similar set of guidelines for<br />
considering privacy in protocol design.<br />
<br />
Privacy is a complicated concept with a rich history that spans many<br />
disciplines. With regard to data, often it is a concept applied to<br />
"personal data", commonly defined as information relating to an<br />
identified or identifiable individual. Many sets of privacy<br />
principles and privacy design frameworks have been developed in<br />
different forums over the years. These include the Fair Information<br />
Practices [FIPs], a baseline set of privacy protections pertaining to<br />
the collection and use of personal data (often based on the<br />
principles established in [OECD], for example), and the Privacy by<br />
Design concept, which provides high-level privacy guidance for<br />
systems design (see [PbD] for one example). The guidance provided in<br />
this document is inspired by this prior work, but it aims to be more<br />
concrete, pointing protocol designers to specific engineering choices<br />
that can impact the privacy of the individuals that make use of<br />
Internet protocols.<br />
<br />
Different people have radically different conceptions of what privacy<br />
means, both in general and as it relates to them personally [Westin].<br />
<br />
Furthermore, privacy as a legal concept is understood differently in<br />
different jurisdictions. The guidance provided in this document is<br />
generic and can be used to inform the design of any protocol to be<br />
used anywhere in the world, without reference to specific legal<br />
frameworks.<br />
<br />
Whether any individual document warrants a specific privacy<br />
considerations section will depend on the document's content.<br />
<br />
Documents whose entire focus is privacy may not merit a separate<br />
section (for example, "Private Extensions to the Session Initiation<br />
Protocol (SIP) for Asserted Identity within Trusted Networks"<br />
[RFC3325]). For certain specifications, privacy considerations are a<br />
subset of security considerations and can be discussed explicitly in<br />
the security considerations section. Some documents will not require<br />
discussion of privacy considerations (for example, "Definition of the<br />
Opus Audio Codec" [RFC6716]). The guidance provided here can and<br />
should be used to assess the privacy considerations of protocol,<br />
architectural, and operational specifications and to decide whether<br />
those considerations are to be documented in a stand-alone section,<br />
within the security considerations section, or throughout the<br />
document. The guidance provided here is meant to help the thought<br />
process of privacy analysis; it does not provide specific directions<br />
for how to write a privacy considerations section.<br />
<br />
This document is organized as follows. Section 2 describes the<br />
extent to which the guidance offered here is applicable within the<br />
IETF and within the larger Internet community. Section 3 explains<br />
the terminology used in this document. Section 4 reviews typical<br />
communications architectures to understand at which points there may<br />
be privacy threats. Section 5 discusses threats to privacy as they<br />
apply to Internet protocols. Section 6 outlines mitigations of those<br />
threats. Section 7 provides the guidelines for analyzing and<br />
documenting privacy considerations within IETF specifications.<br />
<br />
Section 8 examines the privacy characteristics of an IETF protocol to<br />
demonstrate the use of the guidance framework.<br />
<br />
==<br/> 2. Scope of Privacy Implications of Internet Protocols ==<br />
Internet protocols are often built flexibly, making them useful in a<br />
variety of architectures, contexts, and deployment scenarios without<br />
requiring significant interdependency between disparately designed<br />
components. Although protocol designers often have a particular<br />
target architecture or set of architectures in mind at design time,<br />
it is not uncommon for architectural frameworks to develop later,<br />
after implementations exist and have been deployed in combination<br />
with other protocols or components to form complete systems.<br />
<br />
As a consequence, the extent to which protocol designers can foresee<br />
all of the privacy implications of a particular protocol at design<br />
time is limited. An individual protocol may be relatively benign on<br />
its own, and it may make use of privacy and security features at<br />
lower layers of the protocol stack (Internet Protocol Security,<br />
Transport Layer Security, and so forth) to mitigate the risk of<br />
attack. But when deployed within a larger system or used in a way<br />
not envisioned at design time, its use may create new privacy risks.<br />
<br />
Protocols are often implemented and deployed long after design time<br />
by different people than those who did the protocol design. The<br />
guidelines in Section 7 ask protocol designers to consider how their<br />
protocols are expected to interact with systems and information that<br />
exist outside the protocol bounds, but not to imagine every possible<br />
deployment scenario.<br />
<br />
Furthermore, in many cases the privacy properties of a system are<br />
dependent upon the complete system design where various protocols are<br />
combined together to form a product solution; the implementation,<br />
which includes the user interface design; and operational deployment<br />
practices, including default privacy settings and security processes<br />
of the company doing the deployment. These details are specific to<br />
particular instantiations and generally outside the scope of the work<br />
conducted in the IETF. The guidance provided here may be useful in<br />
making choices about these details, but its primary aim is to assist<br />
with the design, implementation, and operation of protocols.<br />
<br />
Transparency of data collection and use -- often effectuated through<br />
user interface design -- is normally relied on (whether rightly or<br />
wrongly) as a key factor in determining the privacy impact of a<br />
system. Although most IETF activities do not involve standardizing<br />
user interfaces or user-facing communications, in some cases,<br />
understanding expected user interactions can be important for<br />
protocol design. Unexpected user behavior may have an adverse impact<br />
on security and/or privacy.<br />
<br />
In sum, privacy issues, even those related to protocol development,<br />
go beyond the technical guidance discussed herein. As an example,<br />
consider HTTP [RFC2616], which was designed to allow the exchange of<br />
arbitrary data. A complete analysis of the privacy considerations<br />
for uses of HTTP might include what type of data is exchanged, how<br />
this data is stored, and how it is processed. Hence the analysis for<br />
an individual's static personal web page would be different than the<br />
use of HTTP for exchanging health records. A protocol designer<br />
working on HTTP extensions (such as Web Distributed Authoring and<br />
Versioning (WebDAV) [RFC4918]) is not expected to describe the<br />
privacy risks derived from all possible usage scenarios, but rather<br />
the privacy properties specific to the extensions and any particular<br />
uses of the extensions that are expected and foreseen at design time.<br />
<br />
==<br/> 3. Terminology ==<br />
This section defines basic terms used in this document, with<br />
references to pre-existing definitions as appropriate. As in<br />
[RFC4949], each entry is preceded by a dollar sign ($) and a space<br />
for automated searching. Note that this document does not try to<br />
attempt to define the term 'privacy' with a brief definition.<br />
<br />
Instead, privacy is the sum of what is contained in this document.<br />
<br />
We therefore follow the approach taken by [RFC3552]. Examples of<br />
several different brief definitions are provided in [RFC4949].<br />
<br />
<br />
===<br/> 3.1. Entities ===<br />
Several of these terms are further elaborated in Section 4.<br />
<br />
* Attacker: An entity that works against one or more privacy protection goals. Unlike observers, attackers' behavior is unauthorized.<br />
<br />
* Eavesdropper: A type of attacker that passively observes an initiator's communications without the initiator's knowledge or authorization. See [RFC4949].<br />
<br />
* Enabler: A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path.<br />
<br />
* Individual: A human being.<br />
<br />
* Initiator: A protocol entity that initiates communications with a recipient.<br />
<br />
* Intermediary: A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate. Unlike an eavesdropper, an intermediary is an entity that is part of the communication architecture and therefore at least tacitly authorized. For example, a SIP [RFC3261] proxy is an intermediary in the SIP architecture.<br />
<br />
* Observer: An entity that is able to observe and collect information from communications, potentially posing privacy threats, depending on the context. As defined in this document, initiators, recipients, intermediaries, and enablers can all be observers. Observers are distinguished from eavesdroppers by being at least tacitly authorized.<br />
<br />
* Recipient: A protocol entity that receives communications from an initiator.<br />
<br />
<br />
===<br/> 3.2. Data and Analysis ===<br />
* Attack: An intentional act by which an entity attempts to violate an individual's privacy. See [RFC4949].<br />
<br />
* Correlation: The combination of various pieces of information that relate to an individual or that obtain that characteristic when combined.<br />
<br />
* Fingerprint: A set of information elements that identifies a device or application instance.<br />
<br />
* Fingerprinting: The process of an observer or attacker uniquely identifying (with a sufficiently high probability) a device or application instance based on multiple information elements communicated to the observer or attacker. See [EFF].<br />
<br />
* Item of Interest (IOI): Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, identities, communications content, and the fact that a communication interaction has taken place.<br />
<br />
* Personal Data: Any information relating to an individual who can be identified, directly or indirectly.<br />
<br />
* (Protocol) Interaction: A unit of communication within a particular protocol. A single interaction may be comprised of a single message between an initiator and recipient or multiple messages, depending on the protocol.<br />
<br />
* Traffic Analysis: The inference of information from observation of traffic flows (presence, absence, amount, direction, timing, packet size, packet composition, and/or frequency), even if flows are encrypted. See [RFC4949].<br />
<br />
* Undetectability: The inability of an observer or attacker to sufficiently distinguish whether an item of interest exists or not.<br />
<br />
* Unlinkability: Within a particular set of information, the inability of an observer or attacker to distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker).<br />
<br />
<br />
===<br/> 3.3. Identifiability ===<br />
* Anonymity: The state of being anonymous.<br />
<br />
* Anonymity Set: A set of individuals that have the same attributes, making them indistinguishable from each other from the perspective of a particular attacker or observer.<br />
<br />
* Anonymous: A state of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set).<br />
<br />
* Attribute: A property of an individual.<br />
<br />
* Identifiability: The extent to which an individual is identifiable.<br />
<br />
* Identifiable: A property in which an individual's identity is capable of being known to an observer or attacker.<br />
<br />
* Identification: The linking of information to a particular individual to infer an individual's identity or to allow the inference of an individual's identity in some context.<br />
<br />
* Identified: A state in which an individual's identity is known.<br />
<br />
* Identifier: A data object uniquely referring to a specific identity of a protocol entity or individual in some context. See [RFC4949]. Identifiers can be based upon natural names -- official names, personal names, and/or nicknames -- or can be artificial (for example, x9z32vb). However, identifiers are by definition unique within their context of use, while natural names are often not unique.<br />
<br />
* Identity: Any subset of an individual's attributes, including names, that identifies the individual within a given context.<br />
<br />
Individuals usually have multiple identities for use in different contexts.<br />
<br />
* Identity Confidentiality: A property of an individual where only the recipient can sufficiently identify the individual within a set of other individuals. This can be a desirable property of authentication protocols.<br />
<br />
* Identity Provider: An entity (usually an organization) that is responsible for establishing, maintaining, securing, and vouching for the identities associated with individuals.<br />
<br />
<br />
* Official Name: A personal name for an individual that is registered in some official context (for example, the name on an individual's birth certificate). Official names are often not unique.<br />
<br />
* Personal Name: A natural name for an individual. Personal names are often not unique and often comprise given names in combination with a family name. An individual may have multiple personal names at any time and over a lifetime, including official names.<br />
<br />
From a technological perspective, it cannot always be determined whether a given reference to an individual is, or is based upon, the individual's personal name(s) (see Pseudonym).<br />
<br />
* Pseudonym: A name assumed by an individual in some context, unrelated to the individual's personal names known by others in that context, with an intent of not revealing the individual's identities associated with his or her other names. Pseudonyms are often not unique.<br />
<br />
* Pseudonymity: The state of being pseudonymous.<br />
<br />
* Pseudonymous: A property of an individual in which the individual is identified by a pseudonym.<br />
<br />
* Real Name: See Personal Name and Official Name.<br />
<br />
* Relying Party: An entity that relies on assertions of individuals' identities from identity providers in order to provide services to individuals. In effect, the relying party delegates aspects of identity management to the identity provider(s). Such delegation requires protocol exchanges, trust, and a common understanding of semantics of information exchanged between the relying party and the identity provider.<br />
<br />
==<br/> 4. Communications Model ==<br />
To understand attacks in the privacy-harm sense, it is helpful to<br />
consider the overall communication architecture and different actors'<br />
roles within it. Consider a protocol entity, the "initiator", that<br />
initiates communication with some recipient. Privacy analysis is<br />
most relevant for protocols with use cases in which the initiator<br />
acts on behalf of an individual (or different individuals at<br />
different times). It is this individual whose privacy is potentially<br />
threatened (although in some instances an initiator communicates<br />
information about another individual, in which case both of their<br />
privacy interests will be implicated).<br />
<br />
<br />
Communications may be direct between the initiator and the recipient,<br />
or they may involve an application-layer intermediary (such as a<br />
proxy, cache, or relay) that is necessary for the two parties to<br />
communicate. In some cases, this intermediary stays in the<br />
communication path for the entire duration of the communication;<br />
sometimes it is only used for communication establishment, for either<br />
inbound or outbound communication. In some cases, there may be a<br />
series of intermediaries that are traversed. At lower layers,<br />
additional entities involved in packet forwarding may interfere with<br />
privacy protection goals as well.<br />
<br />
Some communications tasks require multiple protocol interactions with<br />
different entities. For example, a request to an HTTP server may be<br />
preceded by an interaction between the initiator and an<br />
Authentication, Authorization, and Accounting (AAA) server for<br />
network access and to a Domain Name System (DNS) server for name<br />
resolution. In this case, the HTTP server is the recipient and the<br />
other entities are enablers of the initiator-to-recipient<br />
communication. Similarly, a single communication with the recipient<br />
might generate further protocol interactions between either the<br />
initiator or the recipient and other entities, and the roles of the<br />
entities might change with each interaction. For example, an HTTP<br />
request might trigger interactions with an authentication server or<br />
with other resource servers wherein the recipient becomes an<br />
initiator in those later interactions.<br />
<br />
Thus, when conducting privacy analysis of an architecture that<br />
involves multiple communications phases, the entities involved may<br />
take on different -- or opposing -- roles from a privacy<br />
considerations perspective in each phase. Understanding the privacy<br />
implications of the architecture as a whole may require a separate<br />
analysis of each phase.<br />
<br />
Protocol design is often predicated on the notion that recipients,<br />
intermediaries, and enablers are assumed to be authorized to receive<br />
and handle data from initiators. As [RFC3552] explains, "we assume<br />
that the end systems engaging in a protocol exchange have not<br />
themselves been compromised". However, privacy analysis requires<br />
questioning this assumption, since systems are often compromised for<br />
the purpose of obtaining personal data.<br />
<br />
Although recipients, intermediaries, and enablers may not generally<br />
be considered as attackers, they may all pose privacy threats<br />
(depending on the context) because they are able to observe, collect,<br />
process, and transfer privacy-relevant data. These entities are<br />
collectively described below as "observers" to distinguish them from<br />
traditional attackers. From a privacy perspective, one important<br />
type of attacker is an eavesdropper: an entity that passively<br />
observes the initiator's communications without the initiator's<br />
knowledge or authorization.<br />
<br />
The threat descriptions in the next section explain how observers and<br />
attackers might act to harm individuals' privacy. Different kinds of<br />
attacks may be feasible at different points in the communications<br />
path. For example, an observer could mount surveillance or<br />
identification attacks between the initiator and intermediary, or<br />
instead could surveil an enabler (e.g., by observing DNS queries from<br />
the initiator).<br />
<br />
==<br/> 5. Privacy Threats ==<br />
Privacy harms come in a number of forms, including harms to financial<br />
standing, reputation, solitude, autonomy, and safety. A victim of<br />
identity theft or blackmail, for example, may suffer a financial loss<br />
as a result. Reputational harm can occur when disclosure of<br />
information about an individual, whether true or false, subjects that<br />
individual to stigma, embarrassment, or loss of personal dignity.<br />
<br />
Intrusion or interruption of an individual's life or activities can<br />
harm the individual's ability to be left alone. When individuals or<br />
their activities are monitored, exposed, or at risk of exposure,<br />
those individuals may be stifled from expressing themselves,<br />
associating with others, and generally conducting their lives freely.<br />
<br />
They may also feel a general sense of unease, in that it is "creepy"<br />
to be monitored or to have data collected about them. In cases where<br />
such monitoring is for the purpose of stalking or violence (for<br />
example, monitoring communications to or from a domestic abuse<br />
shelter), it can put individuals in physical danger.<br />
<br />
This section lists common privacy threats (drawing liberally from<br />
[Solove], as well as [CoE]), showing how each of them may cause<br />
individuals to incur privacy harms and providing examples of how<br />
these threats can exist on the Internet. This threat modeling is<br />
inspired by security threat analysis. Although it is not a perfect<br />
fit for assessing privacy risks in Internet protocols and systems, no<br />
better methodology has been developed to date.<br />
<br />
Some privacy threats are already considered in Internet protocols as<br />
a matter of routine security analysis. Others are more pure privacy<br />
threats that existing security considerations do not usually address.<br />
<br />
The threats described here are divided into those that may also be<br />
considered security threats and those that are primarily privacy<br />
threats.<br />
<br />
<br />
Note that an individual's awareness of and consent to the practices<br />
described below may change an individual's perception of and concern<br />
for the extent to which they threaten privacy. If an individual<br />
authorizes surveillance of his own activities, for example, the<br />
individual may be able to take actions to mitigate the harms<br />
associated with it or may consider the risk of harm to be tolerable.<br />
<br />
===<br/> 5.1. Combined Security-Privacy Threats ===<br />
====<br/> 5.1.1. Surveillance ====<br />
Surveillance is the observation or monitoring of an individual's<br />
communications or activities. The effects of surveillance on the<br />
individual can range from anxiety and discomfort to behavioral<br />
changes such as inhibition and self-censorship, and even to the<br />
perpetration of violence against the individual. The individual need<br />
not be aware of the surveillance for it to impact his or her privacy<br />
-- the possibility of surveillance may be enough to harm individual<br />
autonomy.<br />
<br />
Surveillance can impact privacy, even if the individuals being<br />
surveilled are not identifiable or if their communications are<br />
encrypted. For example, an observer or eavesdropper that conducts<br />
traffic analysis may be able to determine what type of traffic is<br />
present (real-time communications or bulk file transfers, for<br />
example) or which protocols are in use, even if the observed<br />
communications are encrypted or the communicants are unidentifiable.<br />
<br />
This kind of surveillance can adversely impact the individuals<br />
involved by causing them to become targets for further investigation<br />
or enforcement activities. It may also enable attacks that are<br />
specific to the protocol, such as redirection to a specialized<br />
interception point or protocol-specific denials of service.<br />
<br />
Protocols that use predictable packet sizes or timing or include<br />
fixed tokens at predictable offsets within a packet can facilitate<br />
this kind of surveillance.<br />
<br />
Surveillance can be conducted by observers or eavesdroppers at any<br />
point along the communications path. Confidentiality protections (as<br />
discussed in Section 3 of [RFC3552]) are necessary to prevent<br />
surveillance of the content of communications. To prevent traffic<br />
analysis or other surveillance of communications patterns, other<br />
measures may be necessary, such as [Tor].<br />
<br />
<br />
====<br/> 5.1.2. Stored Data Compromise ====<br />
End systems that do not take adequate measures to secure stored data<br />
from unauthorized or inappropriate access expose individuals to<br />
potential financial, reputational, or physical harm.<br />
<br />
Protecting against stored data compromise is typically outside the<br />
scope of IETF protocols. However, a number of common protocol<br />
functions -- key management, access control, or operational logging,<br />
for example -- require the storage of data about initiators of<br />
communications. When requiring or recommending that information<br />
about initiators or their communications be stored or logged by end<br />
systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize<br />
the potential for that information to be compromised and for that<br />
potential to be weighed against the benefits of data storage. Any<br />
recipient, intermediary, or enabler that stores data may be<br />
vulnerable to compromise. (Note that stored data compromise is<br />
distinct from purposeful disclosure, which is discussed in<br />
Section 5.2.4.)<br />
====<br/> 5.1.3. Intrusion ====<br />
Intrusion consists of invasive acts that disturb or interrupt one's<br />
life or activities. Intrusion can thwart individuals' desires to be<br />
left alone, sap their time or attention, or interrupt their<br />
activities. This threat is focused on intrusion into one's life<br />
rather than direct intrusion into one's communications. The latter<br />
is captured in Section 5.1.1.<br />
<br />
Unsolicited messages and denial-of-service attacks are the most<br />
common types of intrusion on the Internet. Intrusion can be<br />
perpetrated by any attacker that is capable of sending unwanted<br />
traffic to the initiator.<br />
<br />
====<br/> 5.1.4. Misattribution ====<br />
Misattribution occurs when data or communications related to one<br />
individual are attributed to another. Misattribution can result in<br />
adverse reputational, financial, or other consequences for<br />
individuals that are misidentified.<br />
<br />
Misattribution in the protocol context comes as a result of using<br />
inadequate or insecure forms of identity or authentication, and is<br />
sometimes related to spoofing. For example, as [RFC6269] notes,<br />
abuse mitigation is often conducted on the basis of the source IP<br />
address, such that connections from individual IP addresses may be<br />
prevented or temporarily blacklisted if abusive activity is<br />
determined to be sourced from those addresses. However, in the case<br />
where a single IP address is shared by multiple individuals, those<br />
penalties may be suffered by all individuals sharing the address,<br />
even if they were not involved in the abuse. This threat can be<br />
mitigated by using identity management mechanisms with proper forms<br />
of authentication (ideally with cryptographic properties) so that<br />
actions can be attributed uniquely to an individual to provide the<br />
basis for accountability without generating false positives.<br />
<br />
===<br/> 5.2. Privacy-Specific Threats ===<br />
====<br/> 5.2.1. Correlation ====<br />
Correlation is the combination of various pieces of information<br />
related to an individual or that obtain that characteristic when<br />
combined. Correlation can defy people's expectations of the limits<br />
of what others know about them. It can increase the power that those<br />
doing the correlating have over individuals as well as correlators'<br />
ability to pass judgment, threatening individual autonomy and<br />
reputation.<br />
<br />
Correlation is closely related to identification. Internet protocols<br />
can facilitate correlation by allowing individuals' activities to be<br />
tracked and combined over time. The use of persistent or<br />
infrequently replaced identifiers at any layer of the stack can<br />
facilitate correlation. For example, an initiator's persistent use<br />
of the same device ID, certificate, or email address across multiple<br />
interactions could allow recipients (and observers) to correlate all<br />
of the initiator's communications over time.<br />
<br />
As an example, consider Transport Layer Security (TLS) session<br />
resumption [RFC5246] or TLS session resumption without server-side<br />
state [RFC5077]. In RFC 5246 [RFC5246], a server provides the client<br />
with a session_id in the ServerHello message and caches the<br />
master_secret for later exchanges. When the client initiates a new<br />
connection with the server, it re-uses the previously obtained<br />
session_id in its ClientHello message. The server agrees to resume<br />
the session by using the same session_id and the previously stored<br />
master_secret for the generation of the TLS Record Layer security<br />
association. RFC 5077 [RFC5077] borrows from the session resumption<br />
design idea, but the server encapsulates all state information into a<br />
ticket instead of caching it. An attacker who is able to observe the<br />
protocol exchanges between the TLS client and the TLS server is able<br />
to link the initial exchange to subsequently resumed TLS sessions<br />
when the session_id and the ticket are exchanged in the clear (which<br />
is the case with data exchanged in the initial handshake messages).<br />
<br />
<br />
In theory, any observer or attacker that receives an initiator's<br />
communications can engage in correlation. The extent of the<br />
potential for correlation will depend on what data the entity<br />
receives from the initiator and has access to otherwise. Often,<br />
intermediaries only require a small amount of information for message<br />
routing and/or security. In theory, protocol mechanisms could ensure<br />
that end-to-end information is not made accessible to these entities,<br />
but in practice the difficulty of deploying end-to-end security<br />
procedures, additional messaging or computational overhead, and other<br />
business or legal requirements often slow or prevent the deployment<br />
of end-to-end security mechanisms, giving intermediaries greater<br />
exposure to initiators' data than is strictly necessary from a<br />
technical point of view.<br />
<br />
====<br/> 5.2.2. Identification ====<br />
Identification is the linking of information to a particular<br />
individual to infer an individual's identity or to allow the<br />
inference of an individual's identity. In some contexts, it is<br />
perfectly legitimate to identify individuals, whereas in others,<br />
identification may potentially stifle individuals' activities or<br />
expression by inhibiting their ability to be anonymous or<br />
pseudonymous. Identification also makes it easier for individuals to<br />
be explicitly controlled by others (e.g., governments) and to be<br />
treated differentially compared to other individuals.<br />
<br />
Many protocols provide functionality to convey the idea that some<br />
means has been provided to validate that entities are who they claim<br />
to be. Often, this is accomplished with cryptographic<br />
authentication. Furthermore, many protocol identifiers, such as<br />
those used in SIP or the Extensible Messaging and Presence Protocol<br />
(XMPP), may allow for the direct identification of individuals.<br />
<br />
Protocol identifiers may also contribute indirectly to identification<br />
via correlation. For example, a web site that does not directly<br />
authenticate users may be able to match its HTTP header logs with<br />
logs from another site that does authenticate users, rendering users<br />
on the first site identifiable.<br />
<br />
As with correlation, any observer or attacker may be able to engage<br />
in identification, depending on the information about the initiator<br />
that is available via the protocol mechanism or other channels.<br />
<br />
====<br/> 5.2.3. Secondary Use ====<br />
Secondary use is the use of collected information about an individual<br />
without the individual's consent for a purpose different from that<br />
for which the information was collected. Secondary use may violate<br />
people's expectations or desires. The potential for secondary use<br />
can generate uncertainty as to how one's information will be used in<br />
the future, potentially discouraging information exchange in the<br />
first place. Secondary use encompasses any use of data, including<br />
disclosure.<br />
<br />
One example of secondary use would be an authentication server that<br />
uses a network access server's Access-Requests to track an<br />
initiator's location. Any observer or attacker could potentially<br />
make unwanted secondary uses of initiators' data. Protecting against<br />
secondary use is typically outside the scope of IETF protocols.<br />
<br />
====<br/> 5.2.4. Disclosure ====<br />
Disclosure is the revelation of information about an individual that<br />
affects the way others judge the individual. Disclosure can violate<br />
individuals' expectations of the confidentiality of the data they<br />
share. The threat of disclosure may deter people from engaging in<br />
certain activities for fear of reputational harm, or simply because<br />
they do not wish to be observed.<br />
<br />
Any observer or attacker that receives data about an initiator may<br />
engage in disclosure. Sometimes disclosure is unintentional because<br />
system designers do not realize that information being exchanged<br />
relates to individuals. The most common way for protocols to limit<br />
disclosure is by providing access control mechanisms (discussed in<br />
Section 5.2.5). A further example is provided by the IETF<br />
geolocation privacy architecture [RFC6280], which supports a way for<br />
users to express a preference that their location information not be<br />
disclosed beyond the intended recipient.<br />
<br />
====<br/> 5.2.5. Exclusion ====<br />
Exclusion is the failure to allow individuals to know about the data<br />
that others have about them and to participate in its handling and<br />
use. Exclusion reduces accountability on the part of entities that<br />
maintain information about people and creates a sense of<br />
vulnerability in relation to individuals' ability to control how<br />
information about them is collected and used.<br />
<br />
The most common way for Internet protocols to be involved in<br />
enforcing exclusion is through access control mechanisms. The<br />
presence architecture developed in the IETF is a good example where<br />
individuals are included in the control of information about them.<br />
<br />
Using a rules expression language (e.g., presence authorization rules<br />
[RFC5025]), presence clients can authorize the specific conditions<br />
under which their presence information may be shared.<br />
<br />
<br />
Exclusion is primarily considered problematic when the recipient<br />
fails to involve the initiator in decisions about data collection,<br />
handling, and use. Eavesdroppers engage in exclusion by their very<br />
nature, since their data collection and handling practices are<br />
covert.<br />
<br />
==<br/> 6. Threat Mitigations ==<br />
Privacy is notoriously difficult to measure and quantify. The extent<br />
to which a particular protocol, system, or architecture "protects" or<br />
"enhances" privacy is dependent on a large number of factors relating<br />
to its design, use, and potential misuse. However, there are certain<br />
widely recognized classes of mitigations against the threats<br />
discussed in Section 5. This section describes three categories of<br />
relevant mitigations: (1) data minimization, (2) user participation,<br />
and (3) security. The privacy mitigations described in this section<br />
can loosely be mapped to existing privacy principles, such as the<br />
Fair Information Practices, but they have been adapted to fit the<br />
target audience of this document.<br />
<br />
===<br/> 6.1. Data Minimization ===<br />
Data minimization refers to collecting, using, disclosing, and<br />
storing the minimal data necessary to perform a task. Reducing the<br />
amount of data exchanged reduces the amount of data that can be<br />
misused or leaked.<br />
<br />
Data minimization can be effectuated in a number of different ways,<br />
including by limiting collection, use, disclosure, retention,<br />
identifiability, sensitivity, and access to personal data. Limiting<br />
the data collected by protocol elements to only what is necessary<br />
(collection limitation) is the most straightforward way to help<br />
reduce privacy risks associated with the use of the protocol. In<br />
some cases, protocol designers may also be able to recommend limits<br />
to the use or retention of data, although protocols themselves are<br />
not often capable of controlling these properties.<br />
<br />
However, the most direct application of data minimization to protocol<br />
design is limiting identifiability. Reducing the identifiability of<br />
data by using pseudonyms or no identifiers at all helps to weaken the<br />
link between an individual and his or her communications. Allowing<br />
for the periodic creation of new or randomized identifiers reduces<br />
the possibility that multiple protocol interactions or communications<br />
can be correlated back to the same individual. The following<br />
sections explore a number of different properties related to<br />
identifiability that protocol designers may seek to achieve.<br />
<br />
<br />
Data minimization mitigates the following threats: surveillance,<br />
stored data compromise, correlation, identification, secondary use,<br />
and disclosure.<br />
<br />
====<br/> 6.1.1. Anonymity ====<br />
To enable anonymity of an individual, there must exist a set of<br />
individuals that appear to have the same attribute(s) as the<br />
individual. To the attacker or the observer, these individuals must<br />
appear indistinguishable from each other. The set of all such<br />
individuals is known as the anonymity set, and membership of this set<br />
may vary over time.<br />
<br />
The composition of the anonymity set depends on the knowledge of the<br />
observer or attacker. Thus, anonymity is relative with respect to<br />
the observer or attacker. An initiator may be anonymous only within<br />
a set of potential initiators -- its initiator anonymity set -- which<br />
itself may be a subset of all individuals that may initiate<br />
communications. Conversely, a recipient may be anonymous only within<br />
a set of potential recipients -- its recipient anonymity set. Both<br />
anonymity sets may be disjoint, may overlap, or may be the same.<br />
<br />
As an example, consider RFC 3325 (P-Asserted-Identity (PAI))<br />
[RFC3325], an extension for the Session Initiation Protocol (SIP)<br />
that allows an individual, such as a Voice over IP (VoIP) caller, to<br />
instruct an intermediary that he or she trusts not to populate the<br />
SIP From header field with the individual's authenticated and<br />
verified identity. The recipient of the call, as well as any other<br />
entity outside of the individual's trust domain, would therefore only<br />
learn that the SIP message (typically a SIP INVITE) was sent with a<br />
header field 'From: "Anonymous" <sip:anonymous@anonymous.invalid>'<br />
rather than the individual's address-of-record, which is typically<br />
thought of as the "public address" of the user. When PAI is used,<br />
the individual becomes anonymous within the initiator anonymity set<br />
that is populated by every individual making use of that specific<br />
intermediary.<br />
<br />
Note that this example ignores the fact that the recipient may infer<br />
or obtain personal data from the other SIP payloads (e.g., SIP Via<br />
and Contact headers, the Session Description Protocol (SDP)). The<br />
implication is that PAI only attempts to address a particular threat,<br />
namely the disclosure of identity (in the From header) with respect<br />
to the recipient. This caveat makes the analysis of the specific<br />
protocol extension easier but cannot be assumed when conducting<br />
analysis of an entire architecture.<br />
<br />
<br />
====<br/> 6.1.2. Pseudonymity ====<br />
In the context of Internet protocols, almost all identifiers can be<br />
nicknames or pseudonyms, since there is typically no requirement to<br />
use personal names in protocols. However, in certain scenarios it is<br />
reasonable to assume that personal names will be used (with vCard<br />
[RFC6350], for example).<br />
<br />
Pseudonymity is strengthened when less personal data can be linked to<br />
the pseudonym; when the same pseudonym is used less often and across<br />
fewer contexts; and when independently chosen pseudonyms are more<br />
frequently used for new actions (making them, from an observer's or<br />
attacker's perspective, unlinkable).<br />
<br />
For Internet protocols, the following are important considerations:<br />
<br />
whether protocols allow pseudonyms to be changed without human<br />
interaction, the default length of pseudonym lifetimes, to whom<br />
pseudonyms are exposed, how individuals are able to control<br />
disclosure, how often pseudonyms can be changed, and the consequences<br />
of changing them.<br />
<br />
====<br/> 6.1.3. Identity Confidentiality ====<br />
An initiator has identity confidentiality when any party other than<br />
the recipient cannot sufficiently identify the initiator within the<br />
anonymity set. The size of the anonymity set has a direct impact on<br />
identity confidentiality, since the smaller the set is, the easier it<br />
is to identify the initiator. Identity confidentiality aims to<br />
provide a protection against eavesdroppers and intermediaries rather<br />
than against the intended communication endpoints.<br />
<br />
As an example, consider the network access authentication procedures<br />
utilizing the Extensible Authentication Protocol (EAP) [RFC3748].<br />
<br />
EAP includes an identity exchange where the Identity Response is<br />
primarily used for routing purposes and selecting which EAP method to<br />
use. Since EAP Identity Requests and Identity Responses are sent in<br />
cleartext, eavesdroppers and intermediaries along the communication<br />
path between the EAP peer and the EAP server can snoop on the<br />
identity, which is encoded in the form of the Network Access<br />
Identifier (NAI) as defined in RFC 4282 [RFC4282]. To address this<br />
threat, as discussed in RFC 4282 [RFC4282], the username part of the<br />
NAI (but not the realm part) can be hidden from these eavesdroppers<br />
and intermediaries with the cryptographic support offered by EAP<br />
methods. Identity confidentiality has become a recommended design<br />
criteria for EAP (see [RFC4017]). The EAP method for 3rd Generation<br />
Authentication and Key Agreement (EAP-AKA) [RFC4187], for example,<br />
protects the EAP peer's identity against passive adversaries by<br />
utilizing temporal identities. The EAP-Internet Key Exchange<br />
Protocol version 2 (EAP-IKEv2) method [RFC5106] is an example of an<br />
EAP method that offers protection against active attackers with<br />
regard to the individual's identity.<br />
<br />
====<br/> 6.1.4. Data Minimization within Identity Management ====<br />
Modern systems are increasingly relying on multi-party transactions<br />
to authenticate individuals. Many of these systems make use of an<br />
identity provider that is responsible for providing AAA functionality<br />
to relying parties that offer some protected resources. To<br />
facilitate these functions, an identity provider will usually go<br />
through a process of verifying the individual's identity and issuing<br />
credentials to the individual. When an individual seeks to make use<br />
of a service provided by the relying party, the relying party relies<br />
on the authentication assertions provided by its identity provider.<br />
<br />
Note that in more sophisticated scenarios the authentication<br />
assertions are traits that demonstrate the individual's capabilities<br />
and roles. The authorization responsibility may also be shared<br />
between the identity provider and the relying party and does not<br />
necessarily need to reside only with the identity provider.<br />
<br />
Such systems have the ability to support a number of properties that<br />
minimize data collection in different ways:<br />
<br />
In certain use cases, relying parties do not need to know the real<br />
name or date of birth of an individual (for example, when the<br />
individual's age is the only attribute that needs to be<br />
authenticated).<br />
<br />
Relying parties that collude can be prevented from using an<br />
individual's credentials to track the individual. That is, two<br />
different relying parties can be prevented from determining that<br />
the same individual has authenticated to both of them. This<br />
typically requires identity management protocol support as well as<br />
support by both the relying party and the identity provider.<br />
<br />
The identity provider can be prevented from knowing which relying<br />
parties an individual interacted with. This requires, at a<br />
minimum, avoiding direct communication between the identity<br />
provider and the relying party at the time when access to a<br />
resource by the initiator is made.<br />
<br />
===<br/> 6.2. User Participation ===<br />
As explained in Section 5.2.5, data collection and use that happen<br />
"in secret", without the individual's knowledge, are apt to violate<br />
the individual's expectation of privacy and may create incentives for<br />
misuse of data. As a result, privacy regimes tend to include<br />
provisions to require informing individuals about data collection and<br />
use and involving them in decisions about the treatment of their<br />
data. In an engineering context, supporting the goal of user<br />
participation usually means providing ways for users to control the<br />
data that is shared about them. It may also mean providing ways for<br />
users to signal how they expect their data to be used and shared.<br />
<br />
Different protocol and architectural designs can make supporting user<br />
participation (for example, the ability to support a dialog box for<br />
user interaction) easier or harder; for example, OAuth-based services<br />
may have more natural hooks for user input than AAA services.<br />
<br />
User participation mitigates the following threats: surveillance,<br />
secondary use, disclosure, and exclusion.<br />
<br />
===<br/> 6.3. Security ===<br />
Keeping data secure at rest and in transit is another important<br />
component of privacy protection. As they are described in Section 2<br />
of [RFC3552], a number of security goals also serve to enhance<br />
privacy:<br />
<br />
* Confidentiality: Keeping data secret from unintended listeners.<br />
* Peer entity authentication: Ensuring that the endpoint of a communication is the one that is intended (in support of maintaining confidentiality).<br />
* Unauthorized usage: Limiting data access to only those users who are authorized. (Note that this goal also falls within data minimization.) * Inappropriate usage: Limiting how authorized users can use data.<br />
(Note that this goal also falls within data minimization.)<br />
Note that even when these goals are achieved, the existence of items<br />
of interest -- attributes, identifiers, identities, communications,<br />
actions (such as the sending or receiving of a communication), or<br />
anything else an attacker or observer might be interested in -- may<br />
still be detectable, even if they are not readable. Thus,<br />
undetectability, in which an observer or attacker cannot sufficiently<br />
distinguish whether an item of interest exists or not, may be<br />
considered as a further security goal (albeit one that can be<br />
extremely difficult to accomplish).<br />
<br />
Detection of the protocols or applications in use via traffic<br />
analysis may be particularly difficult to defend against. As with<br />
the anonymity of individuals, achieving "protocol anonymity" requires<br />
that multiple protocols or applications exist that appear to have the<br />
same attributes -- packet sizes, content, token locations, or<br />
inter-packet timing, for example. An attacker or observer will not<br />
be able to use traffic analysis to identify which protocol or<br />
application is in use if multiple protocols or applications are<br />
indistinguishable.<br />
<br />
Defending against the threat of traffic analysis will be possible to<br />
different extents for different protocols, may depend on<br />
implementation- or use-specific details, and may depend on which<br />
other protocols already exist and whether they share similar traffic<br />
characteristics. The defenses will also vary relative to what the<br />
protocol is designed to do; for example, in some situations<br />
randomizing packet sizes, timing, or token locations will reduce the<br />
threat of traffic analysis, whereas in other situations (real-time<br />
communications, for example) holding some or all of those factors<br />
constant is a more appropriate defense. See "Guidelines for the Use<br />
of Variable Bit Rate Audio with Secure RTP" [RFC6562] for an example<br />
of how these kinds of trade-offs should be evaluated.<br />
<br />
By providing proper security protection, the following threats can be<br />
mitigated: surveillance, stored data compromise, misattribution,<br />
secondary use, disclosure, and intrusion.<br />
<br />
==<br/> 7. Guidelines ==<br />
This section provides guidance for document authors in the form of a<br />
questionnaire about a protocol being designed. The questionnaire may<br />
be useful at any point in the design process, particularly after<br />
document authors have developed a high-level protocol model as<br />
described in [RFC4101].<br />
<br />
Note that the guidance provided in this section does not recommend<br />
specific practices. The range of protocols developed in the IETF is<br />
too broad to make recommendations about particular uses of data or<br />
how privacy might be balanced against other design goals. However,<br />
by carefully considering the answers to each question, document<br />
authors should be able to produce a comprehensive analysis that can<br />
serve as the basis for discussion of whether the protocol adequately<br />
protects against privacy threats. This guidance is meant to help the<br />
thought process of privacy analysis; it does not provide specific<br />
directions for how to write a privacy considerations section.<br />
<br />
The framework is divided into four sections: three sections that<br />
address each of the mitigation classes from Section 6, plus a general<br />
section. Security is not fully elaborated, since substantial<br />
guidance already exists in [RFC3552].<br />
<br />
<br />
===<br/> 7.1. Data Minimization ===<br />
a. Identifiers. What identifiers does the protocol use for<br />
distinguishing initiators of communications? Does the protocol<br />
use identifiers that allow different protocol interactions to be<br />
correlated? What identifiers could be omitted or be made less<br />
identifying while still fulfilling the protocol's goals?<br />
<br />
b. Data. What information does the protocol expose about<br />
individuals, their devices, and/or their device usage (other than<br />
the identifiers discussed in (a))? To what extent is this<br />
information linked to the identities of the individuals? How<br />
does the protocol combine personal data with the identifiers<br />
discussed in (a)?<br />
<br />
c. Observers. Which information discussed in (a) and (b) is exposed<br />
to each other protocol entity (i.e., recipients, intermediaries,<br />
and enablers)? Are there ways for protocol implementers to<br />
choose to limit the information shared with each entity? Are<br />
there operational controls available to limit the information<br />
shared with each entity?<br />
<br />
d. Fingerprinting. In many cases, the specific ordering and/or<br />
occurrences of information elements in a protocol allow users,<br />
devices, or software using the protocol to be fingerprinted. Is<br />
this protocol vulnerable to fingerprinting? If so, how? Can it<br />
be designed to reduce or eliminate the vulnerability? If not,<br />
why not?<br />
<br />
e. Persistence of identifiers. What assumptions are made in the<br />
protocol design about the lifetime of the identifiers discussed<br />
in (a)? Does the protocol allow implementers or users to delete<br />
or replace identifiers? How often does the specification<br />
recommend deleting or replacing identifiers by default? Can the<br />
identifiers, along with other state information, be set to<br />
automatically expire?<br />
<br />
f. Correlation. Does the protocol allow for correlation of<br />
identifiers? Are there expected ways that information exposed by<br />
the protocol will be combined or correlated with information<br />
obtained outside the protocol? How will such combination or<br />
correlation facilitate fingerprinting of a user, device, or<br />
application? Are there expected combinations or correlations<br />
with outside data that will make users of the protocol more<br />
identifiable?<br />
<br />
<br />
g. Retention. Does the protocol or its anticipated uses require<br />
that the information discussed in (a) or (b) be retained by<br />
recipients, intermediaries, or enablers? If so, why? Is the<br />
retention expected to be persistent or temporary?<br />
<br />
===<br/> 7.2. User Participation ===<br />
a. User control. What controls or consent mechanisms does the<br />
protocol define or require before personal data or identifiers<br />
are shared or exposed via the protocol? If no such mechanisms or<br />
controls are specified, is it expected that control and consent<br />
will be handled outside of the protocol?<br />
<br />
b. Control over sharing with individual recipients. Does the<br />
protocol provide ways for initiators to share different<br />
information with different recipients? If not, are there<br />
mechanisms that exist outside of the protocol to provide<br />
initiators with such control?<br />
<br />
c. Control over sharing with intermediaries. Does the protocol<br />
provide ways for initiators to limit which information is shared<br />
with intermediaries? If not, are there mechanisms that exist<br />
outside of the protocol to provide users with such control? Is<br />
it expected that users will have relationships that govern the<br />
use of the information (contractual or otherwise) with those who<br />
operate these intermediaries?<br />
<br />
d. Preference expression. Does the protocol provide ways for<br />
initiators to express individuals' preferences to recipients or<br />
intermediaries with regard to the collection, use, or disclosure<br />
of their personal data?<br />
<br />
===<br/> 7.3. Security ===<br />
a. Surveillance. How do the protocol's security considerations<br />
prevent surveillance, including eavesdropping and traffic<br />
analysis? Does the protocol leak information that can be<br />
observed through traffic analysis, such as by using a fixed token<br />
at fixed offsets, or packet sizes or timing that allow observers<br />
to determine characteristics of the traffic (e.g., which protocol<br />
is in use or whether the traffic is part of a real-time flow)?<br />
<br />
b. Stored data compromise. How do the protocol's security<br />
considerations prevent or mitigate stored data compromise?<br />
<br />
<br />
c. Intrusion. How do the protocol's security considerations prevent<br />
or mitigate intrusion, including denial-of-service attacks and<br />
unsolicited communications more generally?<br />
<br />
d. Misattribution. How do the protocol's mechanisms for identifying<br />
and/or authenticating individuals prevent misattribution?<br />
<br />
===<br/> 7.4. General ===<br />
a. Trade-offs. Does the protocol make trade-offs between privacy<br />
and usability, privacy and efficiency, privacy and<br />
implementability, or privacy and other design goals? Describe<br />
the trade-offs and the rationale for the design chosen.<br />
<br />
b. Defaults. If the protocol can be operated in multiple modes or<br />
with multiple configurable options, does the default mode or<br />
option minimize the amount, identifiability, and persistence of<br />
the data and identifiers exposed by the protocol? Does the<br />
default mode or option maximize the opportunity for user<br />
participation? Does it provide the strictest security features<br />
of all the modes/options? If the answer to any of these<br />
questions is no, explain why less protective defaults were<br />
chosen.<br />
<br />
==<br/> 8. Example ==<br />
The following section gives an example of the threat analysis and<br />
threat mitigations recommended by this document. It covers a<br />
particularly difficult application protocol, presence, to try to<br />
demonstrate these principles on an architecture that is vulnerable to<br />
many of the threats described above. This text is not intended as an<br />
example of a privacy considerations section that might appear in an<br />
IETF specification, but rather as an example of the thinking that<br />
should go into the design of a protocol when considering privacy as a<br />
first principle.<br />
<br />
A presence service, as defined in the abstract in [RFC2778], allows<br />
users of a communications service to monitor one another's<br />
availability and disposition in order to make decisions about<br />
communicating. Presence information is highly dynamic and generally<br />
characterizes whether a user is online or offline, busy or idle, away<br />
from communications devices or nearby, and the like. Necessarily,<br />
this information has certain privacy implications, and from the start<br />
the IETF approached this work with the aim of providing users with<br />
the controls to determine how their presence information would be<br />
shared. The Common Profile for Presence (CPP) [RFC3859] defines a<br />
set of logical operations for delivery of presence information. This<br />
abstract model is applicable to multiple presence systems. The SIP<br />
for Instant Messaging and Presence Leveraging Extensions (SIMPLE)<br />
presence system [RFC3856] uses CPP as its baseline architecture, and<br />
the presence operations in the Extensible Messaging and Presence<br />
Protocol (XMPP) have also been mapped to CPP [RFC3922].<br />
<br />
The fundamental architecture defined in RFC 2778 and RFC 3859 is a<br />
mediated one. Clients (presentities in RFC 2778 terms) publish their<br />
presence information to presence servers, which in turn distribute<br />
information to authorized watchers. Presence servers thus retain<br />
presence information for an interval of time, until it either changes<br />
or expires, so that it can be revealed to authorized watchers upon<br />
request. This architecture mirrors existing pre-standard deployment<br />
models. The integration of an explicit authorization mechanism into<br />
the presence architecture has been widely successful in involving the<br />
end users in the decision-making process before sharing information.<br />
<br />
Nearly all presence systems deployed today provide such a mechanism,<br />
typically through a reciprocal authorization system by which a pair<br />
of users, when they agree to be "buddies", consent to divulge their<br />
presence information to one another. Buddylists are managed by<br />
servers but controlled by end users. Users can also explicitly block<br />
one another through a similar interface, and in some deployments it<br />
is desirable to provide "polite blocking" of various kinds.<br />
<br />
From a perspective of privacy design, however, the classical presence<br />
architecture represents nearly a worst-case scenario. In terms of<br />
data minimization, presentities share their sensitive information<br />
with presence services, and while services only share this presence<br />
information with watchers authorized by the user, no technical<br />
mechanism constrains those watchers from relaying presence to further<br />
third parties. Any of these entities could conceivably log or retain<br />
presence information indefinitely. The sensitivity cannot be<br />
mitigated by rendering the user anonymous, as it is indeed the<br />
purpose of the system to facilitate communications between users who<br />
know one another. The identifiers employed by users are long-lived<br />
and often contain personal information, including personal names and<br />
the domains of service providers. While users do participate in the<br />
construction of buddylists and blacklists, they do so with little<br />
prospect for accountability: the user effectively throws their<br />
presence information over the wall to a presence server that in turn<br />
distributes the information to watchers. Users typically have no way<br />
to verify that presence is being distributed only to authorized<br />
watchers, especially as it is the server that authenticates watchers,<br />
not the end user. Moreover, connections between the server and all<br />
publishers and consumers of presence data are an attractive target<br />
for eavesdroppers and require strong confidentiality mechanisms,<br />
though again the end user has no way to verify what mechanisms are in<br />
place between the presence server and a watcher.<br />
<br />
<br />
Additionally, the sensitivity of presence information is not limited<br />
to the disposition and capability to communicate. Capabilities can<br />
reveal the type of device that a user employs, for example, and since<br />
multiple devices can publish the same user's presence, there are<br />
significant risks of allowing attackers to correlate user devices.<br />
<br />
An important extension to presence was developed to enable the<br />
support for location sharing. The effort to standardize protocols<br />
for systems sharing geolocation was started in the GEOPRIV working<br />
group. During the initial requirements and privacy threat analysis<br />
in the process of chartering the working group, it became clear that<br />
the system would require an underlying communication mechanism<br />
supporting user consent to share location information. The<br />
resemblance of these requirements to the presence framework was<br />
quickly recognized, and this design decision was documented in<br />
[RFC4079]. Location information thus mingles with other presence<br />
information available through the system to intermediaries and to<br />
authorized watchers.<br />
<br />
Privacy concerns about presence information largely arise due to the<br />
built-in mediation of the presence architecture. The need for a<br />
presence server is motivated by two primary design requirements of<br />
presence: in the first place, the server can respond with an<br />
"offline" indication when the user is not online; in the second<br />
place, the server can compose presence information published by<br />
different devices under the user's control. Additionally, to<br />
facilitate the use of URIs as identifiers for entities, some service<br />
must operate a host with the domain name appearing in a presence URI,<br />
and in practical terms no commercial presence architecture would<br />
force end users to own and operate their own domain names. Many end<br />
users of applications like presence are behind NATs or firewalls and<br />
effectively cannot receive direct connections from the Internet --<br />
the persistent bidirectional channel these clients open and maintain<br />
with a presence server is essential to the operation of the protocol.<br />
<br />
One must first ask if the trade-off of mediation for presence is<br />
worthwhile. Does a server need to be in the middle of all<br />
publications of presence information? It might seem that end-to-end<br />
encryption of the presence information could solve many of these<br />
problems. A presentity could encrypt the presence information with<br />
the public key of a watcher and only then send the presence<br />
information through the server. The IETF defined an object format<br />
for presence information called the Presence Information Data Format<br />
(PIDF), which for the purposes of conveying location information was<br />
extended to the PIDF Location Object (PIDF-LO) -- these XML objects<br />
were designed to accommodate an encrypted wrapper. Encrypting this<br />
data would have the added benefit of preventing stored cleartext<br />
presence information from being seized by an attacker who manages to<br />
compromise a presence server. This proposal, however, quickly runs<br />
into usability problems. Discovering the public keys of watchers is<br />
the first difficulty, one that few Internet protocols have addressed<br />
successfully. This solution would then require the presentity to<br />
publish one encrypted copy of its presence information per authorized<br />
watcher to the presence service, regardless of whether or not a<br />
watcher is actively seeking presence information -- for a presentity<br />
with many watchers, this may place an unacceptable burden on the<br />
presence server, especially given the dynamism of presence<br />
information. Finally, it prevents the server from composing presence<br />
information reported by multiple devices under the same user's<br />
control. On the whole, these difficulties render object encryption<br />
of presence information a doubtful prospect.<br />
<br />
Some protocols that support presence information, such as SIP, can<br />
operate intermediaries in a redirecting mode rather than a publishing<br />
or proxying mode. Instead of sending presence information through<br />
the server, in other words, these protocols can merely redirect<br />
watchers to the presentity, and then presence information could pass<br />
directly and securely from the presentity to the watcher. It is<br />
worth noting that this would disclose the IP address of the<br />
presentity to the watcher, which has its own set of risks. In that<br />
case, the presentity can decide exactly what information it would<br />
like to share with the watcher in question, it can authenticate the<br />
watcher itself with whatever strength of credential it chooses, and<br />
with end-to-end encryption it can reduce the likelihood of any<br />
eavesdropping. In a redirection architecture, a presence server<br />
could still provide the necessary "offline" indication without<br />
requiring the presence server to observe and forward all information<br />
itself. This mechanism is more promising than encryption but also<br />
suffers from significant difficulties. It too does not provide for<br />
composition of presence information from multiple devices -- it in<br />
fact forces the watcher to perform this composition itself. The<br />
largest single impediment to this approach is, however, the<br />
difficulty of creating end-to-end connections between the<br />
presentity's device(s) and a watcher, as some or all of these<br />
endpoints may be behind NATs or firewalls that prevent peer-to-peer<br />
connections. While there are potential solutions for this problem,<br />
like Session Traversal Utilities for NAT (STUN) and Traversal Using<br />
Relays around NAT (TURN), they add complexity to the overall system.<br />
<br />
Consequently, mediation is a difficult feature of the presence<br />
architecture to remove. It is hard to minimize the data shared with<br />
intermediaries, especially due to the requirement for composition.<br />
<br />
Control over sharing with intermediaries must therefore come from<br />
some other explicit component of the architecture. As such, the<br />
presence work in the IETF focused on improving user participation in<br />
the activities of the presence server. This work began in the<br />
GEOPRIV working group, with controls on location privacy, as location<br />
of users is perceived as having especially sensitive properties.<br />
<br />
With the aim of meeting the privacy requirements defined in<br />
[RFC2779], a set of usage indications, such as whether retransmission<br />
is allowed or when the retention period expires, have been added to<br />
the PIDF-LO such that they always travel with the location<br />
information itself. These privacy preferences apply not only to the<br />
intermediaries that store and forward presence information but also<br />
to the watchers who consume it.<br />
<br />
This approach very much follows the spirit of Creative Commons [CC],<br />
namely the usage of a limited number of conditions (such as 'Share<br />
Alike' [CC-SA]). Unlike Creative Commons, the GEOPRIV working group<br />
did not, however, initiate work to produce legal language or design<br />
graphical icons, since this would fall outside the scope of the IETF.<br />
<br />
In particular, the GEOPRIV rules state a preference on the retention<br />
and retransmission of location information; while GEOPRIV cannot<br />
force any entity receiving a PIDF-LO object to abide by those<br />
preferences, if users lack the ability to express them at all, we can<br />
guarantee their preferences will not be honored. The GEOPRIV rules<br />
can provide a means to establish accountability.<br />
<br />
The retention and retransmission elements were envisioned as the most<br />
essential examples of preference expression in sharing presence. The<br />
PIDF object was designed for extensibility, and the rulesets created<br />
for the PIDF-LO can also be extended to provide new expressions of<br />
user preference. Not all user preference information should be bound<br />
into a particular PIDF object, however; many forms of access control<br />
policy assumed by the presence architecture need to be provisioned in<br />
the presence server by some interface with the user. This<br />
requirement eventually triggered the standardization of a general<br />
access control policy language called the common policy framework<br />
(defined in [RFC4745]). This language allows one to express ways to<br />
control the distribution of information as simple conditions,<br />
actions, and transformation rules expressed in an XML format. Common<br />
Policy itself is an abstract format that needs to be instantiated:<br />
<br />
two examples can be found with the presence authorization rules<br />
[RFC5025] and the Geolocation Policy [RFC6772]. The former provides<br />
additional expressiveness for presence-based systems, while the<br />
latter defines syntax and semantics for location-based conditions and<br />
transformations.<br />
<br />
Ultimately, the privacy work on presence represents a compromise<br />
between privacy principles and the needs of the architecture and<br />
marketplace. While it was not feasible to remove intermediaries from<br />
the architecture entirely or prevent their access to presence<br />
information, the IETF did provide a way for users to express their<br />
preferences and provision their controls at the presence service. We<br />
have not had great successes in the implementation space with privacy<br />
mechanisms thus far, but by documenting and acknowledging the<br />
limitations of these mechanisms, the designers were able to provide<br />
implementers, and end users, with an informed perspective on the<br />
privacy properties of the IETF's presence protocols.<br />
<br />
==<br/> 9. Security Considerations ==<br />
This document describes privacy aspects that protocol designers<br />
should consider in addition to regular security analysis.<br />
<br />
==<br/> 10. Acknowledgements ==<br />
We would like to thank Christine Runnegar for her extensive helpful<br />
review comments.<br />
<br />
We would like to thank Scott Brim, Kasey Chappelle, Marc Linsner,<br />
Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat<br />
Sakimura, Bjoern Hoehrmann, David Singer, Dean Willis, Lucy Lynch,<br />
Trent Adams, Mark Lizar, Martin Thomson, Josh Howlett, Mischa<br />
Tuffield, S. Moonesamy, Zhou Sujing, Claudia Diaz, Leif Johansson,<br />
Jeff Hodges, Stephen Farrell, Steven Johnston, Cullen Jennings, Ted<br />
Hardie, Dave Thaler, Klaas Wierenga, Adrian Farrel, Stephane<br />
Bortzmeyer, Dave Crocker, and Hector Santos for their useful feedback<br />
on this document.<br />
<br />
Finally, we would like to thank the participants for the feedback<br />
they provided during the December 2010 Internet Privacy workshop<br />
co-organized by MIT, ISOC, W3C, and the IAB.<br />
<br />
Although John Morris is currently employed by the U.S. Government, he<br />
participated in the development of this document in his personal<br />
capacity, and the views expressed in the document may not reflect<br />
those of his employer.<br />
<br />
<br />
==<br/> 11. IAB Members at the Time of Approval ==<br />
:Bernard Aboba<br />
:Jari Arkko<br />
:Marc Blanchet<br />
:Ross Callon<br />
:Alissa Cooper<br />
:Spencer Dawkins<br />
:Joel Halpern<br />
:Russ Housley<br />
:Eliot Lear<br />
:Xing Li<br />
:Andrew Sullivan<br />
:Dave Thaler<br />
:Hannes Tschofenig<br />
==<br/> 12. Informative References ==<br />
[CC-SA] Creative Commons, "Share Alike", 2012,<br />
<http://wiki.creativecommons.org/Share_Alike>.<br />
<br />
[CC] Creative Commons, "Creative Commons", 2012,<br />
<http://creativecommons.org/>.<br />
<br />
[CoE] Council of Europe, "Recommendation CM/Rec(2010)13 of the<br />
Committee of Ministers to member states on the protection<br />
of individuals with regard to automatic processing of<br />
personal data in the context of profiling", November 2010,<br />
<https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>.<br />
<br />
[EFF] Electronic Frontier Foundation, "Panopticlick", 2013,<br />
<http://panopticlick.eff.org>.<br />
<br />
[FIPs] Gellman, B., "Fair Information Practices: A Basic<br />
History", 2012,<br />
<http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>.<br />
<br />
[OECD] Organisation for Economic Co-operation and Development,<br />
"OECD Guidelines on the Protection of Privacy and<br />
Transborder Flows of Personal Data", (adopted 1980),<br />
September 2010, <http://www.oecd.org/>.<br />
<br />
[PbD] Office of the Information and Privacy Commissioner,<br />
Ontario, Canada, "Privacy by Design", 2013,<br />
<http://privacybydesign.ca/>.<br />
<br />
<br />
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,<br />
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext<br />
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.<br />
<br />
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for<br />
Presence and Instant Messaging", RFC 2778, February 2000.<br />
<br />
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant<br />
Messaging / Presence Protocol Requirements", RFC 2779,<br />
February 2000.<br />
<br />
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,<br />
A., Peterson, J., Sparks, R., Handley, M., and E.<br />
<br />
Schooler, "SIP: Session Initiation Protocol", RFC 3261,<br />
June 2002.<br />
<br />
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private<br />
Extensions to the Session Initiation Protocol (SIP) for<br />
Asserted Identity within Trusted Networks", RFC 3325,<br />
November 2002.<br />
<br />
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC<br />
Text on Security Considerations", BCP 72, RFC 3552,<br />
July 2003.<br />
<br />
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.<br />
<br />
Levkowetz, "Extensible Authentication Protocol (EAP)",<br />
RFC 3748, June 2004.<br />
<br />
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session<br />
Initiation Protocol (SIP)", RFC 3856, August 2004.<br />
<br />
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)",<br />
RFC 3859, August 2004.<br />
<br />
[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and<br />
Presence Protocol (XMPP) to Common Presence and Instant<br />
Messaging (CPIM)", RFC 3922, October 2004.<br />
<br />
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible<br />
Authentication Protocol (EAP) Method Requirements for<br />
Wireless LANs", RFC 4017, March 2005.<br />
<br />
[RFC4079] Peterson, J., "A Presence Architecture for the<br />
Distribution of GEOPRIV Location Objects", RFC 4079,<br />
July 2005.<br />
<br />
<br />
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,<br />
June 2005.<br />
<br />
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication<br />
Protocol Method for 3rd Generation Authentication and Key<br />
Agreement (EAP-AKA)", RFC 4187, January 2006.<br />
<br />
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The<br />
Network Access Identifier", RFC 4282, December 2005.<br />
<br />
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,<br />
Polk, J., and J. Rosenberg, "Common Policy: A Document<br />
Format for Expressing Privacy Preferences", RFC 4745,<br />
February 2007.<br />
<br />
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed<br />
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.<br />
<br />
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",<br />
RFC 4949, August 2007.<br />
<br />
[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025,<br />
December 2007.<br />
<br />
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,<br />
"Transport Layer Security (TLS) Session Resumption without<br />
Server-Side State", RFC 5077, January 2008.<br />
<br />
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,<br />
and F. Bersani, "The Extensible Authentication Protocol-<br />
Internet Key Exchange Protocol version 2 (EAP-IKEv2)<br />
Method", RFC 5106, February 2008.<br />
<br />
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security<br />
(TLS) Protocol Version 1.2", RFC 5246, August 2008.<br />
<br />
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.<br />
<br />
Roberts, "Issues with IP Address Sharing", RFC 6269,<br />
June 2011.<br />
<br />
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,<br />
Tschofenig, H., and H. Schulzrinne, "An Architecture for<br />
Location and Location Privacy in Internet Applications",<br />
BCP 160, RFC 6280, July 2011.<br />
<br />
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,<br />
"Logging Recommendations for Internet-Facing Servers",<br />
BCP 162, RFC 6302, June 2011.<br />
<br />
<br />
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,<br />
August 2011.<br />
<br />
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of<br />
Variable Bit Rate Audio with Secure RTP", RFC 6562,<br />
March 2012.<br />
<br />
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the<br />
Opus Audio Codec", RFC 6716, September 2012.<br />
<br />
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,<br />
Morris, J., and M. Thomson, "Geolocation Policy: A<br />
Document Format for Expressing Privacy Preferences for<br />
Location Information", RFC 6772, January 2013.<br />
<br />
[Solove] Solove, D., "Understanding Privacy", March 2010.<br />
<br />
[Tor] The Tor Project, Inc., "Tor", 2013,<br />
<https://www.torproject.org/>.<br />
<br />
[Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey<br />
of Westin's Studies", December 2005,<br />
<http://reports-archive.adm.cs.cmu.edu/anon/isri2005/<br />
CMU-ISRI-05-138.pdf>.<br />
<br />
==<br/> Authors ==<br />
<br />
Alissa Cooper<br />
:CDT<br />
:1634 Eye St. NW, Suite 1100<br />
:Washington, DC 20006<br />
:US<br />
:Phone: +1-202-637-9800<br />
:EMail: acooper@cdt.org<br />
:URI: http://www.cdt.org/<br />
<br />
Hannes Tschofenig<br />
:Nokia Siemens Networks<br />
:Linnoitustie 6<br />
:Espoo 02600<br />
:Finland<br />
:Phone: +358 (50) 4871445<br />
:EMail: Hannes.Tschofenig@gmx.net<br />
:URI: http://www.tschofenig.priv.at<br />
<br />
Bernard Aboba<br />
:Skype<br />
:EMail: bernard_aboba@hotmail.com<br />
:Jon Peterson<br />
:NeuStar, Inc.<br />
<br />
:1800 Sutter St. Suite 570<br />
:Concord, CA 94520<br />
:US<br />
:EMail: jon.peterson@neustar.biz<br />
<br />
John B. Morris, Jr.<br />
<br />
:EMail: ietf@jmorris.org<br />
<br />
Marit Hansen<br />
:ULD<br />
:EMail: marit.hansen@datenschutzzentrum.de<br />
<br />
Rhys Smith<br />
:Janet<br />
:EMail: rhys.smith@ja.net</div>Sysophttp://iuwg.net/index.php/Debate_elementsDebate elements2016-02-11T19:43:53Z<p>Sysop: </p>
<hr />
<div><br />
* [[Commented RFC 6973]]<br />
* [[HRPC-Draft-reasearch Annotations]]</div>Sysophttp://iuwg.net/index.php/Human_rights_protocol_considerations_(HRC)Human rights protocol considerations (HRC)2016-02-11T14:05:57Z<p>Sysop: /* Debate elements */</p>
<hr />
<div><br/><br />
<center><big>[[The Universal Declaration of Human Rights]]<br/><br/>[[International Covenant on Civil and Political Rights]]</big><br/><br/>___________</center><br />
<br />
<br />
__TOC__<br />
<br />
<br />
== Debate elements==<br />
<br />
* [[Commented RFC 6973]]<br />
* [[Commented HRPC-Draft-reasearch]]<br />
<br />
== Human Rights Protocol Considerations (hrpc) ==<br />
<br />
RG Name Human Rights Protocol Considerations <br />
<br />
==== Acronym hrpc ====<br />
:State Active <br />
:Charter charter-irtf-hrpc-01 Approved <br />
:Personnel Chairs <br />
::Niels Oever <br />
::Avri Doria <br />
:Mailing list Addresshrpc@irtf.org <br />
<br />
To subscribehttps://www.irtf.org/mailman/listinfo/hrpc <br />
<br />
Archivehttp://www.ietf.org/mail-archive/web/hrpc/ <br />
<br />
Jabber chat Room address xmpp://hrpc@jabber.ietf.org <br />
<br />
Logs https://jabber.ietf.org/logs/hrpc/ <br />
<br />
<br />
== Charter for Research Group ==<br />
<br />
==== Background ====<br />
<br />
The Human Rights Protocol Considerations Research Group is chartered to research <br />
whether standards and protocols can enable, strengthen or threaten human rights, <br />
as defined in the Universal Declaration of Human Rights (UDHR) [1] and the <br />
International Covenant on Civil and Political Rights (ICCPR) [2], specifically, <br />
but not limited to the right to freedom of expression and the right to freedom <br />
of assembly. <br />
<br />
The research group takes as its starting point the problem statement that <br />
human-rights-enabling characteristics of the Internet might be degraded if they <br />
are not properly defined, described and sufficiently taken into account in <br />
protocol development. Not protecting these characteristics could result in <br />
(partial) loss of functionality and connectivity. <br />
<br />
As evinced by RFC 1958, the Internet aims to be the global network of networks <br />
that provides unfettered connectivity to all users at all times and for any <br />
content. Open, secure and reliable connectivity is essential for rights such as <br />
freedom of expression and freedom of association. Since the Internet’s objective <br />
of connectivity makes it an enabler of human rights, its architectural design <br />
converges with the human rights framework. <br />
<br />
The Internet was designed with freedom and openness of communications as core <br />
values. But as the scale and the industrialization of the Internet has grown <br />
greatly, the influence of such world-views started to compete with other values. <br />
This research group aims to explore the relations between human rights and <br />
protocols and to provide guidelines to inform future protocol development and <br />
decision making where protocol s impact the effective exercise of the rights to <br />
freedom of expression or association. <br />
<br />
====Objective ====<br />
<br />
This research has these major aims: <br />
<br />
* To expose the relation between protocols and human rights, with a focus on the rights to freedom of expression and freedom of assembly. <br />
<br />
* To propose guidelines to protect the Internet as a human-rights-enabling environment in future protocol development, in a manner similar to the work done for Privacy Considerations in RFC 6973. <br />
<br />
* To increase the awareness in both the human rights community and the technical community on the importance of the technical workings of the Internet and its impact on human rights. <br />
<br />
==== Outputs ====<br />
<br />
The research group plans on using a variety of research methods to create <br />
different outputs including, but not limited to: <br />
<br />
* Internet drafts, some of which may be put on IRTF RFC stream. These will concern progress of the project, methodology, and will define any possible protocol considerations. <br />
<br />
* Policy and academic papers, for in-depth analysis and discussion of the relationship between human rights and the Internet architecture and protocols. <br />
<br />
* Film and textual interviews with a diverse set of community members, to give an accessible insight into the variety of opinions on this topic represented in the IETF. <br />
<br />
* Data analysis and visualization, to research and visualize the language used in current and historic RFCs and mailinglist discussions to expose core architectural principles, language and deliberations on human rights of those affected by the network. <br />
<br />
* Protocol analysis. Data analysis and visualization of (existing) protocols in the wild to research their concrete impact on human rights. <br />
<br />
==== Membership ====<br />
<br />
Membership is open to any interested parties who intend to remain current with <br />
the published documents and mailing list issues. <br />
<br />
: [1] http://www.un.org/en/documents/udhr/ <br />
: [2] http://www.ohchr.org/EN/ProfessionalInterest/Pages/CCPR.aspx<br />
<br />
<br/></div>Sysophttp://iuwg.net/index.php/Proposal_for_research_on_human_rights_protocol_considerations_draft-doria-hrpc-proposal-01Proposal for research on human rights protocol considerations draft-doria-hrpc-proposal-012015-12-06T23:52:19Z<p>Sysop: Sysop moved page Proposal for research on human rights protocol considerations draft-doria-hrpc-proposal-01 to Proposal for research on human rights protocol considerations</p>
<hr />
<div><br/><br />
''Ce Draft est en discussion à l''''[https://irtf.org/ IRTF]''' : [https://tools.ietf.org/html/draft-doria-hrpc-proposal Texte - version actuelle].''<br />
<br />
<br />
Work has been done on privacy issues that should be considered when<br />
creating an Internet protocol. This draft suggests that similar<br />
considerations may apply for other human rights such as freedom of<br />
expression or freedom of association. A proposal is made for work in<br />
the IRTF researching the possible connections between human rights<br />
and Internet standards and protocols. The goal is to create an<br />
informational RFC concerning human rights protocol considerations.<br />
<br />
<br />
==<br/> 1. Introduction ==<br />
<br />
The recognition that human rights have a role in Internet policies is<br />
slowly becoming part of the general discourse. Several reports from<br />
former United Nations (UN) Special Rapporteur on the promotion and<br />
protection of the right to freedom of opinion and expression, Frank<br />
La Rue, have made such relation explicit, which lead to the approval<br />
of the landmark resolution "on the promotion, protection and<br />
enjoyment of human rights on the Internet" [HRC2012] at the UN Human<br />
Rights Council (HRC). More recently, to the resolution "The right to<br />
privacy in the digital age" [UNGA2013] at the UN General Assembly.<br />
<br />
The NETmundial outcome document [NETmundial] affirms that human<br />
rights, as reflected in the Universal Declaration of Human Rights<br />
[UDHR], should underpin Internet governance principles.<br />
<br />
Nevertheless, a direct relation between Internet Standards and human<br />
rights is still something to be explored and more clearly evidenced.<br />
<br />
<br />
Concerns for freedom of expression and association were a strong part<br />
of the world-view of the community involved in developing the first<br />
Internet protocols. Apparently, by intention or by coincidence, the<br />
Internet was designed with freedom and openness of communications as<br />
core values. But as the scale and the industrialization of the<br />
Internet has grown greatly, the influence of such world-views started<br />
to compete with other values. The belief of the authors is that as<br />
the Internet continues to grow, the linkage of Internet protocols to<br />
human rights needs to become explicit, structured, and intentional.<br />
<br />
Standards and protocols form the basis of the human rights enabling<br />
infrastructure of the Internet. It needs to be determined whether<br />
there is a causal relationship between Internet protocols and<br />
standards, and human rights such as freedom of expression. To study<br />
the relationship between the two one would need to carefully consider<br />
structural and architectural considerations, as well as specific<br />
protocols. The Internet Society paper "Human Rights and Internet<br />
Protocols" [HRIP] "explores human rights and Internet protocols<br />
comparing the processes for their making and the principles by which<br />
they operate and concludes that there are some shared principles<br />
between the two." Though that paper does not go into possible<br />
reasons, dependencies or guidelines, it initiates the discussion.<br />
<br />
More research is needed to map human rights concerns to protocol<br />
elements and to frame possible approaches towards protocols that<br />
satisfy the implications of human rights standards.<br />
<br />
To move this debate further, a list has been created for discussion<br />
of this draft: hrpc@article19.io and related ideas - information or<br />
subscriptions at: https://lists.ghserv.net/mailman/listinfo/hrpc<br />
<br />
=== 1.1. Requirements Language ===<br />
<br />
As this is an informational document describing a research effort, it<br />
will not make use of requirements language as defined in RFC 2119<br />
[RFC2119].<br />
<br />
==<br/> 2. Research topic ==<br />
<br />
In a manner similar to the work done for RFC 6973 [RFC6973] on<br />
Privacy Consideration Guidelines, the premise of this research is<br />
that some standards and protocols can solidify, enable or threaten<br />
user rights.<br />
<br />
As stated in RFC 1958 [RFC1958], the Internet aims to be the global<br />
network of networks that provides unfettered connectivity to all<br />
users at all times and for any content. Open, secure and reliable<br />
connectivity is essential for rights such as freedom of expression<br />
and freedom of association, as defined in the Universal Declaration<br />
of Human Rights [UDHR]. Therefore, considering connectivity as the<br />
ultimate objective of the Internet, this makes a clear case that the<br />
Internet is not only an enabler of human rights, but that human<br />
rights lie at the basis of, and are ingrained in, the architecture of<br />
the network.<br />
<br />
An essential part of maintaining the Internet as a tool for<br />
communication and connectivity is security. Indeed, "development of<br />
security mechanisms is seen as a key factor in the future growth of<br />
the Internet as a motor for international commerce and communication"<br />
RFC 1984 [RFC1984] and according to the Danvers Doctrine RFC 3365<br />
[RFC3365], there is an overwhelming consensus in the IETF that the<br />
best security should be used and standardized.<br />
<br />
In RFC 1984 [RFC1984], the Internet Architecture Board (IAB) and the<br />
Internet Engineering Steering Group (IESG), the bodies which oversee<br />
architecture and standards for the Internet, expressed: "concern by<br />
the need for increased protection of international commercial<br />
transactions on the Internet, and by the need to offer all Internet<br />
users an adequate degree of privacy." Indeed, the IETF has been<br />
doing a significant job in this area [RFC6973] [RFC7258], considering<br />
privacy concerns as a subset of security concerns. [RFC6973]<br />
Besides privacy, it should be possible to highlight other aspects of<br />
connectivity embedded in standards and protocols that can have human<br />
rights considerations, such as freedom of expression and the right to<br />
association and assembly online. This research is working to develop<br />
a methodology that enables us to extract these considerations.<br />
<br />
=== 2.1. Protocol and Standard Examples ===<br />
<br />
Some initial topics that need exploration are indicated in this<br />
section. Most of this work has yet to move beyond speculation and<br />
casual conversation. Continuing releases of this draft will develop<br />
these foundational discussions further, based on discussions to be<br />
held on the hrpc@article19.io email list and the work of researchers<br />
working on the project.<br />
<br />
==== 2.1.1. Architecture ====<br />
<br />
RFC 1958 [RFC1958] mentions "the community believes that the goal<br />
[of the Internet] is connectivity, the tool is the Internet<br />
Protocol." It continues a bit further: "The current exponential<br />
growth of the network seems to show that connectivity is its own<br />
reward, and is more valuable than any individual application such as<br />
mail or the World-Wide Web." This marks the intrinsic value of<br />
connectivity, which is facilitated by the Internet, both in its<br />
principle, and in practice. This shows that the underlying<br />
principles of the Internet aim to preserve connectivity, which is<br />
fundamental and similar to the part of Article 19 of the Universal<br />
Declaration of Human Rights [UDHR], which defines a right to receive<br />
and to impart information.<br />
<br />
Article 19<br />
<br />
Everyone has the right to freedom of opinion and expression; this<br />
right includes freedom to hold opinions without interference and<br />
to seek, receive and impart information and ideas through any<br />
media and regardless of frontiers.<br />
<br />
==== 2.1.2. Transparency ====<br />
<br />
Another part of Article 19 of the Universal Declaration of Human<br />
Rights [UDHR] mentions that one has the right to hold opinions<br />
_without interference_ (emphasis added). This same sentiment can be<br />
found in IAB RFC4924 [RFC4924] - Reflection on Internet Transparency<br />
where it states: "A network that does not filter or transform the<br />
data that it carries may be said to be transparent" or "oblivious" to<br />
the content of packets. Networks that provide oblivious transport<br />
enable the deployment of new services without requiring changes to<br />
the core. It is this flexibility that is perhaps both the Internet's<br />
most essential characteristic as well as one of the most important<br />
contributors to its success."<br />
<br />
==== 2.1.3. HTTP ====<br />
<br />
Websites made it extremely easy for individuals to publish their<br />
ideas, opinions and thoughts. Never before has the world seen an<br />
infrastructure that made it this easy to share information and ideas<br />
with such a large group of other people. The HTTP architecture and<br />
standards, including RFC 7230 [RFC7230], RFC 7231 [RFC7231], RFC 7232<br />
[RFC7232], RFC 7234 [RFC7234], RFC 7235 [RFC7235], RFC 7236<br />
[RFC7236], and RFC 7327 [RFC7237], are essential for the publishing<br />
of information. The HTTP protocol, therefore, forms an crucial<br />
enabler for freedom of expression, but also for the right to freely<br />
participate in the culture life of the community (Article 27) [UDHR],<br />
to enjoy the arts and to share in scientific advancement and its<br />
benefits.<br />
<br />
==== 2.1.4. Mailing lists ====<br />
<br />
Collaboration and cooperation have been part of the Internet since<br />
its early beginning, one of the instruments of facilitating working<br />
together in groups are mailing lists (as described in RFC 2369<br />
[RFC2919], RFC 2919 [RFC2919], and RFC 6783 [RFC6783]. Mailing lists<br />
are critical instruments and enablers for group communication and<br />
organization, and therefore form early artefacts of the<br />
(standardized) ability of Internet standards to enable the right to<br />
freedom of assembly and association.<br />
<br />
==== 2.1.5. Real time communications ====<br />
<br />
Collaborations and cooperation via the Internet have take a large<br />
step forward with the progress of chat and other other real time<br />
communications protocols. The work on XMPP RFC 6162 [RFC6162] has<br />
enabled new methods of global interactions, cooperation and human<br />
right advocacy. The WebRTC work being done to standardize the API<br />
and protocol elements to support real-time communications for<br />
browsers, mobile applications and IoT by the World Wide Consortium<br />
(W3C) and the IETF is another artefact enabling human rights globally<br />
on the Internet.<br />
<br />
==== 2.1.6. IDNs ====<br />
<br />
English has been the lingua franca of the Internet, but for many<br />
Internet user English is not their first language. To have a true<br />
global Internet, one that serves the whole world, it would need to<br />
reflect the languages of these different communities. The<br />
Internationalized Domain Names IDNA2008 (RFC 5890 [RFC5890], RFC 5891<br />
[RFC5891], RFC 5892 [RFC5892], and RFC 5893 [RFC5893]), describes<br />
standards for the use of a broad range of strings and characters<br />
(some also written from right to left). This enables users who use<br />
other characters than the standard LDH ascii typeset to have their<br />
own URLs. This shows the ambition of the Internet community to<br />
reflect the diversity of users and to be in line with Article 2 of<br />
the Universal Declaration of Human Rights which clearly stipulates<br />
that "everyone is entitles to all rights and freedoms [..], without<br />
distinction of any kind, such as [..] language [..]."[UDHR]<br />
<br />
==<br/> 3. Proposal ==<br />
<br />
To start addressing the issue, a mapping exercise analyzing Internet<br />
architecture and protocols features, vis-a-vis possible impact on<br />
human rights needs is being undertaken.<br />
<br />
As part of the research, interviews will be requested with the<br />
current and past members of the Internet Architecture Board (IAB),<br />
current and past members of the Internet Engineering Steering<br />
Group(IESG) and chairs of selected working groups and RFC authors.<br />
<br />
Mapping the relation between human rights and protocols and<br />
architectures is a new research challenge, which requires a good<br />
amount of cross organizational cooperation to develop a consistent<br />
methodology. While the authors of this first draft are involved in<br />
both human rights advocacy and research on Internet technologies - we<br />
believe that bringing this work into the IRTF facilitates and<br />
improves this work by bringing human rights experts together with the<br />
community of researchers and developers of Internet standards and<br />
technologies.<br />
<br />
Assuming that the research produces useful results, the objective<br />
will evolve into the creation of a set of recommended considerations<br />
for the protection of applicable human rights.<br />
<br />
=== 3.1. Working Assumptions ===<br />
<br />
In the analysis of existing RFCs central design and technical<br />
concepts have been found which impact human rights. These concepts,<br />
working assumptions, will form the lens for the analysis of RFCs and<br />
will be further described vis a vis their impact on human rights.<br />
<br />
The combination of content agnosticism, connectivity, security (as<br />
defined in RFC 3365 [RFC3365] and privacy (as defined in RFC 6973<br />
[RFC6973]) are the technical principles that underlay freedom of<br />
expression on the Internet.<br />
<br />
Privacy and security are defined, so here we focus on concepts that<br />
have not been defined as considerations that are relevant for freedom<br />
of expression.<br />
<br />
This is a first list of concepts, which definitions should be<br />
improved and further aligned with existing RFCs.<br />
<br />
<br />
Connectivity:<br />
<br />
The Internet is the tool for providing global connectivity that<br />
conforms with RFC 1958 [RFC1958]. Therefore all protocols and<br />
standards should aim to improve connectivity, and not to limit it.<br />
<br />
<br />
Distributed:<br />
<br />
To enable and strengthen connectivity, stability, and<br />
sustainability of the network, protocols and standards should be<br />
developed in a way that can be implemented in a distributed way.<br />
<br />
If they are not instrumented in a distributed manner, other<br />
'accountability mechanisms' should be in place. Accountability<br />
mechanisms might include features such as access control, logging<br />
and other protocol management.<br />
<br />
<br />
Inter-operable:<br />
<br />
Standards exist to design systems that allow for other systems to<br />
interact freely and openly.<br />
<br />
<br />
Reliable:<br />
<br />
Reliability ensures that a protocol will execute its function<br />
consistently and error resistant as described and function without<br />
unexpected result. This includes factors such as throughput,<br />
middle boxes, and delay/disruption tolerance. A system that is<br />
reliable degenerates gracefully and will have a documented way to<br />
announce degradation. It will also have mechanisms to recover<br />
from failure.<br />
<br />
<br />
Scalable:<br />
<br />
Any solution should support growth of the network with more hosts,<br />
users and traffic. And have clear definition of its scope and<br />
ideally a proposition how it can be expanded in order to support<br />
greater capacity. Any limits in scalability should be defined.<br />
<br />
<br />
Stateless / state-full:<br />
<br />
If possible protocols should be implemented stateless for<br />
reliability and privacy considerations. If not, they should keep<br />
as little state as possible.<br />
<br />
<br />
Content agnostic:<br />
<br />
Protocols should not treat packets/datagrams differently based on<br />
their content.<br />
<br />
<br />
Transparent:<br />
<br />
Protocols should be transparent in what they can do and can not do<br />
and how it is done.<br />
<br />
<br />
Debugging:<br />
<br />
A protocol should allow a user to troubleshoot and debug possible<br />
causes of malfunction and loss of reliability.<br />
<br />
<br />
Robust:<br />
<br />
Protocols should be resistant to errors, and to involuntary, legal<br />
or malicious attempts to disrupt its mode of operations.<br />
<br />
Protocols should be developed in a way that there is no hidden<br />
back doors or kill switches. There should also be a clear<br />
description on how a protocol recovers from potential failures.<br />
<br />
<br />
End user-centric / representing stakeholder rights:<br />
<br />
As proposed in draft-nottingham-stakeholder-rights-00:<br />
<br />
Protocols MUST document relevant primary stakeholders and their<br />
interrelationships. [..]<br />
End-user-facing application protocols MUST prioritise their<br />
users higher than any other stakeholders.<br />
<br />
<br />
Extensions to existing protocols MUST document how they<br />
interact with the extended protocol's stakeholders. If the<br />
extended protocol's stakeholders are not yet documented, the<br />
extension MAY estimate its impact, in coordination with that<br />
protocol's community and the IESG.<br />
<br />
The burden of this documentation need not be high; if HTML can<br />
do it in a paragraph, so can most protocols. While it might be<br />
appropriate in a separate document (e.g., a requirements or use<br />
cases draft) or the protocol specification itself, documenting<br />
stakeholders in the WG charter has considerable benefits, since<br />
it clarifies their relationships up-front.<br />
<br />
==<br/> 4. Acknowledgements ==<br />
<br />
This builds on work done by RFC 6973 [RFC6973].<br />
<br />
Thanks go to those who have discussed and edited the ideas in this<br />
draft. Special thanks go to Joy Liddicoat as the co-author of<br />
Human Rights and Internet Protocols [HRIP]<br />
<br />
==<br/> 5. IANA Considerations ==<br />
<br />
This memo includes no request to IANA.<br />
<br />
==<br/> 6. Security Considerations ==<br />
<br />
As this draft concerns a research proposal, there are no security<br />
considerations.<br />
<br />
==<br/> 7. References ==<br />
<br />
=== 7.1. Normative References ===<br />
<br />
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate<br />
Requirement Levels", BCP 14, RFC 2119, March 1997.<br />
<br />
<br />
=== 7.2. Informative References ===<br />
<br />
[HRC2011] Human Rights Council, , "Report of the Special Rapporteur<br />
on the promotion and protection of the right to freedom of<br />
opinion and expression, Human Rights Council, May 2011",<br />
2011.<br />
<br />
[HRC2012] General Assembly, UN., "Human Rights Council Resolution on<br />
the promotion, protection and enjoyment of human rights on<br />
the Internet", 2011,<br />
<http://daccess-ods.un.org/TMP/554342.120885849.html>.<br />
<br />
[HRC2013] General Assembly, UN., "Report of the Special Rapporteur<br />
on the promotion and protection of the right to freedom of<br />
opinion and expression, Human Rights Council, April 2013",<br />
2013.<br />
<br />
[HRIP] Joy Liddicoat, JL. and AD. Avri Doria, "Human Rights and<br />
Internet Protocols: Comparing Processes and Principles",<br />
2012,<br />
<https://www.Internetsociety.org/sites/default/files/Human<br />
%20Rights%20and%20Internet%20Protocols-%20Comparing%20Proc<br />
esses%20and%20Principles.pdf>.<br />
<br />
[ICCPR] General Assembly, UN., "International Covenant on Civil<br />
and Political Rights", 1966,<br />
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/<br />
CCPR.aspx>.<br />
<br />
[NETmundial]<br />
NetMundial, , "NETmundial Multistakeholder Statement",<br />
2014, <http://netmundial.br/wp-content/uploads/2014/04/<br />
NETmundial-Multistakeholder-Document.pdf>.<br />
<br />
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",<br />
RFC 1958, June 1996.<br />
<br />
[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG<br />
Statement on Cryptographic Technology and the Internet",<br />
RFC 1984, August 1996.<br />
<br />
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines<br />
and Procedures", BCP 8, RFC 2014, October 1996.<br />
<br />
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax<br />
for Core Mail List Commands and their Transport through<br />
Message Header Fields", RFC 2369, July 1998.<br />
<br />
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,<br />
June 1999.<br />
<br />
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field<br />
and Namespace for the Identification of Mailing Lists",<br />
RFC 2919, March 2001.<br />
<br />
[RFC3365] Schiller, J., "Strong Security Requirements for Internet<br />
Engineering Task Force Standard Protocols", BCP 61, RFC<br />
3365, August 2002.<br />
<br />
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC<br />
Text on Security Considerations", BCP 72, RFC 3552, July<br />
2003.<br />
<br />
[RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board,<br />
"IAB Concerns and Recommendations Regarding Internet<br />
Research and Evolution", RFC 3869, August 2004.<br />
<br />
[RFC4440] Floyd, S., Paxson, V., Falk, A., and IAB, "IAB Thoughts on<br />
the Role of the Internet Research Task Force (IRTF)", RFC<br />
4440, March 2006.<br />
<br />
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet<br />
Transparency", RFC 4924, July 2007.<br />
<br />
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an<br />
IANA Considerations Section in RFCs", BCP 26, RFC 5226,<br />
May 2008.<br />
<br />
[RFC5564] El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman,<br />
"Linguistic Guidelines for the Use of the Arabic Language<br />
in Internet Domains", RFC 5564, February 2010.<br />
<br />
[RFC5890] Klensin, J., "Internationalized Domain Names for<br />
Applications (IDNA): Definitions and Document Framework",<br />
RFC 5890, August 2010.<br />
<br />
[RFC5891] Klensin, J., "Internationalized Domain Names in<br />
Applications (IDNA): Protocol", RFC 5891, August 2010.<br />
<br />
[RFC5892] Faltstrom, P., "The Unicode Code Points and<br />
Internationalized Domain Names for Applications (IDNA)",<br />
RFC 5892, August 2010.<br />
<br />
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for<br />
Internationalized Domain Names for Applications (IDNA)",<br />
RFC 5893, August 2010.<br />
<br />
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic<br />
Message Syntax (CMS) Asymmetric Key Package Content Type",<br />
RFC 6162, April 2011.<br />
<br />
[RFC6783] Levine, J. and R. Gellens, "Mailing Lists and Non-ASCII<br />
Addresses", RFC 6783, November 2012.<br />
<br />
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,<br />
Morris, J., Hansen, M., and R. Smith, "Privacy<br />
Considerations for Internet Protocols", RFC 6973, July<br />
2013.<br />
<br />
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol<br />
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June<br />
2014.<br />
<br />
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol<br />
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.<br />
<br />
[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol<br />
(HTTP/1.1): Conditional Requests", RFC 7232, June 2014.<br />
<br />
[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext<br />
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,<br />
June 2014.<br />
<br />
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext<br />
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June<br />
2014.<br />
<br />
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol<br />
(HTTP/1.1): Authentication", RFC 7235, June 2014.<br />
<br />
[RFC7236] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP)<br />
Authentication Scheme Registrations", RFC 7236, June 2014.<br />
<br />
[RFC7237] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP)<br />
Method Registrations", RFC 7237, June 2014.<br />
<br />
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an<br />
Attack", BCP 188, RFC 7258, May 2014.<br />
<br />
[UDHR] General Assembly, UN., "Universal Declaration of Human<br />
Rights", 1948, <http://www.un.org/en/documents/udhr/index.shtmlhttp://www.ohchr.org/en/udhr/pages/<br />
introduction.aspx>.<br />
<br />
[UNGA2013]<br />
General Assembly, UN., "UN General Assembly Resolution<br />
"The right to privacy in the digital age" (A/C.3/68/<br />
L.45)", 2013,<br />
<http://daccess-ods.un.org/TMP/1133732.05065727.html>.<br />
<br />
<br />
This is a place holder for an Appendix if it is needed.<br />
<br />
== <br/> Authors ==<br />
<br />
:Avri Doria<br />
:dotgay LLC<br />
:Providence<br />
:USA<br />
:Email: avri@acm.org<br />
<br />
:Niels ten Oever<br />
:Article 19<br />
:Netherlands<br />
:Email: niels@article19.org<br />
<br />
:Joana Varon<br />
:Brazil<br />
:Email: joana@varonferraz.com</div>Sysophttp://iuwg.net/index.php/Comments_on_IAB_approved_Dave_Thaler_Draft_on_TransitionComments on IAB approved Dave Thaler Draft on Transition2015-11-07T15:19:23Z<p>Sysop: </p>
<hr />
<div>Over the many years since the introduction of the Internet Protocol,<br />
we have seen a number of transitions, throughout the protocol stack,<br />
from one protocol or technology to another. Many protocols and<br />
technologies were not designed to enable smooth transition to<br />
alternatives or to easily deploy extensions, and thus some<br />
transitions, such as the introduction of IPv6, have been difficult.<br />
<br />
This document attempts to summarize some basic principles to enable<br />
future transitions, and also summarizes what makes for a good<br />
transition plan.<br />
<br />
This Internet-Draft is submitted in full conformance with the<br />
provisions of BCP 78 and BCP 79.<br />
<br />
<br />
__TOC__<br />
<br />
==<br/> 1. Introduction ==<br />
A "transition" is "the process or period of changing from one state<br />
or condition to another. There are several types of such<br />
transitions, including both technical transitions (e.g., changing a<br />
protocol or deploying an extension) and organizational transitions<br />
(e.g., changing what organization manages the IETF web site, or the<br />
RFC production center). This document focuses solely on technical<br />
transitions, although some principles might apply to other types as<br />
well.<br />
<br />
There have been many IETF and IAB RFCs and IAB statements discussing<br />
transitions of various sorts. Most are protocol-specific documents<br />
about specific transitions. For example, some relevant ones in which<br />
the IAB has been involved include:<br />
<br />
* IAB RFC 3424 [RFC3424] recommended that any technology for so- called "unilateral self-address fixing (UNSAF)" across NATs include an exit strategy/plan to transition away from such a mechanism. Since the IESG, not the IAB, approves IETF documents, the IESG thus became the body to enforce (or not) such a requirement. <br />
* IAB RFC 4690 [RFC4690] gave recommendations around internationalized domain names. It discussed issues around the process of transitioning to new versions of Unicode, and this resulted in the creation of the IETF Precis WG to address this problem. <br />
* The IAB statement on "Follow-up-work on NAT-PT" [IabIpv6TransitionStatement] pointed out gaps at the time in transitioning to IPv6, and this resulted in the rechartering of the IETF Behave WG to solve this problem. <br />
More recently, the IAB has done work on more generally applicable<br />
principles, including two RFCs.<br />
<br />
IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?"<br />
studied specifically what factors contribute to, and detract from,<br />
the success of a protocol and it made a number of recommendations.<br />
<br />
It discussed two types of transitions: "initial success" (the<br />
transition to the technology) and extensibility (the transition to<br />
updated versions of it). The principles and recommendations in that<br />
document are generally applicable to all technical transitions. Some<br />
important principles included:<br />
<br />
1. Incentive: Transition is easiest when the benefits come to those bearing the costs. That is, the benefits should outweigh the costs at *each* entity. Some successful cases did this by providing incentives (e.g., tax breaks), or by reducing costs (e.g., freely available source), or by imposing costs of not transitioning (e.g., regulation), or even by narrowing the scenarios of applicability to just the cases where benefits do outweigh costs.<br />
<br />
2. Incremental Deployability: Backwards compatibility makes transition easier. Furthermore, transition is easiest when changing only one entity still benefits that entity. In the easiest case, the benefit immediately outweighs the cost and so entities are naturally incented to transition. More commonly, the benefits only outweigh the costs once a significant number of other entities also transition. Unfortunately, in such cases, the natural incentive is often to delay transitioning.<br />
<br />
3. Total Cost: Don't underestimate the cost of things other than the hardware/software itself. For example, operational tools and processes, personnel training, business model (accounting/billing) dependencies, and legal (regulation, patents, etc.) costs all add up.<br />
<br />
4. Extensibility: Design for extensibility so that things can be fixed up later.<br />
<br />
IAB RFC 7305 [RFC7305] reported on a IAB workshop on Internet<br />
Technology Adoption and Transition (ITAT). Like RFC 5218, this<br />
workshop also discussed economic aspects of transition, not just<br />
technical aspects. Some important observations included:<br />
<br />
1. Early-Adopter Incentives: Part of Bitcoin's strategy was extra incentives for early adopters. That is, providing a long-term advantage to early adopters can help stimulate transition even when the initial costs outweigh the initial benefit.<br />
<br />
2. Policy Partners: Policy-making organizations of various sorts (RIRs, ICANN, etc.) can be important partners in enabling and facilitating transition.<br />
<br />
The remainder of this document continues the discussion in those two<br />
RFCs and provides some additional thoughts on the topic of transition<br />
strategies and plans.<br />
<br />
==<br/> 2. Transition vs. Co-existence ==<br />
We need to distinguish between a strict "flag-day" style transition<br />
where an old mechanism is immediately replaced with a new mechanism,<br />
vs. a looser co-existence based approach where transition proceeds in<br />
stages where a new mechanism is first added alongside an existing one<br />
for some overlap period, and then the old mechanism is removed at a<br />
later stage.<br />
<br />
When a new mechanism is backwards compatible with an existing<br />
mechanism, transition is easiest, and the difference between the two<br />
types of transition is not particularly significant. However, when<br />
no backwards compatibility exists (such as in the IPv4 to IPv6<br />
transition), a transition plan must choose either a "flag day" or a<br />
period of co-existence. When a large number of entities are<br />
involved, a flag day becomes impractical. Coexistence, on the other<br />
hand, involves additional costs of maintaining two separate<br />
mechanisms during the overlap period which could be quite long.<br />
<br />
Furthermore, the longer the overlap period, the more the old<br />
mechanism might get further deployment and thus increase the overall<br />
pain of transition.<br />
<br />
Often the decision between a "flag day" and a sustained co-existence<br />
period may be difficult, such as in the case of IDNA2008 [RFC5891]<br />
[RFC5895] and Unicode TR46 [TR46].<br />
<br />
==<br/> 3. Translation/Adaptation Location ==<br />
A translation or adaptation layer is often required if the old and<br />
new mechanisms are not interoperable. Care must be taken when<br />
determining where such a translator is best placed.<br />
<br />
Requiring a translator in the middle of the path can hamper end-to-<br />
end security and reliability. For example, see the discussion of<br />
network-based filtering in [I-D.iab-filtering-considerations].<br />
<br />
On the other hand, requiring a translation layer within an endpoint<br />
can be a resource issue in some cases, such as if the endpoint could<br />
be a constrained node [RFC7228].<br />
<br />
Any transition strategy for a non-backward-compatible mechanism<br />
should include a discussion of where it is placed and a rationale.<br />
<br />
==<br/> 4. Translation Plans ==<br />
A good transition plan includes at least the following components:<br />
<br />
1. An explanation of incentives for each entity involved<br />
2. A description of transition phases. For example, there might be pilot, co-existence, deprecation, and removal phases, for a transition from one technology to another incompatible one.<br />
<br />
3. A proposed timeline<br />
4. A way to effectively communicate the proposed plan to the entities affected, and incorporate their feedback<br />
<br />
==<br/> 5. Security Considerations ==<br />
This document discusses attributes of protocol transitions. Some<br />
types of transition can adversely affect security or privacy. For<br />
example, requiring a translator in the middle of the path may hamper<br />
end-to-end security and privacy, since it creates an attractive<br />
target. For further discussion of some of these issues, see<br />
Section 5 of [I-D.iab-filtering-considerations].<br />
<br />
==<br/> 6. IANA Considerations ==<br />
This document requires no actions by the IANA.<br />
<br />
==<br/> 7. Informative References ==<br />
[I-D.iab-filtering-considerations]<br />
Barnes, R., Cooper, A., Kolkman, O., and D. Thaler,<br />
"Technical Considerations for Internet Service Blocking<br />
and Filtering", draft-iab-filtering-considerations-07<br />
(work in progress), July 2015.<br />
<br />
[IabIpv6TransitionStatement]<br />
IAB, "Follow-up work on NAT-PT", October 2007,<br />
<https://www.iab.org/documents/correspondence-reports-<br />
documents/docs2007/follow-up-work-on-nat-pt//>.<br />
<br />
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for<br />
UNilateral Self-Address Fixing (UNSAF) Across Network<br />
Address Translation", RFC 3424, DOI 10.17487/RFC3424,<br />
November 2002, <http://www.rfc-editor.org/info/rfc3424>.<br />
<br />
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and<br />
Recommendations for Internationalized Domain Names<br />
(IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,<br />
<http://www.rfc-editor.org/info/rfc4690>.<br />
<br />
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful<br />
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,<br />
<http://www.rfc-editor.org/info/rfc5218>.<br />
<br />
[RFC5891] Klensin, J., "Internationalized Domain Names in<br />
Applications (IDNA): Protocol", RFC 5891,<br />
DOI 10.17487/RFC5891, August 2010,<br />
<http://www.rfc-editor.org/info/rfc5891>.<br />
<br />
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for<br />
Internationalized Domain Names in Applications (IDNA)<br />
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,<br />
<http://www.rfc-editor.org/info/rfc5895>.<br />
<br />
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for<br />
Constrained-Node Networks", RFC 7228,<br />
DOI 10.17487/RFC7228, May 2014,<br />
<http://www.rfc-editor.org/info/rfc7228>.<br />
<br />
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet<br />
Technology Adoption and Transition (ITAT)", RFC 7305,<br />
DOI 10.17487/RFC7305, July 2014,<br />
<http://www.rfc-editor.org/info/rfc7305>.<br />
<br />
[TR46] Unicode Consortium, "Unicode IDNA Compatibility<br />
Processing", June 2015,<br />
<http://www.unicode.org/reports/tr46/>.</div>Sysophttp://iuwg.net/index.php/IAB/IETF_Global_Community_ReferencesIAB/IETF Global Community References2015-11-07T15:16:37Z<p>Sysop: Created page with " * Comments on IAB approved Dave Thaler Draft on Transition"</p>
<hr />
<div><br />
* [[Comments on IAB approved Dave Thaler Draft on Transition]]</div>Sysophttp://iuwg.net/index.php/Consensus_declared_--_IETF_IANAPLAN_WG_input_to_the_ICG_request_for_commentsConsensus declared -- IETF IANAPLAN WG input to the ICG request for comments2015-09-15T16:40:38Z<p>Sysop: Created page with "== Date: Mon, 31 Aug 2015 09:18:34 Leslie Daigle Co-Chair IETF/WG/IANAPLAN == Thanks, all, for the engaged discussion and suggestions to follow up the IANAPLAN virtual inter..."</p>
<hr />
<div>== Date: Mon, 31 Aug 2015 09:18:34 Leslie Daigle Co-Chair IETF/WG/IANAPLAN ==<br />
<br />
<br />
Thanks, all, for the engaged discussion and suggestions to follow up the IANAPLAN virtual interim meeting and proposed response to the ICG request for comments on the combined IANA transition proposal. We are declaring consensus on the following text (same as I last shared, copied for ease of reference):<br />
<br />
<br />
The IETF IANAPLAN WG has reviewed the draft ICG proposal within the context of the WG’s charter — specifically, “Should proposals made by other communities regarding the transition of other IANA functions affect the IETF protocol parameter registries or the IETF, the WG may also review and comment on them.” The IETF IANAPLAN working group continues to believe that a transition away from a US Government role in IANA management and oversight is appropriate and confirms consensus of its participants that the draft proposal is not perceived to pose problems for the Protocol Parameters function or to interfere with the development or safe use of IETF standards. The IETF raised two transition points that are mentioned in Paragraph 3062 of the proposal. We would ask that they be referenced in Part 0, Section V of the proposal as well.<br />
<br />
Leslie.<br />
<br />
== Fri, 04 Sep 2015 12:34:16 JFC Morfin == <br />
<br />
Dear Leslie,<br />
<br />
This position of yours seems reasonable within the new IETF framework. It definitely splits the world's catenet technical and political use between at least the ICANN and XLIBRE (http://xlibre.net) RFC 6852 Global Communities. Two very different sizes and spirits now. It is reasonable to also foresee further governance reorganizations involving Europe, BRICs, and GAFAM virtual global network communities. I, therefore, consider that my hope of seeing an organized/agreed sustainable cooperative settlement reached through the appeal process has come to its expectable conclusion, but I had to give it a try.<br />
<br />
I will, therefore, not appeal the ISOC board of trustees.<br />
<br />
The difficulty now is to keep the catenet use stable and coopetitive enough to avoid technical conflicts as well as to prevent the pollution of the digktynet (the digisphere global network system : http://digkty.net) that some of us identify as the general area of interest for the informed users and Libre researchers.<br />
<br />
We certainly favor a permissionless "intertest" charter for all the Global Communities to jointly agree on live experimentation terms and mutual reporting. We consider that the Section 5 - Experimentation of the ICANN ICP-3 document as a good initial working basis. The work carried out by Brian Carpenter in a past I_D could also be used.<br />
<br />
One of our focuses in the coming months might be R&D concerning DDDS in conjunction with the DNS protocols and how this could lead to an open repository system of reference for the different Global Communities and their network technology coopetition: the home-root and super-IANA “plug-in".<br />
<br />
Best regards,<br />
<br />
jfcm</div>Sysophttp://iuwg.net/index.php/The_36_questionsThe 36 questions2015-06-22T19:20:59Z<p>Sysop: Created page with "The list of the 36 questions of the IESG/IAB appeal are gathered here for common convenience ;Question 01: Does this IETF consensus imply that the IETF wants to focus on the..."</p>
<hr />
<div>The list of the 36 questions of the IESG/IAB appeal are gathered here for common convenience <br />
<br />
;Question 01: Does this IETF consensus imply that the IETF wants to focus on the practical details of its IANA contract to ICANN rather than on the overall stability of its technology in an ICANN context, meaning it relies on ICANN expertise to best organize and lead the internet multistakeholder governance? <br />
<br />
;Question 02: Does this IETF consensus imply that the IETF is first committed to the ICANN scenario although it seems to differ with the NTIA announced one? <br />
<br />
;Question 03: Does this IETF consensus imply that in terms of evaluating the consequence of the NTIA Transition the IAB considers that only functional engineering aspects are impacted and that no architectonic concerns are to be considered that might have architectural consequences are to be investigated and discussed? <br />
<br />
;Question 04: Would this not call for some consideration when the intent is to transfer 40 years of US sovereign oversight on a NSA-compatible world key technology considered as quasiproprietary (cf. President Obama) to a multiple stakeholder undefined system animated by an objected non-profit, non-member corporation. <br />
<br />
;Question 05: Does this IETF consensus imply that the IAB does not want to affirm its control of the “.arpa” top-zone and its “iana” domain name as a catenet information center of reference for its internet technology? <br />
<br />
;Question 06: Does this IETF consensus imply that the ICANN vision supersedes the NTIA announcement or is it a stand-by position while a new “supply/demand” consensus develops over the multiplural catenet governance or an intrinsic permanent consensus of the IETF? <br />
<br />
;Question 07: In the same way, does it means that the IETF implements the RFC 6852 paradigm as the proper principles for interoperable “permissionless innovations” by other “Global Communities”? <br />
<br />
;Question 08: Does this IETF consensus imply that the IETF does not consider having a part in any manner to the internet naming space, and fully delegates its management to ICANN? <br />
<br />
;Question 09: In case of conflict with the IANA operator, will IETF/IAB ask VeriSign for the protection of its “.arpa” zone resolution? <br />
<br />
;Question 10: Does the IETF consensus imply that there is no need for an IANA protocol to help the documentation community consistently document a situation where permissionless innovation and technical orientations will be the sole market influence on standard adoption? <br />
<br />
;Question 11: Or does it consider that the documentation sub-communities (in each RFC 6852 global community) should be free to present and adapt the IETF requests for comments in the way they consider as most appropriate for/within their global community (i.e. national, operating system, market, edge provider, Libre, etc. communities)? <br />
<br />
;Question 12: Does the IETF consensus imply that there is no need for ICANN and the NTIA to consider any possible impact from a larger use of the DNS built-in reentrant CLASS system that enables thousands of roots to safely coexist (as reminded in the ICANN Internet Coordination Policy # 3 [ICP-3])? <br />
<br />
;Question 13: I must say that I share this opinion, but prefer to follow the ICP-3 precautions in terms of experimentation and prepare a second ICP-3 conformant live testing (further to my previous “dot-root” community test-bed) concerning CLASS “FL” (Free/Libre) to be both supported by a root system and an “HomeRoot” use. Am I over-precautionary in such a permissionless simple application of RFCs? <br />
<br />
;Question 14: Does the IETF consensus imply that there is no need to consider: ? a possible divergence between RIR and the IETF, for example in a case leading to a change of the IANA operator? ? a non-IETF permissionless innovation introducing another numbering scheme? <br />
<br />
;Question 15: Does the IETF consensus imply that there is no specific policy development to consider in case ICANN undertakes to support other global community equivalents to the IANA or sponsors development by an emerging documentation community? <br />
<br />
;Question 16: Does the IETF consensus silence on the points that the (US) Law remains the only arbitrator in terms of community dissensus imply that there is no specific policy development requirement to consider in this area? <br />
<br />
;Question 17: Does the IETF consensus silence on the IETF Trust copyrights imply a tacit agreement of this consequence? <br />
<br />
;Question 18: Does the IETF consensus imply that the IAB is no longer considering undertaking its responsibilities in the NTIA organized cross-accountability framework IAB/ICANN through the delegation of the “iana.arpa” sources to the “iana.org” service? <br />
<br />
;Question 19: Does the IETF consensus silence on the ICANN accountability framework imply a tacit agreement of this consequence? <br />
<br />
;Question 20: Does the IETF consensus mean that the IETF considers that ICANN is only accountable to the IAB/IETF for the publishing of the protocol parameters? <br />
<br />
;Question 21: Does the IETF consensus silence on its announced obedience to the NTIA imply a tacit indication that this subjection to the IANA is a one shot case? <br />
<br />
;Question 22: In the absence of an indication in the appealed Draft of an internal IETF procedure concerning the very decision to change the IANA operator (see below), it seems that it will simply call for an IAB consensus (or vote, since votes are sometimes used at the IETF) that can be appealed to ISOC and disputed in US Courts. Is that correct? <br />
<br />
;Question 23: Does the IETF consensus silence on this point imply a tacit indication that this would not be a problem for the IETF? This is important for other communities shopping for their own registries operator. <br />
<br />
;Question 24: Does this IETF response imply that the IETF considers that any jurisdiction, anywhere in the world, is valid in case of the misbehavior of the IANA operator? <br />
<br />
;Question 25: Why has no international legal expert panel been requested to assist the WG review of this text? <br />
<br />
;Question 26: Does this IETF response imply that the IETF considers that the transition will: ? not modify the global technological context of the digisphere? ? or that the momentum of the current practice will last forever regardless of the permissionless innovations that may happen? <br />
<br />
;Question 27: Does the IETF consensus imply that it considers that external permissionless innovation will not necessitate its IANA operator’s requirements to adapt? <br />
<br />
;Question 28: Who is a stakeholder in the IETF parlance? What is the eventual conclusion on the IETF “Paywall” issue? <br />
<br />
;Question 29: What is the IETF position regarding the omnistakeholder vision, considering how it is difficult to gather abstainers, but that they also make the bulk of the users multitude and eventually also make the changes and revolutions? <br />
<br />
;Question 30: Does this IETF response imply that the IETF considers that there is no procedural need to protect the exchanges with the IANA systems, and that they are possibly immune from exploits? <br />
<br />
;Question 31: Does this IETF response imply that the IETF considers that there is no IANA services stress test or an evaluation period under their new governance circumstances? <br />
<br />
;Question 32: Does this IETF consensus imply that the IETF considers the internet technology to be now mature enough to be immune from multiplural permissionless innovations using the Catenet reentrance? <br />
<br />
;Question 33: Does this IETF consensus imply that the IETF estimates that it has sufficiently considered the pragmatic credibility of the NTIA scenario and does not expect to have to carry out periodic reviews of the general catenet architecture and of the architectonic practices? <br />
<br />
;Question 34: Does this IETF consensus as it is worded imply that the IETF does not consider that it would need to set-up a permanent mailing list among the OpenStand signatories and endorsers, extended to Libre, IUsers, Governments and industry community for everyone to be kept abreast of the ongoing permissionless innovation? <br />
<br />
;Question 35: The consensus does exist, but it is by the IETF "affinity group". I myself, and most probably others, need more clues to understand what to do with it. This is why I have listed the Questions that are needed for RFC.3774-affinity-group non-members to understand what it means. Would there be additional points that should be addressed in such a perspective? <br />
<br />
;Question 36: This Question is a practical summary of the consequences of the IETF consensual position: is there a problem for the “Relationnels Libres” community to operate an information service at “iana.zone” and further on an adequate TLD of the “FL” (Free/libre) CLASS (see above)?</div>Sysophttp://iuwg.net/index.php/20150530_-_I*Chairs_report20150530 - I*Chairs report2015-05-01T14:08:48Z<p>Sysop: Created page with "Dear colleagues, This is an update to the community on the current discussion between the IETF and ICANN regarding the annual SLA or Supplemental Agreement. Each year, the IE..."</p>
<hr />
<div>Dear colleagues,<br />
<br />
This is an update to the community on the current discussion between<br />
the IETF and ICANN regarding the annual SLA or Supplemental Agreement.<br />
Each year, the IETF (via the IAOC) and ICANN specify a supplemental<br />
agreement to our Memorandum of Understanding, in order to ensure that<br />
any gaps or identified operational issues are addressed.<br />
<br />
As you are aware, inspired by the request from the IANA Stewardship<br />
Transition Coordination Group (ICG), last year we formed the IANAPLAN<br />
working group and achieved IETF consensus on the state of affairs with<br />
IANA registries published under the direction of the IETF. That<br />
consensus is captured in draft-ietf-ianaplan-icg-response-09, which was<br />
transmitted to the ICG. In that document the community sought to have<br />
some facts acknowledged as part of any IANA transition plan:<br />
<br />
* The protocol parameters registries are in the public domain. It is the preference of the IETF community that all relevant parties acknowledge that fact as part of the transition.<br />
<br />
* It is possible in the future that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledge that it will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition to subsequent operator(s), should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use the protocol parameters registries or other resources currently located at iana.org.<br />
<br />
Understanding this consensus, the IETF leadership have been negotiating with ICANN to include text to satisfy these points in our annual Service Level Agreement. After some iterations, we arrived at text that we think captures the IETF consensus, but ICANN has informed us that they are unable to agree to that text right now. ICANN told us that, in their opinion, agreeing to that text now would possibly put them in breach of their existing agreement with the NTIA.<br />
<br />
It is our view that the substance of the statements above is already part of our agreement with ICANN, and that we are merely elaborating details of that existing agreement. We expect that as we continue towards the orderly winding down of NTIA's involvement in the IANA processes, our existing arrangements will be preserved, in keeping with IETF consensus.<br />
<br />
We will of course continue to assess the situation, agreements, and next steps, as well as developments in other operational communities. We think that the existing agreement between ICANN and the IETF makes good sense, and is good for the Internet. The IETF has stated very strongly that it supports that existing agreement. That strong support is a necessary condition for success, and we shall not waver in our commitment to the IETF's continued responsible stewardship of the protocol parameters registries.<br />
<br />
We note that the IETF community remains very satisfied with ICANN's current level of performance. The existing supplemental agreement, from last year, continues until it is replaced.<br />
<br />
We welcome your thoughts about this situation. We will continue to use the IANAPLAN mailing list for these discussions.<br />
<br />
Best regards,<br />
<br />
Jari Arkko - IETF Chair<br />
<br />
Tobias Gondrom - IAOC Chair<br />
<br />
Andrew Sullivan - IAB Chair</div>Sysophttp://iuwg.net/index.php/20150424_-_JFCM%27s_Response_to_Seun_Odjedji_and_Andrew_Sullivan20150424 - JFCM's Response to Seun Odjedji and Andrew Sullivan2015-04-26T22:34:31Z<p>Sysop: Created page with "==== At 16:07 24/04/2015, Seun Ojedeji wrote: ==== ''Hi Jefsey,<br/> ''I understand its a proposal by the names community only and not the ICG proposal'' Interesting how the..."</p>
<hr />
<div>==== At 16:07 24/04/2015, Seun Ojedeji wrote: ====<br />
<br />
''Hi Jefsey,<br/><br />
''I understand its a proposal by the names community only and not the ICG proposal''<br />
<br />
Interesting how there is no mention of the OIO relations. (Other IANA Operators).<br/><br />
jfc<br />
<br />
<br />
==== At 16:08 24/04/2015, Andrew Sullivan wrote: ====<br />
<br />
''I'm not sure what you mean, but if you mean other registries for protocol parameters I'd expect that to be out of scope for the names community.<br />
<br />
''What other IANA operators are there for the names community?''<br />
<br />
<br />
My point is addressed in the questions of my appeal the IESG has not considered necessary to address. What I consider as increasingly disturbing and whish to see approched in the best manner (I try to adopt a median position acceptable to most) in my IAB appeal.<br />
<br />
Let say that, independently from the political bargains that commands the transition plan, I wish to keep as stable internet for every of us, however it is likely it will not be the same one (because - cf. RFC 6852 - it will include at least two "global community" coalitions : those who consider they are bound by NTIA and FCC positions/decisions and those who dont).<br />
<br />
Each of these coalitions will necessary have a few (hopefully) different visions. This will translate into the need for them to have their own version of the IANA. One should be managed as an ICANN affiliate and the other is still open. IMHO two other ones would make sense: one by ITU and one by the Libre. (I purposely use the term Libre, and "Relationnels Libres" in French to make clear it is not the open source, but an open network approach which corresponds to the Vint Cerf IEN 48 objective second montivation. This ICANN(PTI)/ITU/Libre IANA Operators would represent the states (ITU), business (ICANN) and civil society (Libre) approches and permit some of the multistakeholderism both NTIA and ITU desire. I suppose that the Libre community is young enough for accepting that its desired omnistakeholderism can be delayed, as long as this is the way it will internally proceed.<br />
<br />
This scheme, as eventually devised by Vint in July 1978, is the one I engaged into in 1977 with Tymnet and some European PTT and the French government plan (Transpac and Minitel) prevented us to merge with Louis Pouzin's Cyclade. So, my interest is in making sure that - whatever the States (US, Europe, BRICS) may do, negociate, fight, etc. the civil society may keep a stable service eith from PTI and/or from Libre, as I tested it through the Dot-Root community project (along ICANN still valide ICP/3 testing terms) 13 years ago. <br />
<br />
The scheme I campaign for - and this is why I stayed with the IETF for all these years, as well as opposing some of the Unicode consortium influence, (while most of the Libre and State oriented people did not) - is one I think acceptable on both sides and possibly also on the third one (if ITU is to enter the game). It could even accomodate more new commers (probably a small galaxy of them if people feel it is not correctly planned). It is the experimentation scheme, along ICANN experimentation rules. Permissionless innovation/projects as long as they keep being experimental first.<br />
<br />
In here, and in my appeal, I made clear that I will experiment the DNS CLASS "FL" (for Free/Libre) along with the principles documented by the DNSA. So far, this makes little difference with the IANA PTI Version, but it will help keeping peacefull the varions CLASS "IN" backup solutions and the support of the various "MYCANN" configurations or plug-ins. IMHO, if they do not foresee some fighting, many would be candidate will drop interest.<br />
<br />
Obviously the most significant jurisdictionnal disagreements or extensions will probably happen in the naming area. This is why I think the ICANN "name community" is the predominant contributor, also because ICANN is perceived as the name-space commercial hijacker by many States and Civil/Local society members. And eventually because it is the sole interlocutor the NTIA considers in its announcement. The NTIA only considers the DNS. ICANN considers the IANA. <br />
<br />
It will also be a way to test ICANN. If it will considers its peers as equals; and if it wants or do not want to respect a multistakeholder approach for itself, or it considers that the TLDs and RIRs are the stakeholders, and it is itself the Queen of Borgs.<br />
<br />
All this is in five months now.<br/><br />
jfc<br />
<br />
<br />
==== At 20:05 24/04/2015, Andrew Sullivan wrote: ====<br />
'' You have not, unless I have overlooked something important, actually yet filed an appeal with the IAB. Right? That is, you have stated an intention to appeal, but haven't filed it. (You talk of "my IAB appeal", but I presume that you just elided the "forthcoming" or something like that.)''<br />
<br />
<br />
Right. As I say I wish to see the point correctly presented in this text under preparation. i.e. to make sure that those who whish to help me, help me in a proper direction.<br />
<br />
<br />
As per RFC 2026 I understand I had to focus on the way the IESG accepted a text that is unclear in spite of my contributions during the WG and according to the Charter; In the appeal to the IAB I understand I am to focus on the way the lack of response of the IESG puts the whole technology at risk of jeopardy. And in a possible apeal to ISOC on the way the appeal system itself, in this specific case, could be insufficient to protect the interest of the community.<br />
<br />
<br />
Nothing more.<br/><br />
Thank you for your care.<br/><br />
jfc</div>Sysophttp://iuwg.net/index.php/20150418_-_Lettre_aux_parlementaires20150418 - Lettre aux parlementaires2015-04-18T18:26:53Z<p>Sysop: </p>
<hr />
<div><br />
<br />
<br />
<big><big><big>'''''Lettre aux représentants de la Nation'''''</big></big></big><br />
<br />
<br />
Je vous écris au sujet de la loi sur la surveillance et sur l’avancée importante du Président Hollande qui est soucieux de la soumettre au Conseil Constitutionnel, ce qui est bien puisque, à mes yeux, elle réclame de s'appuyer sur une loi organique encore absente.<br />
<br />
Cette loi est bien entendu nécessaire, mais les domaines de l’information, de la communication et de l’intellition (c’est à dire de l’information calculée) qu’elle traite ne sont que très partiellement évoqués par la Constitution (sauf dans la Charte de l’Environnement) et les engagements internationaux de la France (sauf lors des conclusions et engagements du Sommet Mondial sur la Société de l’Information de Tunis, 2005).<br />
<br />
Elle déclenche donc un débat sur la souveraineté digitale et la sécurité numérique de la France et de chacun, un sommet mondial ayant montré et retenu que la Société de l’Information, le nom ainsi donné à notre société « anthropobotique » actuelle (faites d'hommes et de plus en plus processus digitaux autonomes), était un tripartenariat entre le régalien, le citoyen et le secteur privé. C’est ce changement sociétal majeur que, sous la pression des circonstances, nous devons aborder sans préparation et au sujet duquel vous avez à légiférer en urgence. <br />
<br />
Nous savons tous que ce n’est pas possible, pour une raison d’expérience comparable. C’est celle de la révolution industrielle, c'est-à-dire de l’introduction de la facilitation technique à l’industrie humaine : nous en avons vu les effets politiques, historiques, économiques, constitutionnels et culturels sur plusieurs siècles. <br />
<br />
Nous sommes aujourd’hui engagés dans plus encore : la facilitation technique du penser humain. Les Américains appellent cela la « singularité technologique », ce qui - pour leur école de pensée californienne - va même jusqu’au « post-humain » ! Certes, il nous faut raison et maîtrise garder, mais le domaine est majeur.<br />
<br />
Cette maîtrise va sans doute nous demander des décennies voire des siècles à établir. Le point important est que nos tentatives ne nous bloquent pas et que nos rigidités n’avantagent pas nos coopétiteurs politiques (US/BRICS) et industriels, non plus que nos ennemis, à commencer par les terroristes capables de manipuler nos faux pas. J’ai été bloqué en 1986 parce que, au sein de l'entreprise catalysatrice mondiale de l’internet d’alors, mes projets n’étaient pas « NSA-compatible » aux yeux du militaro-industriel américain ; tandis que mes collègues ou maîtres à penser, dans certains aspects, de l’IRIA, de la CII et du CNET, étaient bloqués de même.<br />
<br />
Depuis quarante ans, le développement de l’écosystème digital au service de la numérisation des espaces relationnels humains et industriels nous a appris des principes d’expérience qu’il faut maintenant porter dans la loi et sans doute, ensuite, dans la Constitution. Parmi ces principes :<br />
<br />
* La Constitution du digital est dans le code source.<br />
* Les grands systèmes complexes sont faits de simplicités.<br />
* Tout algorithme peut être faux, sa validation est dans le « running code » et le « living mode »<br />
* L’on doit être conservateur dans ce que l’on envoie et ouvert dans ce que l’on reçoit.<br />
* Ce qui est (donnée), ce que l’on reçoit (captée), ce que l’on consolide (traitée) est différent.<br />
<br />
La loi sur la surveillance est l’algorithme (c'est-à-dire la recette de base). Cet algorithme dit « pour trouver les terroristes utiliser des boîtes noires ». Les instructions algorithmiques complémentaires viendront par décrets, circulaires, et réponses à appels d’offres.<br />
<br />
<br />
Nous, '''Français''', avons besoin d’une Doctrine nationale du digital. C’est ce que demande le M. le Sénateur Bockel. Nous avons déjà une avance constitutionnelle significative :<br />
<br />
* La charte de l’Environnement en établit des principes fondamentaux, car la digisphère est une des sphères environnementales de l’homme.<br />
* C’est ce que la Livre Blanc sur la Défense a bien établi au sujet du cyberespace comme un théâtre d’opérations comme la Terre, la Mer, l’Air et l’Espace proche. <br />
<br />
<br />
Nous, '''militaires''', avons à capitaliser sur l'évolution stratégique et polémologique du siècle dernier où nous avons appris la notion de pacification postérieure aux combats, que nous avons maintenant à généraliser à celle de contre-guerre de précaution à une guerre possible ou à sa reprise. Les standardisateurs vivent déjà au quotidien une contre-guerre globale à l'établissement de normes biaisées, origine probable de conflits futurs. Ainsi nous ne faisons pas la guerre au terrorisme, mais la guerre aux terroristes et une contre-guerre au terrorisme. Une solution organique possible à la demande de l'Etat et des Services est l'étude d'un "état de précaution" pouvant être sectoriellement déclanché (et des forces de précaution pouvant être activées) dans les différents domaines de responsabilité régalienne, et en particulier, ici, dans le domaine digital. Car enfin ce qui vous est demandé est de codifier un plan "Digipirate".<br />
<br />
<br />
Nous, '''chercheurs et professionnels''', avons dans un souci constitutionnel de défense nationale et de précaution citoyenne, à rechercher les bugs de votre algorithme et à les soumettre : pour cela il faut que vous ayez établi une instance pour nous répondre. Sinon, nous devrons faire en sorte d’être assignés en Justice pour nous permettre de soulever les QPC nécessaires. C’est ce que nous avions prévu de faire si le Président de la République n’avait pas engagé le débat constitutionnel du Digital.<br />
<br />
<br />
Il importe sans doute au seuil de ce débat de clarifier trois choses :<br />
<br />
*Ne pas confondre avec l’Académie française le digital et le numérique. La consultation de Wikipédia peut y aider. Le numérique c’est Euclide : entre deux points il y a une infinité de points. Le digital ce sont les pixels, entre eux il y a rien. C’est l’intelligence ajoutée qui apporte la continuité, mais cette intelligence peut être trompée par l’illusion. Un eillusion que Hollywood et les média ont transformé en industrie. Et que Clearstream nous a montré être une arme politique.<br />
<br />
* présomption algorithmique de culpabilité », lorsque la machine se trompe et nous donne l’illusion de la certitude probatoire d’une prévision. C’est sans doute possible, mais c’est un chemin fondamentalement nouveau.<br />
<br />
* Nous sommes actuellement engagés dans une très grande manœuvre américaine pour transformer au 30 septembre 2015, son protectorat sur l’internet mondial (à travers la supervision depuis 1998 de l’ICANN par le NTIA, agence de télécommunication de l’Exécutif) en colonisation de l’écosystème digital mondial dont la gouvernance serait assurée par l’ICANN, donc sous juridiction américaine et coordination de la FCC. <br />
<br />
Ceci est une réponse à la fois au vote qu’ils ont perdu lors du renouvellement du Traité Mondial des Télécommunications et de l’évolution des technologies qui fait que le « catenet », c'est-à-dire le « réseau des réseaux » de Louis Pouzin n’est plus destiné à être une chasse gardée de la seule technologie de l’IETF (l’organisation de standardisation de l’internet). L’IETF vient de décider que son ultime référent est le NTIA. J’ai fait appel en première instance de cette position, car les appels doivent être individuels. En seconde instance je peux élargir ma base de questions, mais je suis en l’absence de doctrine régalienne en la matière et vais donc devoir continuer à m’en tenir à une doctrine que j’essaie d’établir sous le nom de « Relationnels Libres ».<br />
<br />
C’est un exemple de la nécessité du débat que le Président de la République a ouvert à l’occasion de la loi sur la surveillance.<br />
<br />
Pour conclure, ce dernier exemple, comme les préoccupations terroristes, comme les analyses qu’il va falloir engager pour écrire, valider et opérer les algorithmes complémentaires à l’algorithme de la loi, dans le cade des algorithmes constitutionnels, des Droits de l’Homme et de la Charte de l’Environnement, montrent que nous sommes dans une vision complémentaire nouvelle de la réalité qui nous permet d’aller plus loin, vis-à-vis de phénomènes nouveaux. La science pour traiter cela est l’'''architectonique''' dont son concepteur, Aristote, disait qu’elle était, en tant que '''discipline''' de la compréhension de la réalité, la '''science''' de la politique dont l’'''art''' était de conduire la société des hommes libres. <br />
<br />
La différence est que nous avons digitalement et intelligemment '''interconnecté''' ces hommes libres, sans bien savoir encore si ces liens les asservissent ou en étendent les capacités. C’est à vous de nous le dire.<br />
<br />
Sincèrement votre,<br />
<br />
''JFC Morfin<br/><br />
''Facilitateur, IUWG.''</div>Sysophttp://iuwg.net/index.php/20150416_-_R%C3%A9ponse_de_l%27IESG20150416 - Réponse de l'IESG2015-04-18T13:27:47Z<p>Sysop: </p>
<hr />
<div>(Texte mis en page avec titres et commentaires (en itallique) pour plus de clarté).<br />
<br />
IESG Response to JFC Morfin on the Appeal concerning its approval of the "draft-ietf-ianaplan-icg-response"<br />
<br />
16 April 2015<br />
<br />
== First paragraph ==<br />
<br />
The IESG interprets the appeal as having two elements: <br />
<br />
* one is largely focused on making comments about the IANAPLAN document and <br />
* the other is asking questions about what the consensus on the document means. <br />
<br />
The IESG notes that appeals are not a supplement to participation in the working group, and that the appellant did, in fact participate in the working group process. <br />
<br />
We recognize that the appellant is seeking to make a precautionary appeal as stated at the beginning of the appeal text. <br />
<br />
The IESG considers that the RFC 2026 appeals process is only available for handling actions that have already been performed, and that appeals cannot be used to develop questions about potential future actions or outcomes. <br />
<br />
The IESG further notes that appeals of this length, and appeals that use novel and/or unfamiliar terminology and expect readers to understand it are not helpful to the process. We strongly encourage appellants to be brief, clear, and to the point.<br />
<br />
== Disprespect of RFC 6852 principles ==<br />
<br />
The actionable substance of the appeal appears to be that the consensus on the IANAPLAN document is in question because<br />
<br />
:(1) the appellant was not given proper consideration by the working group, and <br />
:(2) organizations, such as IEEE, W3C and other lesser known organisations were not included and given consideration.<br />
<br />
The appellant also calls the working group charter into question, but he has brought charter issues up before and there has been no consensus to make changes in response to those issues, and the time is well past for appeals related to the content of the charter: the charter approval was announced on 8 September, 2014, so the two-month period specified in Section 6.5.4 of RFC 2026 ended in early November.<br />
<br />
* The IANAPLAN working group, in common with other IETF working groups and according to IETF process, considers input according to the issues and arguments raised, not favoring input from organizations (through liaisons) over input from individuals, and allowing all contributions to be made via the working group mailing list. <br />
* Announcements of the working group's charter were made, as is usual, on the ietf-announce and new-work mailing lists, to ensure that individuals from all organizations could be informed of the work and participants were solicited in that manner. Quite a number of individuals have participated as a result of that solicitation. Further, some organizations have given input through formal liaison channels. It is the IESG's judgment that the process has been followed correctly in this regard.<br />
<br />
== Personnal involvement ==<br />
<br />
It is the IESG's judgment, having reviewed the working group's email archive, that Mr Morfin had significant participation in the working group, that his input was considered, and that where he was not satisfied with the result, it was not because he was ignored. <br />
<br />
The appellant also notes that because there is a PR action preventing him from posting to the IETF discussion list, he could not participate in the last call of the document. Yet the last call notice says that "Exceptionally, comments may be sent to iesg@ietf.org instead."<br />
* Mr Morfin could well have participated in last call through that means, and did not.<br />
* He also does not cite any issues that were discussed during last call that he was barred from commenting on.<br />
<br />
The IESG, therefore, considers that all individuals and organizations were given the opportunity to contribute to the discussion according to normal IETF processes, that no person or organization was denied the ability to contribute, and that all contributions received were properly handled and considered. Consequently, the IESG denies this appeal.<br />
<br />
== Core of the response : implications ==<br />
<br />
The IESG further notes that the IANAPLAN document is very clear about what the scope of the document is, and that it is specifically in response to the request for input from the IANA Stewardship Transition Coordination Group (ICG). <br />
<br />
No further scope is implied nor can be inferred.</div>Sysophttp://iuwg.net/index.php/Acknowledgment_of_the_IESG_dilatory_reponseAcknowledgment of the IESG dilatory reponse2015-04-18T00:50:09Z<p>Sysop: /* On 02:50 18/04/2015, JFC Morfin said: */</p>
<hr />
<div><br />
==== On 02:50 18/04/2015, JFC Morfin said: ====<br />
<br />
Dear Jari,<br />
<br />
I thank you for [http://www.ietf.org/iesg/appeal/response-to-morfin-2015-03-11.html the response of the IESG to my appeal] that I have just seen now. I understand at this stage that the paragraphs of importance are the first and last one, which I perceive as incorrect. This, therefore, calls for an appeal to the IAB that I will forward before June 16, 2015. <br />
<br />
I note that your response, its implications, and my subsequent appeal to the IAB will be of some influence on the French legal and constitutional debate on digital surveillance that is currently underway (as it is also engaged in several other countries). I, therefore, regret the lack of reference to the RFC 6852 related issues in your dilatory response. It will encourage those who perceive the IETF as the US/IETF that the IANAPLAN document has personally implied for you, and as a result plead for the global community's broader independence from political and commercial interests.<br />
<br />
jfc</div>Sysophttp://iuwg.net/index.php/JJU_Algorithm:_D%C3%A9bat(e)JJU Algorithm: Débat(e)2015-04-17T14:18:24Z<p>Sysop: </p>
<hr />
<div>Cette page de support de débat est en français et en anglais.<br />
* Elle concerne l''''algorithme "JJU"''' (''Jetons la Justice aux Uniformes'') rapporté par [http://www.urvoas.bzh/2015/04/03/loi-renseignement-preciser-encadrer-controler/ M. Jean-Jacques Urvoas, député de la première circonscription du Finistère] (Quimper). Cet algorithme est exprimé ici de façon générale : "''pour co-résoudre un problème de sécurité sociétal l'on peut utiliser des boites noires''".<br />
* Elle reprend sous forme de BLIK (Blog/Wiki) des échanges et contributions qui sont en '''cohérence technique''' avec la vision d'une '''architectonique''' cohérente de l''''information''', de la '''communication''' et de l''''intellition''' au sein de l'écosystème digital et de ses utilisations numériques.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
{{LERDA}}<br />
<br />
== Circonstances ==<br />
<br />
Ce que font la Quadrature du Net et d'autres actions est, dans l'urgence, répondre à l'alibi de l'urgence retenu par Manuel Valls pour évacuer au débotté/allumer le débat sur (?) le problème politique fondamental ('''architectonique''', donc plus profond encore que le constitutionnel) de notre société, qui est confrontée à ce que les Américains appellent, partiellement exactement, la "'''singularité technologique'''" et les Californiens renvoient même au "'''post-humain'''".<br />
<br />
Nous ne pourrons toutefois le résoudre que par une discussion sociale sur une extension de la Constitution, comme nous l'avons commencé avec la Charte de l'Environnement (qui a déjà introduit les principes de '''participation''', de '''responsabilité proportionnelle''' et des '''droits et devoirs de précaution''', de l''''Etat''' et des '''Citoyens'''). Les bits et les bots font aujourd'hui partie de notre environnement et de notre société devenue "anthropobotique" : en fait nous en sommes "refaits" (double sens ?) par la numérisation de nos corps, êtres et gestes.<br />
<br />
La réponse à moyen terme est donc d'utiliser la technique d'une manière qui nous fera soupçonner de contravention à la loi. Il s'en suivra des assignations qui nous donneront le moyen, sans polémiques complexes, de QPC, et donc assurer au Conseil d'Etat et au Conseil Constitutionnel une saisinne pour commenter la loi que le Parlement ne lui accorde pas et que la voix populaire lui réclame.<br />
<br />
== At 10:06 16/04/2015, xxxx wrote: ==<br />
<br />
==== ''Honnêtement, le français technique me sort par les yeux.'' ====<br />
<br />
:Je comprends tout à fait. Et je compatis. Nous en sommes au début de notre société "post-moderne" et s'il n'y avait qu'une chose à retenir pour survivre à cette évolution c'est que la pensée humaine seule ou en groupe n'y suffit plus. De la même façon que la société industrielle a été que le corps humain seul ou en groupe n'y suffisait plus. Il fallait l'aide de la machine. Aujourd'hui il nous faut l'aide de l'ordinateur.<br />
<br />
:Et de la même façon que le français du XXème serait inaudible à Napoléon, le français post-moderne est mal-audible aux Francophones modernes à qui il sort par les yeux (mais rerentre par le Palais Bourbon).<br />
<br />
:Ce qu'il faut accepter est que ce mal-audible n'est pas tant au niveau des sujets que l'on peut apprendre, des mots ou des tournures que l'on peut étudier, mais de l'énonciation elle-même, car ce qui a changé est la manière de penser. L'on ne pense plus avec sa tête ou en échangeant avec celle des autres, on pense avec sa tête, son ordinateur, la tête et les ordinateurs des autres et tout cela en réseau. C'est uniquement cela l'"algorithme des boîtes noires". Le reste est du détail applicatif qui va changer tout le temps et devenir de plus en plus complexe, puissant, intrusif, dirigiste, buggé, virussé, etc.<br />
<br />
:L'algorithme des boites noires est l'article voté hier :<br />
<br />
<pre><br />
0001 Pour terroriser les terroristes<br />
0002 il faut mécadigitalement les terroriser<br />
<br />
0003 comme ils sont inconnus il faut suspecter tout le monde<br />
0004 et être crédibles sur la manière dont on peut enquêter<br />
0005 c'est à dire que tous croient<br />
<br />
0006 que l'Etat peut savoir ou inventer tout sur tout<br />
0007 avant que de choisir entre abstention, action et assignation.<br />
<br />
0008 ce qui requiert une preuve par la démonstration constante de cette capacité<br />
0009 qui sera pédagogiquement administrées par son application visible ordinaire<br />
0010 à la criminalité qui met en oeuvre une sophistication et à des besoins comparables au terrorisme<br />
0011 mais aussi à la simple délinquance pour la démotivation des candidats au terrorisme et les loups solitaires.<br />
<br />
0012 cette capacité repose sur la recherche de correlations d'indices dans l'espace, le temps, et la mémoire<br />
0013 qui devront donc être renouvelées à chaque extension de la mémorisation<br />
0014 ce qui est très lourd et sera allégé par effacement mémoriel à optimisation (plus d'info/MO)<br />
<br />
0015 les autorisations réglementaires et budgétaires nécessaires sont préautorisées<br />
</pre><br />
<br />
:Cette dernière optimisation correspondant à un oubli selectif va certainement donner lieu à une recherche poussée : comment pouvoir se souvenir plus en mémorisant moins. Aristote l'a bien compris : l'intelligence n'est pas de se souvenir mais de se remémorer.<br />
<br />
==== ''Je n'ai pas compris le paragraphe qui parle de la Terre comme d'un ordinateur quantique,''====<br />
<br />
:Tu prends n'importe quoi : tu peux le "numériser", c'est à dire le voir sous forme digitale (les pixels de ton écran ou de ta jet d'encre). L'ensemble de ces pixels est la digitalité, faite de 0 et de 1 et soumise à la vision ponctuelle d'une multitude de formats locaux qui vont te donner des images, des textes, du son, etc.<br />
<br />
:Si tu compresses cela (c'est à dire réduit l'entropie, le superfétatoire, au maximum) tu vas avoir le ".zip" de l'univers, la digisphère. Rien que des 0 et des 1. C'est la trace mémorielle que laisse l'univers.<br />
<br />
:Les boites noires de la loi, vont tenter d'en tracer quelques unes. Ce sera la "captamasse".<br />
<br />
==== ''personellement - je ne vois pas le rapport avec la surveillance de masse ou avec la datamasse''====<br />
<br />
:Nous allons traiter la '''captamasse''' pour la faire parler au miximum. Ce que nous allons en tirer sera la "'''tractamasse'''". Ce que nous croirons être la révélation de la réalité cachée. Ceci va nous permettre d'en faire une carte (ontographie) que nous allons documenter en temprs réel (ontologie) en la croisant avec d'autres ontologies (autres sources, autres suspects, etc.)<br />
<br />
:Mais pour savoir mieux, il faudra savoir plus. Ou pour imaginer plus crédible.<br />
<br />
:Attention : ce que je décris est ce que nous faisons tous, tout le temps (en pensant, en discutant). En nous mettant en réseau de gros ordinateurs d'Etat on faire un peu plus. Notre problème est que l'"algorithme" de la loi ne fixe pas de limite<br />
<br />
==== '' (qui d'aprés wikipedia est simplement la version approuvée par l'Académie Française de "Big data")'' ====<br />
<br />
:L'académie française n'a pas encore bien compris tout ce qui est en train de se passer et qui - en fait - boulverse le concept même de langue. Elle tente de mettre des mots français sur des concepts anglais. Sans se rendre compte que les concepts anglais ne sont pas toujours des concepts français; les chercheurs/philosophes/analystes francophones étant aussi bons (historiquement meilleurs ?) que les anglo-saxons pour trouver ou approfondir des idées nouvelles, et ayant une approche de pensée différente sans doute en raison de leur langue - qui est sans doute plus appropriée (plus méta/mécaniste) que l'anglais à la machine évoluée (sémiotiquement). Bien que nous ayons de grands progrès à faire dans des choses de base pour l'AlgoJJU" comme :<br />
:* la mécalingistique (l'utilisation des langues par les machines)<br />
:* la multilinguistique (la cybernétique des langues entre elles)<br />
:* la morphotypie (rasterisation des passeports pour éviter les variance erronées par exemple).<br />
<br />
Pour ce qui est du sens :<br />
* Les "'''big data'''" sont le problème informatique posé par toutes les captées accumulées (''captamasse'') à transformer en tractées (''tractamasse'') utilisable. Le vocable est étendu sous forme de "bad data" (intox), "bog data" (poluées).<br />
* La "datamasse" est l'ensemble des données disponibles dans l'univers qu'il est possible d'extraire. Le mot utilisé en anglais est "datamass". <br />
<br />
==== ''[http://rue89.nouvelobs.com/2015/04/15/lalgorithme-gouvernement-sera-intrusif-inefficace-prouve-258672 Je suggérerai bien de rajouter un lien sur l'article de rue89 sur le sujet]'' ====<br />
<br />
:Fait ! Attention : les gens interviewés sont les gens qu'un journaliste a cru techniquement compétents. Il faut aller voir dans certains détails et dans certains commentaires que la problèmatique du journaliste et de la loi ne sont pas la même. Il se demande comment l'on peut faire, les députés disent simplement qu'ils faut le faire et qui sera responsable de la recherche, du développement et des opérations.<br />
<br />
<br />
== Monsieur le Député Urvoas ==<br />
<br />
Il est manifeste que vous ne maîtrisez que partiellement la problématique que vous vous proposez de légiférer. Ceci me paraît tout à fait normal : la société humaine est en effet soumise depuis 125 ans à une profonde mutation de pensée que l’on nous brocarde souvent sous le nom de « singularité technologique ».<br />
<br />
==== Ce qui se passe ====<br />
<br />
Il s’agit simplement de l’irruption en 1889 des conclusions du mathématicien français Henri Poincaré qui a invalidé une vision simplement newtonienne du monde et ouvert dans les années qui ont suivi à la confirmation de l’atome, à la physique quantique, aux théories de la relativité, à l’incomplétude mathématique, à la théorie dite des catastrophes, à la théorie de l’information, à la cybernétique, à l’auto-organisation critique, à la théorie des systèmes, au problème de localité, au principe du « réseau des réseaux » de Louis Pouzin et à son application US à la technologie de l’Internet.<br />
<br />
* Cette irruption, basée sur la bande perforée de Basile Bouchon, les travaux de Leibnitz sur le binaire, l’algorithme industriel de Jacquard, etc. est simple à comprendre : la simplicité est la capacité d’extraire une continuité numérique (analogue) au sein de la discontinuité complexe (catalogue) de la digitalité de l’univers.<br />
<br />
* Il s’avère que cette simplicité est une séquence finie et non ambigüe d’opérations ou d’instructions permettant de résoudre un problème de reproductible (donc prévisible). Elle a été identifiée par Al-Khawarizmi dans le contexte de la syllogistique et de la logique du tiers exclu d’Aristote. Elle s’appelle un algorithme. Chacune de ses opérations ou instructions peut elle-même faire l’objet d’un algorithme pour autant que la récurrence en soit clairement limitée, donc programmable.<br />
<br />
==== L'Algorithme des boites noires ====<br />
<br />
L’exemple typique d’un algorithme est donc une loi, accompagnée de ses décrets d’application, et de ses circulaires interprétatives et réglementaires.<br />
<br />
La loi que vous présentez est donc tout simplement un nouvel algorithme de protection régalienne intérieure, l’algorithme « JJU » (traduit par certains comme « Jeter le Juge pour l’Uniforme »).<br />
<br />
Ancien officier de Marine je n’ai rien contre l’uniforme, mais son rôle au sein de l’Etat relève de l’Archonte Polémarque (polémiques « extérieures » à la cité et à l’ordre) et non de l’Archonte Basileus (paix « intérieure »).<br />
<br />
Toutefois, je conçois très bien votre dilemme face au niveau digital nouveau pour l’Etat, qui doit gérer un nouvel espace régalien : celui de l’ « ultérieur » et de ses menaces (que la Constitution nous indique de traiter par la Précaution, sans avoir encore assigné sa préparation et son organisation à cet Archonte Architarque dont nous nous découvrons la nécessité pratique, hors du domaine de la synthèse théorique en terme de ***science*** politique, dont l’inventeur Aristote, fait l’***art*** politique la conduire de la société des hommes libres).<br />
<br />
C’est pourquoi votre algorithme est bancal. Elle devrait s’appuyer sur un Archonte qui ait le même niveau de séparation des pouvoirs régaliens que les Ministres de la Justice et de l’Intérieur (et leurs Juges) et que le Ministre des Armées (et ses Officiers).<br />
<br />
==== la présomption de culpabilité lourde ====<br />
<br />
Si vous réfléchissez bien : l’idée est que le Terroriste n’a pas à être protégé par la loi commune. Le problème est que l’on ne saura qu’il est un terroriste qu’après l’attentat.<br />
<br />
Le pari est donc :<br />
<br />
* que l’« intellition » (c’est-à-dire la capacité intelligente, facilitée par ordinateur, à produire de l’information nouvelle à partir de la connaissance existante – la discipline fondamentale de nos vies et de notre temps que nous ignorons royalement) va nous permettre de savoir de façon suffisamment certaine qu’un individu/une organisation va commettre un crime qui va le placer hors-la-loi.<br />
<br />
* et que l’on va pouvoir transporter cette certitude du futur au présent : pour qu’il en devienne d’hors et déjà hors-la-loi. Il est indéniable que le pouvoir d’en décider ne peut relever que de qui est en charge de l’ « ultérieur ».<br />
<br />
==== Un changement de paradigme constitutionnel ====<br />
<br />
Nous sommes donc confrontés à un problème constitutionnel fondamental, que le Premier Ministre souhaite trancher dans l’urgence.<br />
<br />
Ce n’est pas possible, sauf à considérer qu’il s’agit d’une loi d’exception (comme la loi sur les suspects de 1793, la loi de 1858, ou les dispositions sur la 5ème colonne), sur laquelle nous allons revenir. <br />
<br />
Car, il ne s’agit pas d’un danger politique du domaine du maintien de l’ordre civil ou de la protection de l’Etat, mais – à l’occasion du couplage de circonstances politiques (terrorisme) et technologiques (le numérique – la découverte d’une nouveauté architectonique fondamentale qui concerne : <br />
<br />
* la souveraineté régalienne (droits et devoirs) sur la digitalité du cyberespace,<br />
* les institutions qui doivent les gouverner alors que nous avons déjà :<br />
:* souscrit à l’engagement de Tunis (Sommet Mondial pour la Société de l’Information – 2005) <br />
:* et reconnu que leur gouvernance se devait d’être techniquement tripartites pour prospérer (régalien, citoyen, privé). <br />
<br />
Pour cela,<br />
* notre pays, le Livre Blanc, le Gouvernement, etc. n’a pas de doctrine de défense, pourtant depuis longtemps réclamée depuis longtemps par Jean-Marie Bockel,<br />
* et nos militaires n’ont pas de méthode – confondant les divers niveaux du « cyber », le réduisant à la seule informatique physique et non pas à l’ensemble des sciences de <br />
:* l’information (ce qui augmente la connaissance), <br />
:* la communication (ce qui duplique la connaissance) et <br />
:* l'intellition (ce qui permet de créer de l’information à partir de la connaissance) <br />
:dans un environnement <br />
:* non plus de logique linéaire (dialectique),<br />
:* mais de polylectique maillée des influences, des menaces, des forces, des intentions politiques, des croyances, des objectifs, etc. tout ce que l’identification informatique (au sens de science de l’information) des motivations, préparations, actions terroristes) va réclamer.<br />
<br />
Etant confronté de façon directe par la conduite des intérêts citoyens, <br />
<br />
::*ce que l’on a qualifié de « société civile ») <br />
::*dans le contexte général de la digisphère et la stratégie actuellement engagée par l’administration Obama (dont je fais actuellement appel sur une base de gouvernance technique)<br />
<br />
je sais la difficulté qu’il y a à ménager les besoins, les attentes, les innovations dans ce nouvel espace de la vie, de l’activité, de l’industrie et des risques humains. <br />
<br />
Dans cet espace le Terrorisme est un aspect à court terme d’importance seconde par rapport aux enjeux : vous l’avez mesuré à rencontrer les industriels de l’hébergement. Dans la guerre digitale globale, la détection des traces numériques de terroristes est comparable à une traque de police au sein d’une invasion.<br />
<br />
==== Relationnels Libres ====<br />
<br />
C’est pourquoi, au nom des « Relationnels Libres », c’est-à-dire de la gestion autonome des ressources digitales partagées (le Catenet, selon le nom que lui a donné Louis Pouzin et qu’ont repris les développeurs de son application internet), je sais que tout réclame tâtonnement et expérimentation.<br />
<br />
Le but que nous pouvons donc nous assigner serait : <br />
:* face aux dispositions funestes pour la liberté, l’innovation et l’industrie qu’impliquerait l’urgence<br />
:* en ne permettant pas de faire d’abord appel au Conseil Constitutionnel et au débat de fond populaire que réclame une extension de la constitution – sans doute soumise à consensus référendaire solennel (il s’agit de la souveraineté digitale de la France) <br />
<br />
* de ne pas figer les textes actuels en les fixant « ad experimenda » (avec une révision/confirmation prévue à l’issue d’une période expérimentale et d’un débat), <br />
* et de susciter la recherche d’exemples pratiques où l’innovation technologique et de l’utilisation vont se trouver en contravention avec les textes. Ceci permettra à partir de la pratique soit pour alimenter le débat, ou de le soulever à l’occasion de QPC. Sans opposer le fonds et l’urgence.<br />
<br />
==== Légaliser le réglementaire ====<br />
<br />
Je note enfin que votre position qui consiste à dire que l’on ne fait que légaliser une pratique réglementaire autorisée par décrets montre bien que nous sommes au niveau constitutionnel. La loi que vous faites voter n’est pas constitutionnelle, non qu’il s’oppose à la Constitution, mais parce qu’elle légifère dans un domaine où la Constitution n’a pas encore dit la souveraineté et encore moins le droit.<br />
<br />
==== L'incapacitation technique de la Magistrature ====<br />
<br />
Pour terminer, je veux noter que techniquement votre loi est impossible à un Juge. Qui va prouver que les contenus, pardon les "métadonnées", qui lui seront présentées comme preuves sont le fait du prévenu, de la NSA, d’un hacker, d’un virus ou d’un bug. <br />
<br />
La France est, comme les autres nations, souveraine dans le domaine de la digitalité. Le problème est que la digisphère n’est pas locale, mais globale, et que cette "globalité" (en français, « le tout supérieur à la somme de ses parties ») est encore plus que ne peut l’inclure la "mondialité" américaine qui tente de nous vassaliser à son avantage, puis qu’il inclut les '''liens entre les choses et le temps'''.<br />
<br />
==== L'incapacitation des Elus et des Dirigeants de la Nation ====<br />
<br />
Simplement, si elle se voulait pérenne, votre loi ne servirait qu’à fournir du travail aux Juges : pas un parti, pas un homme politique, pas un dirigeant qui ne serait à l’abri du '''sifflotage''' (''Snowden'') ou de l’'''invention''' (''Clearstream 2'') d’un hacker.<br />
<br />
<br />
== Pour aider à cette analyse ==<br />
<br />
=== Le problème des mots ===<br />
<br />
Pour l'instant, le premier problème que nous avons est de pateauger avec des mots de journaliste pour parler de choses totalement nouvelles. Le fameux "algorithme des boites noires" est la loi elle-même. Un algorithme est une recette. Il utilise des instructions qui sont ses algorithmes seconds, etc. Ici l'algorithme est : "pour résoudre le problème du terrorisme : utiliser des boites noires". Les algorithmes seconds seront les décrêts d'application et les circulaires réglementaires et explicatives des appels d'offre et des contrats passés.<br />
<br />
=== Algorithme vs. Agorisme ===<br />
<br />
Le problème auquel nous sommes confronté est qu'un algorithme est par définition fini (fermé) (cf. Al Korizemi). La recette ne se continue pas sur la table, dans l'estomac, etc.<br />
* elle dit "prenez des oeufs" (elle est prédicative) et donc calculable.<br />
* elle ne dit pas "prenez une recette" (c'est à dire imprécative, utilisant des composants à son image, ce qui peut être récusrsif mais aussi conduire au cercle vicieux de la boucle infinie, au bug).<br />
<br />
Ici nous avons un besoin qui sera indéfiniment ouvert (à chaque amélioration découverte, à chaque nouveau type de suspects, etc.). Cela n'est plus un algorithme mais un agorisme (ce qui va traiter ce qui se passe/émerge dans les/des agoras d'agoras d'agoras, etc. de trucs ouverts). Nous sommes en fait confrontés au paradigme imprécatif de Louis Pouzin que nous connaissons tous sur le bout des doigts : "le réseau des réseaux". <br />
<br />
Nous ne pouvons nous en sortir qu'en transformant notre agorisme/loi ouvert(e) en algorithme fermé c'est à dire en devenant exhaustifs : en sachant tout sur tout le monde. CQFD.<br />
<br />
=== La preuve par le futur ===<br />
<br />
En Justice nous avons besoin de preuves, c'est à dire de faits passés, authentifiés, vérifiés, mémorisés. Ici nous voulons des preuves (que A ou B est un terroriste) ***avant*** les faits. Donc découvrir des preuves ***futures*** et condamner des gens pour ce qu'ils n'ont ***pas encore fait***. <br />
<br />
Cela s'appelle jusqu'à maintenant :<br />
* soit l'abritraire, avec un responsable : le tyran, et un droit : celui de la terreur. Terrorisons les terroristes (5ème colonne, Valls).<br />
* soit l'exception, avec un responsable : le juge, et un droit : les lois des suspects. Etablissons la Terreur (Robespierre, etc.)<br />
* soit la violence, avec un responsable : l'exécutif, et un droit : celui de la guerre. Guerre au terrorisme (Chirac puis Bush).<br />
<br />
Nous sentons qu'il faut le constitutionaliser. <br />
<br />
#Nous ne pouvons pas utiliser de preuve ? Pas de problème, qui cela gène-t-il ? Le Juge. Jettons le Juge pour l'Uniforme (l'algorithme JJU, Jean-Jacques Urvoas)<br />
#Le droit de la cyberguerre est en cours (Manuel de Tallin). Mais la France (VA Coustillière, en charge de notre CyberDéfense) ne croit pas à la CyberGuerre. AMHA la racine est à l'académie française qui ne fait dictionnairement pas de différence entre le numérique (de de - à + l'infini - ce que nous utilisons) et le digital (0 et 1, ce dont les choses et les machines sont faites). Ceci nous gène pour bien comprendre beaucoup de choses, mais peut nous aider à mieux nous les approprier en y réfléchissant ensemble.<br />
#Pour l'instant l'idée semble donc de l'appeler "surveillance numérique", avec un responsable : "l'administration", et un droit "celui des machines". Pour une informatique (science de l'information) du terrorisme. <br />
<br />
=== Au Menu ===<br />
<br />
Souvenons-nous de l'autre paradigme de base de l'internet (Dr. Lessig) : "la constitution est dans le code source". Nous allons changer de Constitution - et abbroger le parlementarisme (tous seront comme leur prédécesseur imprécatif Robespierre - au menu du Mur des Cons, dégustés, au choix, à la '''sauce Snowden ou Clearstream'''). <br />
<br />
Toutefois, je ne sais pourquoi il y a comme un arrière-gout de "Google paradigm" : "si c'est gratuit, c'est vous le produit", et que nous sommes tous au menu ?<br />
<br />
=== Droits de l'homme à l'envers ===<br />
<br />
Le [http://www.vie-publique.fr/decouverte-institutions/justice/definition/garanties/qu-est-ce-que-presomption-innocence.html principe de la présomption d’innocence] est garanti par de multiples textes : il apparaît notamment dans la Déclaration de droits de l’homme de 1789, dans la Convention européenne des droits de l’homme, et, depuis une loi de 2000, il est placé en tête du code de procédure pénale.<br />
<br />
Le principe même de la "guerre au terrorisme" de Chirac, Bush, Valls est une erreur de doctrine militaire. Le concept adéquat est celui de "'''contreguerre au terrorisme'''". Le problème est que notre cerveau humain et notre pensée actuelle n'est pas suffisament puissant pour aisément accomoder ce que "contreguerre" signifie. Ceci résulte de ce qu'une contreguerre est une guerre actuelle aux racines d'un conflit qui pourrait advenir. Il ne s'agit donc plus de se battre contre un ennemi extérieur ou intérieur, mais ultérieur. Ceci nous demande certainement l'aide d'algorithmes adéquats. L'algorithme des boîtes noires est-il une priorité optimale face au type de la menace ?<br />
<br />
Ceci est complexe car la stratégie, la tactique, la Justice se fondent sur des informations prouvées (rensignement, instruction). La contreguerre se fond sur de l'intellition cohérente, c'est à dire des choses qui ne sont pas encore advenues, mais dont les machines ont confiance en leur survenue, et que l'on va s'efforcer d'empêcher - et que donc on ne pourra pas valider.<br />
<br />
Il ne s'agit donc plus de protection mais de précaution. Il ne s'agit plus de considérer des '''faits''' mais de présumer des "profaits" de confiance variable. Il faut pour s'en sortir construire un nouveau Code des Droits de l'Homme basé sur la présomption de culpabilité. Ceci n'est pas une plaisanterie mais constitutionnel:<br />
<br />
::"Lorsque la réalisation d'un dommage, '''bien qu'incertaine en l'état des connaissances scientifiques''', pourrait affecter de manière grave et irréversible l'environnement (*), les autorités publiques veillent, par application du principe de précaution et dans leurs domaines d'attributions, à la mise en oeuvre de procédures d''''évaluation des risques''' et à l'adoption de mesures '''provisoires''' et '''proportionnées''' afin de '''parer à la réalisation du dommage'''. (Article 5. Charte de l'Environnement)<br />
<br />
::NB: "Chacun a le droit de vivre dans un environnement équilibré et '''respectueux de la santé'''". (Article 5. Charte de l'Environnement). Le respect de la santé, commence par le respect et la protection de la vie des gens.<br />
<br />
=== Mots de la constitution ===<br />
<br />
Il semble qu'un certaion nombre de mots sont utilisés dans la Constitution (et en particulier dans la Charte de l'Environnement), dans la loi et les textes réglementaires qui nécessiteraient une définition juridique bien plus précise. <br />
<br />
:;santé: seule définition traité de New York créant l'OMS ?<br />
:;environnement :<br />
::# Action d'environner ; résultat de cette action.<br />
::# Ce qui entoure de tous côtés. Vivre dans un environnement de forêts. Travailler dans un environnement de livres.<br />
::# Ensemble des agents chimiques, physiques, biologiques, et des facteurs sociaux exerçant, à un moment donné, une influence sur les êtres vivants et les activités humaines. Le digital et le numérique sont ils part des "facteurs sociaux" ?<br />
:;digital vs. numérique : l'Académie Française fait dans l'abus de langage et la confusion avec le mot [http://fr.wikipedia.org/wiki/Digital digital] : "''Emprunté de l'anglais digital, dans digital computer, « ordinateur digital », dérivé de digit, « chiffre » (en tant qu'ils étaient primitivement comptés sur les doigts). INFORM. TECHN. Qui utilise des nombres, numérique. Le terme Numérique doit être préféré''" !!!.<br/>C'est oublier bien vite Basile Bouchon, Jean-Baptiste Falcon, Jacques Vaucansson, Joseph Marie Jacquard. Excusez du peu. Les nombres sont '''continus''' de (- l'infini) à (+ l'infini). Les digits sont '''discontinus''' (0 et 1) en codage artificiel, (U,C,A, G) en codage naturel (chromosome), les entiers en arithmétique, etc.<br />
<br />
== Travailler sur la pertinence technique de la loi ==<br />
<br />
La loi actuellement proposée a été pensée dans le contexte d'une vision inexacte de la réalité digitale. Il faut donc :<br />
<br />
* repartir de ce qui existe vraiement, <br />
* pour le documenter à l'intention des utilisateurs, des décideurs et des politiques<br />
* pour ensuite poser ensuite les vais problèmes en les illustrant concrêtement.<br />
* dégager ensemble :<br />
::* les approches techniques qui conviennent au besoin social et économique durable.<br />
::* les insérer dans un contexte sociétal et constitutionnel démocratiquement débattu et adopté.<br />
<br />
==== La base réelle de la digitalité ====<br />
<br />
Le '''Catenet''' est la concaténation des ressources locales partagées par la structure de réseau digital global utilisé par les différentes technologies d'échanges numériques telles que :<br />
<br />
* l'internet, <br />
* le NDN (réseau à contenu dénommé),<br />
* le SDN (réseau logiciellement défini),<br />
* les réseaux maillés locaux, <br />
<br />
Il est perméable à certains de leurs services qui peuvent ainsi être utilisés d'une technologie l'autre. Exemples :<br />
* plans de numérotation : Téléphone, IP, ULA, <br />
* nommage : Classes du DNS, Marques,<br />
* bande passante géostationnaire : câbles, liaisons radio, transpondeurs satellites, liens optiques, <br />
* alimentation électrique/solaire, <br />
* implantations immobilières : immeubles, espaces, etc. <br />
* matériel, équipements, mémoire, ...<br />
* bases de données référentielles, <br />
* standards internationaux : ISO, ITU, etc.<br />
* instances de gouvernance : IGF, régles internationales, lois locales<br />
* industries de fournisseurs d'accès et services.<br />
<br />
La prééminence politique donnée par les Etats-Unis à la seule technologie TCP/IP de l'internet est la trosième phase (qui s'achève) de l'histoire du Catenet mondial.<br />
<br />
#1977-1987 : le monopole technologie est celui de la technologie '''Tymnet'''. <br />
#::* Son architecture est frange à frange, <br />
#::* le réseau de bout en bout relie des points d'accès intelligents capables des processer les captées reçues à partir de leurs métadonnées (données sur les données) <br />
#::* et développaient des services étendus (en particulier à partir d'Eurloab Saint-Cloud) utilisant les syllodonnées (données entre les données liées) pour la livraison de "traitées". Ce laboratoire a été fermé en 1986 et ses services peu à peu abandonnés pour "NSA-incomptibilité" après le rachat de Tymshare/Tymnet par le groupe Mc Donnell Douglas.<br />
#1981-2009 : la proposition X.25/X.75 du '''CCITT''' supportée par Tymnet et Telenet, puis CII, Northern Telecom, etc. qui a été la technologie du réseau '''Transpac''', devenu le plus puissant au monde.<br />
#::* Diverses tentatives ont été tentées pour acclimater cette technologie dans le contexte des achats militaires américains. <br />
#::* Le point d'achoppement principal étant l'absence dans la technologie TCP/IP de la "couche OSI six, présentation" tournée vers la sécurité, l'intelligence, les services, le multilinguisme, notemment inclues dans le prototype Cyclades du Catenet par l'équipe IRIA de Louis Pouzin (Huber Zimmerman, Michel Elie). <br />
#1983-actuelle : la proposition TCP/IP de l''''IETF''' d'un catenet pour le réseau ARPANET et son "internetting" avec les autres réseaux sous technologie similaire (comme le CCITT, premier objectif) ou non (comme Tymnet, second objectif). Cette seconde phase n'a pas encore vu le jour en réson de la stratégie américaine du "status-quo" qui avait bloqué Tymnet et le CCITT.<br />
<br />
Aujourd'hui le "[http://fr.wikipedia.org/wiki/Monopole_radical monopole radical]" de l'architecture internet organisé par l'ICANN<br />
* sous le protectorat du NTIA (agence de télécommunications de l'Exécutif américain) <br />
* et la légende des serveurs racines, <br />
se prépare à être transféré à partir du 30 septembre 2015 sous le contrôle "commun" de la loi <br />
* principalement américaine vu les implantations des organisations impliquées<br />
* et donc de la réglementation de la FCC. Le propos de la Maison Blanche est que la confusion commune entre le Catenet et l'Internet <br />
::* transfère de facto dans la pratique contractuelle leur supervision de l'internet sur le catenet, <br />
::* fasse prévaloir <br />
:::*une approche normative (RFC 6852), <br />
:::*une gouvernance multipartieprenante, <br />
::: et hautement algorithmique à travers la maîtrise des "big data" de leur industrie et de leur administration (Google, NSA/USCC).<br />
<br />
L'IUWG est une approche des "'''Relationnels Libres'''" pour soutenir une approche <br />
* cooperative de l'optimisation "omnipartieprenante" du Catenet par chacun de ses utilisateurs <br />
* une vision "post-Google" de l'intellition de la datamasse (chacun propriétaire de ses propres données) <br />
<br />
Cette approche se fera dans le contexte de la nouvelle stratégie de "permissionless innovation" poussée par les Etats-Unis où ils misent sur :<br />
* la taille/puissance politique des centres normatifs (IEEE, IETF, IAB, ISOC, W3C) <br />
* et les ramifications commerciales et sociales des "communautés globales" de consommation<br />
* pour assurer leur dominance sur l'utilisation européenne <br />
* et tenir tête aux déploiement des BRICS.<br />
<br />
Dans ce contexte l'IUWG a engagé [http://iuwg.net/index.php/Letter_to_Lawrence_E._Strickling,_Assistant_Secretary,_NTIA une demande de clarification technique et de gouvernance normative] destinée à établir l'approche coopérative d'une compagnie du Catenet (CCC) comme le coeur d'une des grandes "communautés globales" (considérées par les USA comme des bienfaits pour l'humanité) fondée sur les valeurs du Libre.<br />
<br />
==== Un exemple parlant du DECLIC ! ====<br />
<br />
Le même jour que le vote de la loi sur la surveillance en 1ère lecture : http://www.nextinpact.com/news/93847-la-france-ouvre-sa-base-d-adresses-nationale-collaborative.htm<br />
<br />
Du '''DECLIC''' (Durable En Coopération Libre, Institutionnel, Commercial) :<br />
<br />
* OpenStreetMap<br />
* Etat<br />
* Poste<br />
<br />
Voilà ce que les '''Relationnels Libres''' veulent !<br />
<br />
==== Définitions sémantiques ====<br />
<br />
L'on comprends de plus en plus que la '''personne''' est une vision consciente, autonome et souveraine de la réalité, en commençant par la sienne propre. Ses formes, essence, intelligence, et substances physiques, morales, intellectuelles, etc. peuvent avoir diverses preprésentations, y compris numériques (pixel), biologiques (phénotype), digitales (datamasse), intellectuelles (oeuvre), etc.<br />
<br />
La personne peut se voir privée de parties de sa consience (manipulation), de son autonomie (assujetissement), de ses biens (propriété), de sa souveraineté (destruction, inféodation) et même de son existance (assassinat, exécution). La partie de son "territoire privé" dont elle peut ainsi être privée sera en conséquence topologiquement appelé son "'''privatoire'''".<br />
<br />
Ce "privatoire" va inclure sa vie physique, morale et intellectuelle, les secrets privés qui la concerne, sa réputation, sa mémoire, ce qui a trait à sa protection, etc.<br />
<br />
Ce "privatoire" et son respect sont fortement protégés par la loi, la Constitution et les Droits de l'Homme. En particulier dans le cadre de la Société de l'Information que le Sommet Mondial de Tunis s'est engagé à l''''unanimité des représentations des peuples de la Terre''', comme devant être "'''people centered, à caractère humain, centrada en la persona'''".<br />
<br />
Ce "privatoire" est en but à plusieurs types d'agressions physiques et morales : médisance, calomnies, menaces, voies de faits, viols, vols.<br />
<br />
Une forme particulière d'agression correspond à l''''inhibition''' d'une partie de ce "privatoire" par la '''peur'''. C'est ce que l'on appelle le "'''Terrorisme'''", <br />
* qui va créer et utiliser un climat de terreur sur les personnes, <br />
* qu'il alimente par <br />
:* des violences physiques (attentats, exécution), intellectuelles (peur, chantage), <br />
:* ou des pénétrations de l'intimité corporelle (viols) ou informationnelle.<br />
<br />
(''NB: l'on notera que le terme "privatoire" ainsi défini est un polynyme [synonyme interlinguistique strict], utile à la compréhenson mutuelle, du terme anglais "privacy"'').</div>Sysophttp://iuwg.net/index.php/EXP:OPESEXP:OPES2015-04-15T12:08:15Z<p>Sysop: /* Qu'est-ce que c'est ? */</p>
<hr />
<div>'''OPES''' : open pluggable edge service. <br/>'''ONES''' : open networked edge services.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
== Un OPES qu'est-ce que c'est ? ==<br />
<br />
Un '''OPES''', c'est très simple dans le principe :<br />
<br />
* une simple '''dérivation''' (sonde) ou '''déviation du trafic''' (capteur) dans une "boîte noire" en plastique.<br />
* pour le faire passer par un '''ordinateur tiers''', local ou distant qui pourra interposer ses services pour, par exemple :<br />
: * '''copier'''<br />
: * '''bloquer'''<br />
: * '''facturer'''<br />
: * '''retarder'''<br />
: * '''modifier''' (exemple : traduire, processer, compléter, vérifier, etc., etc. ) le trafic échangé.<br />
<br />
Elle peut être rendue un peu intelligente pour filtrer plus particulièrement un protocole, un type de trafic. Mais dans ce cas, il suffirait d'utiliser un nouveau protocole pour s'en affranchir ... pas très sûr pour de la surveillance générale.<br />
<br />
== Et un "ONES" ? ==<br />
<br />
Un '''ONES''' consiste en la '''mise en corrélation''' de trafics par la '''mise en réseau''' de leurs ordinateurs tiers associés. <br />
<br />
C'est une proposition faite au Groupe de Travail de l'IETF qui a spécifié les OPES, mais qui sortait du cadre strict de son "charter" limité à la "prise intelligente" de la dérivation et ne s'étendant pas aux services eux-mêmes ni à l'organisation de leur serveurs. <br />
<br />
== Intrusions ==<br />
<br />
Les ONES/OPES ne sont donc '''pas intrusifs des opérations''' des utilisateurs, mais de leurs '''relations'''. Leur rôle est donc la surveillance, la protection, la desserte intelligente et la manipulation des espaces relationnels.<br />
<br />
Architecturalement, ils constituent une "frange" (RFC 1958) du réseau qui peut être voulue, inconnue ou acceptée par les utilisateurs. Ils sont au niveau du '''catenet''', c'est à dire de la sous-structure commune aux différentes technologies (Internet, SDN, NDN, réseaux maillés, etc.). Leurs déviations peuvent être implantées sur des "edges" (chemin du trafic) de tout niveau : commutateurs, points d'accès, frontaux de serveurs, sockets, au sein d'une application ou du système d'exploitation - ou requis pas un protocole ou la supervision des opérations d'un réseau.<br />
<br />
== Neutralité ==<br />
<br />
Bien entendu un réseau pourvu d'OPES/ONES à l'intérieur du "bout en bout" ne peut pas être considéré comme neutre.<br />
<br />
* ni au niveau du '''service''', puisque le trafic peut en être ralenti et peut être facilement modulé (cas d'une dérivation) et des additions injectées.<br />
* ni au niveau du '''contenu''', puisque tout ou partie du contenu et des métadonnées peut être modifié - avec ou sans l'accord des parties.<br />
<br />
Seule une augmentation relative des délais de bout en bout peut permettre la détection d'un ou plusieurs OPES/ONES sur une connexion.<br />
<br />
== "Algorithme des boites noires" ==<br />
<br />
Il n'y a pas à proprement parler d''''algorithme des boites noires''' dans le cas d'une déviation totale du trafic : un nœud du réseau est rajouté avec un aller-retour vers un ordinateur tiers. <br />
<br />
Les solutions OPES spécifiées par les RFC de l'IETF inspectent les paquets et les envoient à un ou plusieurs ordinateurs tiers en fonction de leurs métadonnées. Rien n'interdit que ces métadonnées soient d'abord extraites du contenu au fil de l'eau ou en début de cession.<br />
<br />
Lorsque l'on parle d'"algorithme des boites noires" comme Cazeneuve, Besancenot, etc., et la presse, l'on ne se réfère donc pas explicitement à un algorithme qui ferait clignoter la boîte noire à chaque échange terroriste, à partir de la composition de leur adresse e-mail ou à leur fournisseur d'accès, etc. (métadonnées). L'on parle d'une '''chaine informatique''' de plus en plus '''complexe''' et '''puissante''' connectée par ces boîtes noires et faisant appel à des masses de plus en plus importantes de données, en cherchant à les '''corréler'''.<br />
<br />
==== Explication un peu plus poussée ====<br />
<br />
Comprenons : le Terre est un vaste '''ordinateur quantique''' qui calcule à chaque instant son microétat, c'est-à-dire un chiffre binaire fait de milliards de milliards de bits : c'est la '''datamasse'''. On veut collecter une partie de cette datamasse pour tenter d'y trouver le signal d'un danger terroriste. Pour cela on va utiliser des algorithmes successifs. Le premier est celui de la loi : l'on parie que là où on va trouver le plus d'informations c'est sur le réseau, on va donc le forer par des "boîtes noires". Et on en demande l'autorisation. Il est possible qu'on se trompe et que les meilleures données sont ailleurs. On apprend. Ce que l'on sait est que les US (NSA, etc.) se sont ménagé une certaine avance qui leur permet peut-être de nous manipuler.<br />
<br />
C'est cela l'algorithme des boîtes noires : ce n'est que le '''début d'une cascade d'algorithmes''' qui vont tenter d'en savoir le plus possible sur tout le monde sous forme de "0" et de "1" (on se moque de ce que cela veut dire) et de corréler ces "0" et "1" avec d'autres motifs de "0" et de "1" correspondant de près ou de loin à des actes douteux. Et on va recommencer, et recommencer - comme pour le spam. <br />
<br />
==== Attention aux fausses alertes ====<br />
<br />
A la fin, il y aura des positifs et des faux positifs pour lesquels il faudra :<br />
* soit lever le doute (enquête) <br />
* ou prendre une décision dans le doute (action)<br />
* ou assigner devant le Juge pour qu'il instruise l'alerte reçue qui semblera ressembler au signal d'un délit. En sachant que des faux pourront être volontaires (manipulations, intrusions, virus, bugs).<br />
<br />
C’est ainsi qu’aux US une none s’est retrouvée menottée sous la menace de quelques mitraillettes, car elle roulait dans la voiture d’une organisation terroriste … qui venait d'être retenue pour le Prix Nobel de la Paix. L'algorithme responsable a été modifié : il y avait un bug dans le menu d'entrée des données de la Police qui taggait comme "terroriste", les organisations "autres".<br />
<br />
==== La décision du législateur ====<br />
<br />
Ce qui est demandé au législateur est l'algorithme que doit suivre l'opératif. C'est là qu'une doctrine nationale de cyberdefense et de souveraineté digitale est nécessaire (cf. réclamation du sénateur Bockel depuis des années). Le législateur doit décider - vu les avantages et les risques de l'algorithme qui lui est proposé - quel est le mieux pour la France. En particulier dans ce cas de définir jusqu'où l'Etat peut-il aller pour terroriser les terroristes.<br />
<br />
<br/></div>Sysophttp://iuwg.net/index.php/Mal-loiMal-loi2015-04-15T10:13:24Z<p>Sysop: /* Singularité sociétale */</p>
<hr />
<div>Une '''mal-loi''' est une loi du '''mal-être'''. La société actuelle est '''mal à l'aise''' vis-à-vis d'une réalité nouvelle qu'elle identifie encore mal et qui est l''''intellition'''.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
== Intellition ==<br />
<br />
L''''intellition''' c'est la continuation intelligente des notions d'information et de communication.<br />
<br />
* l''''information''' est ce qui '''augmente''' la '''connaissance'''.<br />
* la '''communication''' est ce qui '''copie''' l''''information''' à d'autres '''connaissances'''.<br />
* l''''intellition''' est ce qui''' produit''' de l''''information''' à partir d'une '''connaissance'''.<br />
<br />
Une appréhension simple de l'intellition est "'''ce qui fait sens'''" et qui n'a donc '''pas besoin d'être communiqué pour être su'''. L''''intellition''' est bien entendu limitée par les '''capacités intellitives''' de sa '''cérébrique''', c'est à dire de sa mécanique d'intelligence, face à la complexité de la '''réalité''', des '''personnalités''', des '''virtualités''' possibles.<br />
<br />
== Niveaux cérébriques ==<br />
<br />
Cinq niveaux de systèmes cérébriques sont à considérer :<br />
<br />
# le processeur sémantique naturel de type homo sapiens sapiens ('''PSN/HSS''') : le '''cerveau de chacun'''.<br />
# la mise en réseau intellectuel de plusieurs '''PSN/HSS''' : les assemblée d'hommes et donc de leurs cerveaux discutant entre eux par protocoles linguistiques interposés ('''Universitas''' en latin), <br />
# la construction d'un processeur mécatronique artificiel : l''''ordinateur'''.<br />
# la mise en réseau de plus en plus globale de ces ordinateurs : le '''catenet''', avec ses technologies de gestion (ex. '''internet''') et ses applications (ex. '''web''', etc.)<br />
# la concaténation "noosphèrique" des réseaux naturels et artificiels : la société "'''anthropobotique'''" des cerveaux humains et mécatroniques (bots) que devient la nôtre.<br />
<br />
Cela signifie qu'avec l'aide du brainware, le "noogitiel du savoir utiliser les capacités intellitives du catenet partagé global', '''tout''' peut : <br />
:* '''être su''' <br />
:* et que ce savoir peut être '''trompé'''.<br />
<br />
Rien de bien nouveau sous le soleil : c'est l'antique "vu, su, cru".<br />
<br />
== Singularité sociétale ==<br />
<br />
Ceci représente toutefois un saut au niveau quantitatif de la complexité de ce qui doit être conjointement traité. Ce seuil, franchi avec l'aide de la machine, est un point de non-retour, une '''singularité''' dans l'évolution de la société humaine. C'est-à-dire une '''extension''' de ce qui lui devint '''nécessaire''' pour exister et survivre. Ce qui réclame une certaine attention.<br />
<br />
Les précédentes singularités ont sans doute été <br />
* la '''science''' : la capacité de gérer l''''information''', <br />
* la '''sémiotique''' : la capacité à la '''communiquer''',<br />
* et la '''syllogistique''' : la capacité du discours à inférer, que notre cérébrique a dû intellectuellement limiter à la linéarité de la '''raison logique'''.<br />
<br />
Notre singularité actuelle est baptisée "'''technologique'''" et l'un des chantres le plus connus est '''[http://fr.wikipedia.org/wiki/Raymond_Kurzweil Raymond Kurzweil]''' de chez Google. <br />
<br />
En fait elle n'est pas l'apport général de capacités techniques nouvelles, mais l'approfondissement de la pénétration de la complexité grâce à la facilitation/extension apportée par la machine en réseau<br />
* à notre '''logique du tiers exclu''' (dialectique, entre toi et moi) <br />
* vers l''''agorique''' ("''mathématique de la foule''") '''au tiers non exclu'''" (polylectique de l'omnipartieprenance : tous et chacun et tous leurs actes sont concernés, reconnus, et considérés).<br />
<br />
== Le risque d'erreur ==<br />
<br />
Il est normal que nous soyons mal à l'aise face à des problématiques nouvelles où certains prennent de l'avance sur le momentum général. Il s'en suit une '''hystérésis''' naturelle qui crée des '''distorsions dynamiques''' du '''local''' vis-à-vis du '''global'''. <br />
<br />
Ceci est général et s'observe dans tous les domaines. Leurs effets s'appellent la crise, les déportations, les guerres culturelles, le terrorisme.<br />
<br />
Il s'agit du phénomène de base de l'évolution par '''émergence''' qui s'appelle l''''[http://fr.wikipedia.org/wiki/Auto-organisation auto-organisation]'''. Il est ici à l'échelle de la société humaine. Il a été mathématiquement introduit par '''René Thom''' selon une théorie qu'un mathématicien américain enthousiaste a promue sous le nom de '''[http://fr.wikipedia.org/wiki/Th%C3%A9orie_des_catastrophes théorie des catastrophes]'''. Elle permet de comprendre ce qui se passe dans un contexte de singularités et d'auto-organisation critique, mathématiquement appelé "catastrophe", c'est à dire lorsque l'analogique de la continuité se trouve confronté au catalogique (cela se casse) d'une discontinuité. Quand on coupe le cordon.<br />
<br />
Le risque d'erreur est partout dans un environnement nouveau, surtout lorsqu'il s'agit de l'humanité (même si l'expression "'''post-humain'''" des méridionaux californiens semble exagérée). Il sera d'abord dans sa perception par ses acteurs lorsqu'ils se réfèreront en commun, volontairement, manipulés, ou par ignorance, à des conceptions, des compréhensions, des mots (ce que l'on appelle un '''paradigme''') ne correspondant pas au niveau cérébrique en cours.<br />
<br />
C'est ce qui se passe actuellement, sous la '''pression politique''' américaine et économique (ICANN/DAVOS), quand <br />
:* on confuse la cérébrique de "niveau 2 - raisonnement en '''assemblée'''",<br />
:* ayant une expérience inégale de la cérébrique de "niveau 3 -'''ordinateur'''", <br />
:* et inexistante du "niveau 4 - '''OPES/ONES'''" en réseaux eux-mêmes cyberpénétrables, <br />
* pour leur faire décider dans l'urgence <br />
:* de la constitution sociale de cérébrique de "niveau 5 - '''société nationale'''" et notre protection à tous, <br />
:* dans un contexte '''esthétique''' (ce que l'on veut) <br />
:* et donc '''éthique''' et '''éthitechnique''' (comment nous et nos machines devons faire pour y parvenir)<br />
* '''flou''' et '''non''' démocratiquement '''réfléchi''', <br />
* contre qui ? des poseurs de bombes, des poseurs de bugs ou des poseurs de faux ?<br />
* voire en '''contradiction''' avec <br />
:* nos engagements internationaux ('''Engagement de Tunis''' du Sommet Mondial pour la Société de l'Information - SMSI) <br />
:*et nos '''fondements constitutionnels''' (Charte de l'Environnement - Droit et Devoir de '''Précaution''').<br />
<br />
== Les arroseurs arrosés ==<br />
<br />
Face à l'utilisation d'une innovation peu encore maîtrisée, la première des précautions est l''''expérimentation''' préalable sur un banc-test réduit. Ceci permet de mieux comprendre les dérives et les effets pervers possibles.<br />
<br />
Dans le cas d'une mal-loi, il est probable que le législateur peu informé, et au moins partiellement manipulé sous d'excellents prétextes soit la première victime de son imprécaution. <br />
<br />
Il faut se souvenir que l'intellition n'est qu'une science. Son propos est traquer la crédibilité, ou d'être utilisée pour la construire, pas d'assurer la vérité. Discener et décider de la vérité est le rôle du Juge. Pas de machines. <br />
<br />
Si j'avais à détruire ou à contrôler la France, j''''encouragerais la mal-loi''' et je commencerais à développer un '''virus sémantique''' pour la cérébrique digitale de ses ONES. <br />
<br />
Peut-être le prochain Tom Clancy, Richard Clarke ?</div>Sysophttp://iuwg.net/index.php/OPES/ONESOPES/ONES2015-04-13T23:23:52Z<p>Sysop: /* Links and Documents */</p>
<hr />
<div>Nos politiques ne savent pas bien de ce quoi ils parlent. Pour les aider, <br />
* dans leur considération de leur "'''[[mal-loi]]'''"<br />
* voici une explication courte de ce que sont leurs "'''[[EXP:OPES|boites noires]]'''"<br />
* et l'ouverture d'un '''[[AlgoJJU|Le débat sur l'AlgoJJU]]<br />
<br />
<br />
__TOC__<br />
<br />
<br />
{{LERDA}}<br />
<br />
== RFCs ==<br />
<br />
* RFC 3238 - IAB Architectural and Policy Considerations for Open Pluggable Edge Services<br />
* RFC 3705<br />
* RFC 3752 - Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios <br />
* RFC 3835 - An Architecture for Open Pluggable Edge Services (OPES) <br />
* RFC 3836 - Requirements for Open Pluggable Edge Services (OPES) Callout Protocols <br />
* RFC 3837 - Security Threats and Risks for Open Pluggable Edge Services (OPES)<br />
* RFC 3838 - Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) <br />
* RFC 3897 - Open Pluggable Edge Services (OPES) Entities and End Points Communication<br />
* RFC 3914 - Open Pluggable Edge Services (OPES) Treatment of IAB Considerations <br />
* RFC 4037 - Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core <br />
* RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES)<br />
* RFC 4902 - Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP<br />
* [http://tools.ietf.org/html/draft-ietf-opes-rules-p-02 draft-ietf-opes-rules-p-02] P: Message Processing Language<br />
<br />
== Links and Documents ==<br />
<br />
* [http://www.planethofmann.com/markus/publications/papers/ieee-internet-computing.pdf Open Pluggable Edge Services - An Architecture for Networked Content Services]] Markus Hofmann (Bell Labs/Alcatel-Lucent) Leland R. Beaumont (Simply Quality)<br />
<br />
* [https://www.isoc.org/briefings/005/ OPES: ISOC Briefing] <br />
* (fr) [http://fr.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol ICAP Protocol]<br />
* (en) [http://en.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol ICAP Protocol]<br />
* (fr) [[20150419 - Lettre aux parlementaires]] ''(Projet)''<br />
<br />
== IUDOCs ==<br />
<br />
Les IUDOCs sont les futurs chapitres d'une documentation d'utilisation intelligente du Catenet par les différentes technologies, solutions communes, innovations en cours de discussion.<br />
<br />
* ''A cette date aucun document de publié. Une réflexion en cours pour le développement d'un OPES d'encryption et de routages multiples dans le cadre de VGN (Virtual Glocal Networks) privés.''<br />
* ''L'idée de base est le montage d'une expérimentation réseau au niveau Catenet (''sous-structure multitechnologiques'') opposant la technologie et l'émulation d'un strict respect de la loi afin d'en recherche et documenter les difficultés constitionnelles possibles.''</div>Sysophttp://iuwg.net/index.php/Poles_of_research_and_documentation_(PRDs)Poles of research and documentation (PRDs)2015-04-13T23:16:56Z<p>Sysop: </p>
<hr />
<div><br />
At this stage the IUWG proceeds by thematic domains, aiing at gathering and extending a lead user documentation in specialized area of particular unnovative interest, until it may offer a comprehensive and maintained "catenet book" covering the entire catenet architectonics.<br />
<br />
;[[BLCP]]: Portal of the work on BLCP (Bare Local Catenet Protocol) for the [http://catenet.org CATENET Scic] initiative.<br />
<br />
;[[OPES/ONES]]: Open pluggable edge services and open networks of edge services.<br />
<br />
; VGN: Virtual Glocal Networks.<br />
<br />
; MDRS : MetaData Reference System.<br />
<br />
;Software defined networking : <br />
:* [http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp13084.html CISCO R&D]<br />
<br />
;NDN : Named Data Networks.<br />
:* [http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp12071.html CSICO R&D]<br />
<br />
;Meshed Networking : locally distributed resillent network systems.<br />
<br />
;Extended Services : <br />
:* [http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp12074.html CISCO R&D]</div>Sysophttp://iuwg.net/index.php/DocumentsDocuments2015-04-10T15:28:36Z<p>Sysop: /* US NTIA to FCC transition */</p>
<hr />
<div><br />
== US NTIA to FCC transition ==<br />
<br />
* '''[[Consensus declared -- IETF IANAPLAN WG input to the ICG request for comments]]<br />
* '''[[The 36 questions]]'''<br />
* '''[http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf IANAPLAN Appeal to the IESG]''': this appeal (entitled "iana.arpa 404") concerns the disambiguation of the IESG approved for RFC publication WG/IANAPLAN Draft. It was '''[[Letter to Lawrence E. Strickling, Assistant Secretary, NTIA|introduced to Lawrence E. Strickling, Assistant Secretary, NTIA]]'''.<br />
:* '''[[explication française]]'''<br />
:* '''[[IANAPLAN Appel à l'IESG - Historique]]<br />
:* '''[[Schéma de pensée de l'appel "iana.arpa 404"]]'''<br />
:* [[20150416 - Réponse de l'IESG]] -- '''[[Acknowledgment of the IESG dilatory reponse]]''' (begining of the escalation to the IAB, and then ISOC). <br />
:* [[20150424 - JFCM's Response to Seun Odjedji and Andrew Sullivan]]<br />
:* [[20150530 - I*Chairs report]]<br />
<br />
* [[IETF Fork]] - not as in opposition, but as in generation.<br />
<br />
* [http://iuwg.net/dir/tech_letter_on_cisa_final.pdf Tech Letter on CISA (USA)]</div>Sysophttp://iuwg.net/index.php/CatenetCatenet2015-03-28T16:03:06Z<p>Sysop: Created page with "{| |width="600"| |width="50"| |width="600"| |- |valign="top"| <!--fr--> maillage/concaténation global des resources partagées du réseau des réseaux digitaux. (''Concept in..."</p>
<hr />
<div>{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
maillage/concaténation global des resources partagées du réseau des réseaux digitaux. (''Concept introduit par Louis Pouzin en 1973'')<br />
<!--/fr--><br />
|valign="top"|<br />
<!--en--><br />
<br />
<!--/en--><br />
|valign="top"|<br />
<!--en--><br />
global meshing/concatenation of the digital network of networks shared resources (''Concept introduced by Louis Pouzin in 1973'').<br />
<!--/en--><br />
|}</div>Sysophttp://iuwg.net/index.php/R%26D_-_Liens_%26_LinksR&D - Liens & Links2015-03-26T16:58:51Z<p>Sysop: Created page with " * [https://sites.google.com/site/imaginouest/colloque-imaginaire-savoirs-connaissance/societes-post-modernes-et-numerisphere Sociétés post modernes et numérisphère] - Geo..."</p>
<hr />
<div><br />
* [https://sites.google.com/site/imaginouest/colloque-imaginaire-savoirs-connaissance/societes-post-modernes-et-numerisphere Sociétés post modernes et numérisphère] - Georges Bertin.</div>Sysophttp://iuwg.net/index.php/Some_Principles_of_the_Internet_-_Jay_HaubenSome Principles of the Internet - Jay Hauben2015-03-26T16:41:42Z<p>Sysop: Created page with "Some Principles of the Internet<br/> by Jay Hauben<br/>jrh@ais.org == Introduction == Before 1973, the idea of an Internet had not yet been proposed. As of 2000, over 200 m..."</p>
<hr />
<div>Some Principles of the Internet<br/><br />
by Jay Hauben<br/>jrh@ais.org <br />
<br />
== Introduction ==<br />
<br />
Before 1973, the idea of an Internet had not yet been proposed. As of<br />
2000, over 200 million people worldwide actively use this<br />
communications system. The Internet consists of these people and more<br />
than one million packet switching networks with very many different<br />
characteristics, interconnecting more than 100 million computers as<br />
nodes. Yet the Internet is still young. With care taken about its<br />
scientific basis and technological principles it has the potential to<br />
keep expanding for many years to come. But there are many aspects of<br />
Internet technology that must be protected for further growth to<br />
occur. In particular, the acceptable unreliability at the internetwork<br />
level is unique and differentiable from other telecommunications<br />
network technologies such as the telephone system. Also the scaling of<br />
the Internet to meet the expected increase in demand for its use is in<br />
no way assured. To better understand this new means of communication<br />
and help protect its growth, it is worthwhile to look for the<br />
principles upon which it has been developed.<br />
<br />
<br />
__TOC__<br />
<br />
== History ==<br />
<br />
High speed, digital computers first appeared in the US in any numbers<br />
in the early 1950s. By the end of that decade, such computers were so<br />
large and so expensive that they were operated almost exclusively for<br />
machine efficiency. That meant that few people used the computers<br />
interactively. Instead programmers and users submitted their programs<br />
on punched cards or tapes to computer centers. There, operators lined<br />
the jobs up and feed them to the computer, job after job. Sometime<br />
later the output was available for the user or programmer to retrieve<br />
and examine. This mode of use was called "batch processing". It may<br />
have seemed efficient in terms of machine utilization. But, from the<br />
point of view of human users who waited time intervals of the order of<br />
hours or days for responses to their jobs, it was woefully<br />
inefficient. Batch processing was particularly frustrating for<br />
programmers trying to correct errors in their work.<br />
<br />
In the early 1960s, a major improvement in efficiency for both humans<br />
and computers was achieved by the development of the "time-sharing"<br />
mode of computer operation. Taking advantage of the great processing<br />
speed of transistorized computers, this new mode allowed a set of<br />
users to simultaneously access the same computer. Computer processing<br />
time was now parceled out in very small intervals and made available<br />
to the users in round-robin fashion. Each user was offered his or her<br />
short time slots in turn so rapidly that each had the illusion of<br />
being the sole user of the computer. Time-sharing made possible wide<br />
spread interactive use of computers.<br />
<br />
As time-sharing systems began to become more available, some computer<br />
pioneers realized that two time-sharing computers could be connected,<br />
each appearing to the other as just another user. By so doing, all the<br />
users on both systems shared the resources available on the two<br />
computers which included the other users. To test how large a system<br />
might eventually be possible, a cross country hookup of such systems<br />
was attempted in 1965 using long distance telephone lines. The result<br />
was a success for long distance time-sharing computer networking but<br />
the call set ups and tear downs of the telephone system created time<br />
delays that were unacceptable for actual use of such a network.<br />
<br />
Telephone switching requires the setup of a complete and dedicated<br />
path or circuit before actual end-to-end communication starts to take<br />
place. Such communication technology is known as "circuit switching".<br />
The problem is that computer data is often bursty or a message of<br />
minimal size as when a single key stroke is sent to solicit a<br />
response. Therefore computer data communication over normal switched<br />
telephone lines requires frequent call setups or wasteful quiet times.<br />
A solution suggested by queuing theory and other lines of reasoning<br />
was "packet switching" as opposed to circuit switching. Data to be<br />
communicated from a number of sessions could be broken into small<br />
packets which would be transmitted interspersed, each routed to its<br />
destination separately without setting up a path for each packet. Once<br />
at the destination, the packets are reassembled to create an exact<br />
copy of the original message. Experimentation with packet switching<br />
technology was initiated in Europe and the US starting in 1969 which<br />
confirmed the prediction of great efficiency.<br />
<br />
Best known of the early packet switching computer networks were the<br />
ARPANET in the US, Cyclades in France, and the National Physical<br />
Laboratory network in the UK. The ARPANET designers and researchers<br />
succeeded in achieving resource sharing among time-shared computers<br />
manufactured by different vendors and using different operating<br />
systems, character sets, and so forth. The computers were located at<br />
universities and military related research laboratories. The ARPANET<br />
was funded and encouraged by the Information Processing Techniques<br />
Office (IPTO) of the Advanced Research Projects Agency (ARPA), a<br />
civilian agency within the US Department of Defense. ARPA/IPTO also<br />
funded and encouraged packet switching experimentation using ground<br />
based radio receivers and transmitters and using satellites.<br />
<br />
== Internetting and Catenet ==<br />
<br />
In the early 1970s, in Europe, a number of packet switching network<br />
experiments were undertaken. In Hawaii, a successful packet radio<br />
network, the ALOHANET, was developed. In the US, encouraged by the<br />
success of the ARPANET, commercial networks like Tymnet and Telenet<br />
were attempted. Just as isolated time-shared computers suggested<br />
networking, the existence of isolated packet switching networks,<br />
suggested the possibility of some sort of interconnectivity. Robert<br />
Kahn in the US and Louis Pouzin in France were among the first to<br />
consider what needed to be done to create such a meta network or<br />
internet of networks. Kahn at ARPA/IPTO developed the Internetting<br />
Project and Pouzin in France developed the concept of a Catenet.<br />
<br />
The goal of the Internetting Project was to develop an effective<br />
technology to interconnect the packet switching data networks that<br />
were beginning to emerge from the experimental stage. It rejected the<br />
alternative of integrating all networks into one single unified<br />
network. The later might have produced better integration and<br />
performance but would have limited the autonomy and continued<br />
experimental development of new network technologies. Also, the<br />
developing networks were under different political and economic<br />
administrations and it is not likely they could have been enticed to<br />
give up their autonomy to voluntarily join together as part of a<br />
single network.<br />
<br />
Kahn had been involved in trying to solve a problem of great<br />
complexity: could a ground based packet radio network be developed<br />
that would even allow mobile transmitters and receivers? The<br />
complexity was that radio communication is prone to fading,<br />
interference, obstruction of line-of-site by local terrain or blackout<br />
such as when traveling through a tunnel. A radio signal link is by its<br />
nature inherently unreliable in itself for data communication. Crucial<br />
therefore to the success of such a packet radio network would be an<br />
end-to-end mechanism that could arrange for retransmissions and employ<br />
other techniques so that a reliable communication service could be<br />
provided despite the unreliability of the underlying link level.<br />
<br />
Pouzin had worked on the time-sharing experiments at MIT in the 1960s.<br />
He was impressed by the successful way individual users were<br />
'networked' on a single time sharing computer and then how these<br />
computers themselves were networked. He looked for the essence of<br />
packet switching networks to give the clue how they could be<br />
interconnected. He saw many features which were not mandatory to<br />
packet switching such as virtual circuits, end-to-end acknowledgments,<br />
large buffer allocations, and so forth. He felt that any end-to-end<br />
function which users might desire could be implemented at the user<br />
interface. The Catenet need only provide a basic service, packet<br />
transport.<br />
<br />
== Principles for an Internet ==<br />
<br />
How then to achieve an effective interconnection of packet switching<br />
networks? If the interconnection was to include packet radio networks<br />
the resulting internet would have at least some unreliable links.<br />
Should packet radio networks and others that could not offer reliable<br />
network service be excluded? Kahn's answer was that the new<br />
interconnection should be open to all packet switching networks. That<br />
was the first principle of the Internet that was to emerge: open<br />
architecture networking the interconnection of as many current and<br />
future networks as possible by requiring the least commonality<br />
possible from each (Leiner, et al, 1998). Each network would be based<br />
on the network technology dictated by its own purpose and achieved via<br />
its own architectural design. Networks would not be federated into<br />
circuits that formed a reliable end to end path, passing individual<br />
bits on a synchronous basis. Instead, the new "internetworking<br />
architecture" would view networks as peers in helping offer an<br />
end-to-end service independent of path or of the unreliability or<br />
failure of any links.<br />
<br />
:"Four ground rules were critical to Kahn's early thinking: <br />
::* Each distinct network would have to stand on its own and no internal changes could be required to any such network to connect it to the Internet.<br />
::* Communications would be on a best effort basis. If a packet didn't make it to the final destination, it would shortly be retransmitted from the source.<br />
::* Black boxes would be used to connect the networks; these would later be called gateways and routers. There would be no information retained by the gateways about the individual flows of packets passing through them, thereby keeping them simple and avoiding complicated adaptation and recovery from various failure modes.<br />
::* There would be no global control at the operations level."<br />
::: (Leiner et al, 1998)<br />
<br />
Pouzin and his colleagues developed a set of ground rules and applied<br />
them in the development of the Cyclades network. On an experimental<br />
basis, they connected Cyclades with the National Physical Laboratory<br />
(NPL) in London in August 1974, with the European Space Agency (ESA)<br />
in Rome in October 1975 and with the European Informatics Network<br />
(EIN) in June 1976 (Pouzin, 1982). Pouzin's team implemented a packet<br />
service which did not assume any interdependence between packets. Each<br />
packet was treated as a separate entity moving from source to<br />
destination according to the conditions prevalent at each moment of<br />
its travel. There would be dynamic updating of the routing at the<br />
gateways and retransmissions because of congestion or link or node<br />
failures. Sometimes the packets would arrive at their destinations out<br />
of order or duplicated or with some packets missing from a sequence.<br />
The gateways were programmed to make an effort to keep the packets<br />
moving toward the source but no guarantee of delivery service was<br />
built into them. Such a best effort transmission service is called a<br />
datagram service.<br />
<br />
In the past, out of sequence packets, packet duplication and packet<br />
loss were considered at least a burden if not serious problems, so<br />
communication switches were designed to prevent them. Now producing<br />
end-to-end acknowledgment and retransmission mechanisms rectified<br />
these events. In this way substantial simplicity, cost reduction and<br />
generality of the service that gateways provided was achieved. By<br />
requiring gateways to provide only a datagram service, the<br />
interconnection of networks was reduced to its simplest, most<br />
universally applicable technology. This was a second Internet<br />
principle: as little demand as possible is put on the Internet<br />
gateway; or stated conversely, as much as possible be done above the<br />
internetwork level. This came to be called the "end-to-end principle"<br />
(Carpenter, 1996). It provided for successful communication under<br />
almost any condition except the total failure of the whole system.<br />
Another way to state this principle was that the information about a<br />
communication session (state information) would be at the end points.<br />
Intermediate failures could not destroy such information. Disrupted<br />
communication resulting from such failures could be continued when the<br />
packets began to arrive again at the destination.<br />
<br />
In October 1972, Kahn had organized a large public demonstration of<br />
the ARPANET at the International Computer Communications Conference<br />
(ICCC72) in Washington, DC. This was the first international public<br />
demonstration of packet switching network technology. Researchers were<br />
there from Europe, Asia, and North America. At the meeting, an<br />
International Network Working Group (INWG) was established to share<br />
experiences and be a forum to help work out standards and protocols.<br />
In 1973-74, the INWG was adopted by the International networking<br />
professional organization, the International Federation of Information<br />
Processing (IFIP) as its Telecommunications Committee Working Group<br />
6.1 (IFIP/TC 6.1). Researchers around the world knew of each other's<br />
work and the work of others who were considering these problems by<br />
attending and presenting papers at meetings of the IFIP/TC 6.1 and<br />
sharing their work with each other on a regular basis. This is an<br />
early example of openness and collaboration. This was to become a<br />
third principle of the Internet: open and public documentation and<br />
open and cooperative standards and protocol development. [See RFC 2555<br />
in this issue.]<br />
<br />
== TCP/IP and the Internet ==<br />
<br />
In 1973, Kahn brought Vinton Cerf into the work on internetting.<br />
Together they sought a general solution to the internetting problem.<br />
They aimed to set specifications for what was needed in common on the<br />
end computers and the gateways so that the interconnection would be<br />
successful. The set of such specifications is called a communication<br />
protocol. At first, this protocol was called Transmission Control<br />
Protocol (TCP). Cerf and Kahn first shared their thinking in a formal<br />
way at a meeting of the INWG members who were in Brighton, England in<br />
September, 1973 and then in the article "A Proposal for Packet Network<br />
Intercommunication" (Cerf and Kahn, 1974). What they envisioned was a<br />
reliable, sequenced, data stream delivery service provided at the end<br />
points despite any unreliability of the underlying internetwork level.<br />
<br />
The first implementation of TCP only resulted in packets traveling in<br />
a circuit like internetwork service. For some network services such<br />
virtual circuits were too restrictive. At the time it was argued by<br />
Danny Cohen who was working on packet voice delivery that TCP<br />
functionality should be split between what was required end-to-end,<br />
like reliability and flow control, and what was required hop-by-hop to<br />
get from one network to another via gateways. Cohen felt packet voice<br />
needed timeliness more than it needed reliable delivery. This led to<br />
the reorganization of the original TCP into two protocols, Internet<br />
Protocol (IP) and the Transport Control Protocol (TCP). The simple IP<br />
provided for addressing, fragmentation and forwarding of individual<br />
packets. The separate TCP provided for recovery from out of sequence<br />
and lost packets.<br />
<br />
A major boost to the use of what became known as TCP/IP was its<br />
adoption by the US Department of Defense (DOD). The DOD funded work in<br />
1979-80 that incorporated TCP/IP into modifications of the Unix<br />
operating system being made at the University of California at<br />
Berkeley. When this version of Unix was distributed to the<br />
universities and other sites that had adopted the Unix operating<br />
system, much of the computer science community in the US and around<br />
the world began to have TCP/IP capability built into its operating<br />
systems. This was a great boost for broad adoption of the Internet. It<br />
is also another example of the principle of free and open documenta<br />
tion, in this case open Unix source code. The DOD required all users<br />
of the ARPANET to adopt TCP/IP by January 1, 1983, further insuring<br />
that it would be broadly implemented. The transition to TCP/IP was not<br />
easy but by April 1, 1983 was pretty much successful.<br />
<br />
A key element of the design of IP is the capability at each gateway to<br />
break packets too large for the next network into fragments that will<br />
fit in the next network's network frames. These fragments then travel<br />
along as ordinary datagrams until they are reassembled at the<br />
destination host. By allowing for fragmentation, IP makes it possible<br />
for large packet handling and small packet handling networks to<br />
coexist on the same Internet. This is an example of applying the open<br />
architecture principle. Allowing fragmentation relieves the necessity<br />
of specifying a minimum or a maximum packet size (although in practice<br />
such limits do exist). Leaving the reassembly until the destination<br />
minimizes the requirements on the gateway/routers. Schemes that would<br />
eliminate fragmentation from future versions of IP should be carefully<br />
scrutinized because they may cause the obsoleting of under resourced<br />
networks that could not adapt to the mandated packet sizes. That would<br />
violate the open architecture principle.<br />
<br />
== Conclusion ==<br />
<br />
The highest order feature a communications system can provide is<br />
universal connectivity. This has been up until the present the guiding<br />
vision and goal of the Internet pioneers. Leonard Kleinrock has argued<br />
that "as the system resources grow in size to satisfy an ever<br />
increasing population of users" gains in efficiency occur (1976, p.<br />
275). This is an example of the law of large numbers which suggests<br />
that the more resources and users there are, the more sharing there<br />
is. This results in a greater level of efficient utilization of<br />
resources without increased delays in delivery. So far the scaling of<br />
the Internet has conformed to the law of large numbers and provides a<br />
remarkably inexpensive, convenient and efficient communications<br />
system. Also the desire for connectivity grows with the Internet's<br />
growth as does its value since with its growth comes more connectivity<br />
for those who have already been connected as well.<br />
<br />
In its first 25 years (1973-1998) the Internet grew to provide<br />
communication to 2.5% of the world's people. This is a spectacular<br />
technical and social accomplishment. But much of the connectivity is<br />
concentrated in a few parts of the world (North America, Europe and<br />
parts of Asia). The web of the Internet's connectivity is also still<br />
sparse even in North America. Often, even though there is sufficient<br />
total bandwidth, there are too few alternative paths so that the<br />
communication service available has uncomfortably long delays.<br />
<br />
Top priority for the Internet policy, computer science and technical<br />
communities is to find ways of continuing the growth and scaling of<br />
the connectivity provided by the Internet. But the principle of<br />
universal connectivity to a global Internet communications system is<br />
being challenged by those who want instead to convert the Internet<br />
into an e-commercenet. The Internet is a new and different technology,<br />
making possible a meta-level interconnection of independent networks.<br />
To achieve the necessary further scaling, the Internet will require a<br />
large pool of well supported, talented and highly educated scientists<br />
and engineers who have studied the principles and unique features of<br />
the Internet and who are dedicated to its essence as a communications<br />
system. It will also require government policy makers who understand<br />
the technology and its social implications or who listen to advisors<br />
with such knowledge. All will need to work collaboratively online and<br />
off line to hold each other to the principles as they seek solutions<br />
to the current and future problems. Then the Internet has a chance of<br />
reaching the goal of its pioneers, universal connectivity.<br />
<br />
== Bibliography ==<br />
<br />
Carpenter, B. RFC 1958: Architectural Principles of the Internet. <br />
June, 1996<br />
<br />
Cerf, Vinton G. and Robert Kahn. "A Protocol for Packet Network<br />
Intercommunication". IEEE Transactions on Communications, Vol. <br />
Com-22, No 5. May, 1974.<br />
<br />
Cerf, Vinton G. IEN48: The Catenet Model for Internetworking. July,<br />
1978. http://lwp.ualg.pt/htbin /ien/ien48.html<br />
<br />
Clark, David D. "The Design Principles of the DARPA Internet<br />
Protocols". Proceedings SIGCOMM88 ACM CCR Vol 18 #4. August, 1988.<br />
<br />
Comer, Douglas E. Internetworking with TCP/IP Vol I: Principles,<br />
Protocols, and Architecture 2nd Edition. Englewood Cliffs, NJ.<br />
Prentice Hall. 1991.<br />
<br />
Comer, Douglas E. The Internet Book: Everything You Need to Know about<br />
Computer Networking and How the Internet Works. Englewood Cliffs, NJ.<br />
Prentice Hall. 1995.<br />
<br />
Davies, D. W., D. L. A. Barber, W.L. Price C.M. Solomonides. <br />
Computer Networks and Their Protocols. Chichester. John Wiley & Sons.<br />
1979.<br />
<br />
Hauben, Michael and Ronda Hauben. Netizens: On the History and Impact<br />
of Usenet and the Internet. Los Alamitos, CA. IEEE Computer Society<br />
Press. 1997<br />
<br />
Kleinrock, Leonard. Queuing Systems Volume II: Computer Applications.<br />
New York. John Wiley and Sons.1976.<br />
<br />
Leiner, Barry M., et al. "A brief History of the Internet" at<br />
http://www.isoc.org/internet/history/brief.html<br />
<br />
Lynch, Daniel C. and Marshall T. Rose. Editors. Internet Systems<br />
Handbook. Reading, MA. Addison-Wesley. 1993.<br />
<br />
Pouzin, Louis. "A Proposal for Interconnecting Packet Switching<br />
Networks". Proceedings of EUROCOMP. Brunel University. May, 1974.<br />
Pages 1023-36.<br />
<br />
Pouzin, L. Ed. The Cyclades Computer Network. Amsterdam. North<br />
Holland. 1982.<br />
<br />
Stevens, W. Richard. TCP/IP Illustrated, Vol 1 Protocols. Reading,<br />
MA. Addison-Wesley. 1994.<br />
<br />
<br />
----<br />
<br />
<br />
Reprinted from the Amateur Computerist Vol 10 No 1 Spring/Summer 2000. <br />
The whole issue or a subscription are available for free via email. <br />
Send a request to jrh@ais.org or see http://www.ais.org/~jrh/acn/</div>Sysophttp://iuwg.net/index.php/INWG_and_the_conception_of_the_Internet_-_Alex_McKenzieINWG and the conception of the Internet - Alex McKenzie2015-03-14T18:38:05Z<p>Sysop: /* Internet Protocol Proposals */</p>
<hr />
<div>INWG and the Conception of the Internet: An Eyewitness Account<br />
<br />
'''Alexander McKenzie'''<br />
<br />
1972 was an exciting year in computer networking. The ARPANET, which came to life near the end of 1969, had grown to 29 nodes by August 1972. The National Physical Laboratory in England, under the direction of Donald Davies, had been running a 1-node packet switch interconnecting several NPL computers for several years. The French Research Laboratory IRIA, under the direction of Louis '''Pouzin''', had begun the implementation of a packet-switched system called Cyclades.<br />
<br />
:''In February [http://www.computerhistory.org/revolution/mainframe-computers/7/181/724 1972, Tymnet] also issued the first invoice for network access services to the NLM of Bethesda.''<br />
<br />
In July 1972, three people associated with the ARPANET work at BBN formed a new company, Packet Communications, “to engage in the business of providing communication services for computer to terminal, computer to computer, [and] terminal to terminal information transfer.”1 In November 1971 the European Common Market announced the intention to build a European Informatics Network (EIN) for research and scientific purposes under the direction of Derek Barber from NPL, and planning was underway in 1972. Several national post, telephone, and telegraph (PTT) organizations were beginning to consider building national common-user data networks using packet-switching technology. These included the British Post Office’s Experimental Packet Switched System (EPSS), RCP (French PTT), and a small experimental packet-switched network (PSN) built by the Norwegian PTT during 1971 to 1972 and used for experiments for three months.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
== Formation of INWG ==<br />
<br />
The people responsible for all these networks converged on the first International Conference on Computer Communication held in Washington D.C. during October 1972. There was a live demonstration of the ARPANET in a ballroom of the conference hotel, which created great excitement.2 And with a push from Larry Roberts of DARPA, a group of network designers met to talk about how all these networks could be interconnected. On 24 October, these designers met to form what they called the International Packet Network Working Group (INWG),3 modeled on the ARPANET NWG, and began the publication of a series of numbered INWG notes modeled on the ARPANET request for comments (RFCs). Larry Roberts volunteered to have the ARPANET Network Information Center (NIC) distribute the notes to INWG members.4 '''Vint Cerf''' volunteered to be temporary chairman/secretary. The group divided into two subgroups to consider “Communication System Requirements” and “HOST-HOST Protocol Requirements;” the reports of these subgroups are INWG 1 and INWG 2.<br />
<br />
Subgroup 1 agreed that its job was as follows:<br />
<br />
#To consider what requirements must be met by the packet switching networks to allow convenient communications between computers and terminals when that communication takes place through more than one network.<br />
#To consider what recommendations to make on packet-switching networks, and how to provide for acceptance of these recommendations through CCITT and other international organizations […]5<br />
<br />
Specific discussions included these questions:<br />
:*Should a network provide a message service (such as ARPANET) or a packet-only service (such as Cyclades)?<br />
:*Should a network provide an interface to a “host” computer, to a simple terminal, or both?<br />
:*Can a packet size that could be handled by all “current” networks be required as “a lower limit for the maximum packet size of future networks” that wish to participate in interconnection?<br />
:*Flow control has aspects that only apply to end-to-end operation and aspects that enable “a network … to protect itself against congestion.” How tightly coupled should these be?<br />
<br />
Subgroup 2 agreed to review existing protocols6 by exchanging technical documents with the intent of meeting the following (ordered) set of objectives:<br />
# Define which issues must be resolved by HOST-HOST protocol.7<br />
# Select a design philosophy.<br />
# Design the HOST-HOST protocol.<br />
# Agree to implement the protocol design by a certain date.<br />
# Make implementation recommendations.<br />
<br />
During the next few months, INWG notes included documents from CCITT (study of “packet mode operation” during 1972–1976), Japan (link types), France (French PTT experimental packet network, congestion control, and addressing), UK (congestion control, NPL network documentation, and specifications for EPSS), and US (ARPANET throughput analysis and measurement and IMP flow control mechanisms). Particularly interesting was '''Pouzin'''’s observation in INWG 20 that a packet’s source and destination address is not identical to a “network interface address.” “Each communication software [must] be identified individually even if it is necessary to go through a common line or common computer to reach it.” This was a concept that was particularly misunderstood by the PTTs.<br />
<br />
<br />
== Internet Protocol Proposals ==<br />
<br />
The second INWG meeting was held 7–8 June 1973 in New York in conjunction with the American Federation of Information Processing Societies (AFIPS) National Computer Conference. By this time, '''Pouzin''' had been instrumental in having INWG be chartered as Working Group 6.1 of the International Federation for Information Processing (IFIP) under Technical Committee (TC) 6, Data Transmission. [CLARIFICATION 2001/04/24 Both '''Pouzin''' and Alex Curran were involved. See http://www.historyofcomputercommunications.info/Book/6/6.4-TransmissionControlProtocol%28TCP%2973-76.html.] This sponsorship gave INWG (as IFIP WG 6.1) standing to participate directly in the deliberations of CCITT and ISO, providing technical input on packet networking. At the New York meeting, a small team of engineers8 with implementation experience in ARPANET (US), Cyclades (F), MERIT (US), and NPL (UK) created a first draft of an International Transmission Protocol (ITP). '''Vint Cerf''' served as the editor of this document, which was distributed as a set of supplements to INWG 28. An introduction stated:<br />
<br />
If we treat the computer communication system of each network as a complicated communication line joining HOSTs and Gateway[s], then the Gateways appear to be international nodes9, joined by 2 or more networks, facilitating communication between HOSTs.<br />
<br />
The international transmission protocol (ITP) described herein is intended to:<br />
<br />
# Be resistant to failures in intermediate constituent networks and gateways.<br />
# Be unaffected by the maximum message sizes permitted in constituent networks and by intra- and inter-network timing idiosyncrasies.<br />
# Be capable of exactly reconstituting a message stream originating in a foreign HOST.<br />
# Provide for high bandwidth and/or low delay transmission.<br />
# Require no status information in gateways.<br />
# Be relatively easy to implement.<br />
# Permit the receiving HOST to control the flow from the sending HOST.<br />
<br />
Messages are made up of a fixed length header, containing control and addressing information, an integral number of fixed length elements containing the text of the message, and space for an optional checksum.<br />
<br />
It is imagined that between pairs of HOST computers, a single logical connexion is established upon which is multiplexed all communications between these two HOSTs.” A “Transmission Control Program (TCP) [is defined as a] program in a HOST computer which realizes the International Transmission Protocol enabling a collection of messages from processes and terminals associated with one HOST to be multiplexed along a connexion to another HOST in the same or foreign network. The TCP does not address itself to the problem of interprocess … communication. The job of the TCP is merely to take a stream of messages produced by one HOST and reproduce the stream at a foreign receiving HOST without change.<br />
<br />
The draft specification described message format, including header fields for source address, destination address, left element ID (sequence number), bit count (of the text portion), element size (bits/element), acknowledgment (of traffic in the reverse direction), and type (user text, ITP control, or TCP status). It described a positive-acknowledgment, timeout, and retransmission scheme to insure reliable transmission, and a sliding window flow control scheme linked to the reliable transmission mechanism. It describes how a gateway can break a message received from a network with a large packet size into smaller pieces for transmission through a subsequent network with a smaller packet size without knowing anything about the message except for its header fields and checksum mechanism. It noted: “Clearly, it is necessary that all networks have the capability of sending a message consisting of the header, checksum, and one element.”<br />
<br />
About a month later, '''Vint Cerf''' and '''Bob Kahn''' distributed INWG 39, which they described as “an attempt to collect and integrate the ideas uncovered at the June 1973 INWG meeting in New York, as well as some ideas which have been worked out since that time by various other people.”10 Gone was the concept that the “TCP does not address … interprocess communication.” Addresses now include a portion that specifies an individual process/port. Each port-to-port association was now separately flow- and error-controlled. Messages are divided into segments by the source TCP, and a checksum is computed for each segment. Gateways did not recompute checksums if they had to break up a segment and so each packet carried a flag field that specified the following:<br />
<br />
:*This packet ends a source segment.<br />
:*This segment ends a source message.<br />
:*This message begins an association (synchronize on this sequence number).<br />
:*This message ends an association (deallocate resources).<br />
<br />
Because associations begin and end, there were some special problems selecting initial sequence numbers and acknowledging the data that arrives in the packet that ends an association. The “Type” field was omitted because the authors felt that the flag field specifies sufficient ITP control and TCP status information (although the flags are specific to an association).<br />
<br />
In October, '''Pouzin''' distributed INWG 42, a tutorial titled “Interconnection of Packet Switching Networks” that detailed the concepts that were being discussed in INWG. This paper introduced the term catenet (from concatenated network), defined as “an abstract PSN resulting from the juxtaposition of several PSNs.” '''Pouzin''''s view of gateways was summed up in the following quote: “We come to the conclusion that users and gateways cannot assume anything about other networks [in the catenet] but the simplest possible properties. The reason is that the gateways cannot give to networks properties that they do not have. They can only screen out undesirable properties.”<br />
<br />
In April 1974, '''Hubert Zimmermann''' and '''Michel Elie''', both members of the Cyclades project, distributed INWG 61, titled “Standard Host/Host Protocol for Heterogeneous Computer Networks.” This proposal built on the ideas of INWG 28 and INWG 39, papers that had been circulated within INWG during the second half of 1973, an earlier proposal outline (INWG 43) that they published in November 1973, and the output of a January 1974 INWG meeting in Hawaii. The terminology of this paper differed from INWG 28/39, but the basic assumptions were the same. Both INWG 39 and INWG 61 provided for multiplexing several logical data streams, fragmentation and reassembly of long information units, retransmission and acknowledgment, and both feedback flow control and explicit flow control.<br />
<br />
The major conceptual difference between the two proposals was in fragmentation and reassembly. INWG 39 assumed that each logical data stream could be viewed as a stream of 8-bit bytes (octets). The only restriction placed on an individual network regarding packet length was that it be at least long enough to carry the headers and checksum plus at least one octet of text. Hosts and gateways could fragment a message on any octet boundary. In contrast, INWG 61 assumed that every network could carry packets of at least 255 octets plus a “local network header” (if needed). Communication consisted of telegrams with 2 octets of data and letters of up to 128 fragments. All letter fragments (except perhaps the last) were the same length; when the length was combined with Internet headers and checksum there would be exactly 255 octets. The authors argued that fixed-length fragments would greatly simplify implementation. INWG 39 numbered individual octets for flow and error control; INWG 61 numbered letters (and fragments) for this purpose. Furthermore, INWG 61 made error and flow control options, which the application could choose for reliable transmission or omit for potentially lower delay. Finally, INWG 61 hosts were responsible for fragmentation, and no further fragmentation was required at gateways because all networks could carry a full fragment (by definition). <br />
<br />
In May 1974, the IEEE Transactions on Communications published “A Protocol for Packet Network Interconnection” by '''Cerf''' and '''Kahn'''. This was a greatly updated and refined version of INWG 39.<br />
<br />
INWG met again on 10–11 August 1974 in Stockholm. The meeting was attended by 32 people from 11 countries. It was reported that the protocol of INWG 61 was in the test stage, and the protocol of INWG 39 (updated) was in the detailed specification stage. It was also reported that plans were being made for experiments with the updated INWG 39 protocol at ARPA supported sites,11 and the INWG 61 protocol was being used for experiments between NPL and Cyclades using a Modula 1 computer at NPL as a gateway. Experiments with the INWG 61 protocol were being planned between Cyclades and EIN when EIN became operational in late 1975 or early 1976.<br />
<br />
== Synthesis of Competing Proposals ==<br />
<br />
In December 1974 I proposed a synthesis of the two protocols.12 I wrote:<br />
<br />
It might be argued that a synthesis of these protocols is counterproductive; that INWG should foster as many different protocol experiments as possible. In my view, however, there are almost no significant differences between the current formulations of these two ideas; thus independent experiments would produce little “light,” although possibly much heat. On the other hand, a synthesis of the two ideas has the potential for enlarging the community of experimenters, and thus increasing the probability of intensive study.<br />
<br />
A single protocol design was also consistent with our original objectives, documented in INWG 2. The approach I took was to start with INWG 61, introduce a gateway fragmentation mechanism derived from INWG 39, and “discard any options proposed [in INWG 61] which complicate the gateway fragmentation mechanism without great compensating benefits.” I added the checksum option from INWG 39 and a time stamp field that had been proposed by Tomlinson13 to detect duplicate messages delivered extremely late by the catenet.<br />
<br />
In May 1975, following an INWG meeting in Anaheim, California, where the three proposals (and various ideas for modifying them) were discussed, '''Pouzin''' and '''Cerf''' issued INWG 85 calling for a vote by mail on an End-To-End Protocol to be forwarded to standards bodies. They wrote: “discussions in the Anaheim meeting confirm that there is no major difficult in reaching now an agreement on a common E-E protocol. However, it is also apparent that such an agreement cannot be reached during a typical INWG meeting.” It called for a vote among “all complete proposals” that had been “submitted (in writing) by 1 September 1975.” It stated that only one vote would be accepted from each separate organization represented in the INWG membership, regardless of how many individuals from that organization participated in INWG work.<br />
<br />
In July 1975, '''Cerf''' (representing INWG 39 and ARPA),''' Zimmermann''' (representing INWG 61 and Cyclades), Roger Scantlebury (representing NPL and EIN), and I (designated as output editor) met in London, agreeing to stay in session for as long as it took to produce a single proposal that INWG could vote on or reach the conclusion that we could not agree. In less than a week we had reached an agreement, which was documented in INWG 96.14 This proposal provided for an Internet header of 26 octets and a user text divided into fragments of 216 octets (which it noted to be a common multiple of machine word lengths of 8, 12, 16, 18, 24, 32, 36, and 64 bitsall of which were in use in some machine at that time). Address fields in the header provided for 32 bits of host address and 16 bits of process address. A letter could consist of up to 255 fragments (about 200,000 bits), and each letter carried a 16-bit sequence number for error control. Communication between application processes could be in either lettergram mode or liaison mode. Lettergram mode treated each letter independently (like a postal letter), with the possibility of requesting acknowledgment; Liaison mode treated the association as a bit stream (with the possibility of error and flow control) at the cost of carrying out initialization and termination exchanges of control information. Gateway fragmentation was possible if the source network allowed packets long enough to contain multiple fragments and the sender made use of that capability to send multifragment packets; all networks participating in the catenet were required to carry packets of at least 242 octets (a header plus one fragment).<br />
<br />
<br />
== Synthesis Approved, but Collaboraton Collapses ==<br />
<br />
With the successful formulation of the INWG 96 proposal, the vote called in INWG 85 was changed to a simple yes/no on the question of submitting INWG 96 to CCITT and ISO as the IFIP recommendation for an international standard. A ballot, INWG 102, was circulated on 1 December 1975; returned ballots were required to be postmarked no later than 15 January 1976. The results of the balloting were announced in INWG 109. The vote was 25.8 in favor, 7.5 opposed, and 8.7 abstaining (several organizations internally divided their single vote among several active participants who didn’t agree). Derek Barber, who became INWG chair early in 1976, announced in INWG 111 that he was formally transmitting the accepted proposal to ISO and CCITT.<br />
<br />
With the formal vote in favor of the INWG 96 protocol, it was expected that the various research groups within INWG would announce plans to convert to the common protocol and carry out their experiments with it. NPL and Cyclades, the two groups already carrying out internetwork tests, announced plans to convert immediately. EIN, still several months away from initial deployment, also announced their intention to use the INWG 96 protocol. But we were all shocked and amazed when '''Bob Kahn''' announced that DARPA researchers were too close to completing implementation of the updated INWG 39 protocol to incur the expense of switching to another design.15<br />
<br />
As events proved, '''Kahn''' was wrong (or had other motives); the “final” TCP/IP specification was written in 1980 after at least four revisions.16 But whether he was right or wrong didn’t matter; DARPA had a bigger research budget than any of the other research organizations, and for this reason, its protocol choice became dominant over time.<br />
<br />
INWG continued work on protocol design and formal specification for another 15 or 20 years17 and then disbanded around the time of the Internet explosion.<br />
<br />
<br />
== Reflections ==<br />
<br />
History is not an experiment that can be run multiple times from different initial conditions, but I have often speculated about what might have been different if DARPA had chosen to adopt the INWG 96 proposal in early 1976.18 I once thought that if the research community were united behind one End-to-End Protocol, we might have avoided most or all of the incredibly wasteful ISO Open Systems Interconnection activity. However, the OSI effort was probably an inevitable clash between computer manufacturers and PTTs, and of both against IBM.19 <br />
<br />
I also once believed that the Internet might have exploded into the public consciousness five years earlier if European and US research groups had been cooperating. Maybe so, but there really had to be a number of other developments before the Internet explosion took place, including the transition of the US infrastructure from government-owned to privately-owned20 under the masterful direction of Steve Wolff of the US National Science Foundation21 with the funding championed by US Senator Al Gore;22 the widespread adoption of Unix23 as an “open” server OS, with free Internet software developed with DARPA funding;24 the widespread adoption of the personal computer for household use with free Internet software; the development of the hypertext linking protocols by Tim Berners-Lee25 and using the mouse26 for point-and-click computing; the development of a browser with a graphic user interface;27 and the development of a high-performance search engine.28 Once these developments occurred, the Internet explosion was assured, and until they occurred, it was impossible. Perhaps the only historical difference that would have occurred if DARPA had switched to the INWG 96 protocol is that rather than '''Cerf''' and '''Kahn''' being routinely cited as “fathers of the Internet,” maybe '''Cerf''', Scantlebury, '''Zimmermann''', and I would have been.<br />
<br />
<br />
== References and Notes ==<br />
<br />
# Filing with the US Federal Communications Commission (FCC) to become licensed as a common carrier.<br />
# K. Hafner & M. Lyon, Where Wizards Stay Up Late, Simon & Schuster, 1996, pp. 176–186.<br />
# D. Barber (EIN, UK), B. Barker (BBN, US), '''V. Cerf''' (Stanford University, US), W. Clipsham (UK), D. Davies (NPL, UK), R. Despres (PTT, F), V. Detwiler (UBC, CA), F. Heart (BBN, US), '''A. McKenzie''' (BBN, US), L. '''Pouzin''' (IRIA, F), O. Riml (Bell-Northern Research, CA), K. Samuelson (Stockholm University), K. Sandum, B. Sexton (NPL, UK), P. Shanks (Post Office, UK), C.D. Shepard (Dept. of Communications, CA), J. Tucker (Logica, UK), and B. Wessler (ARPA, US).<br />
# This was before online documentation; INWG notes were distributed on paper. To preserve the historical record and make it available to the public, I donated my almost-complete set of INWG notes to the Charles Babbage Institute at the University of Minnesota, Minneapolis, in 1996 when I retired. I used that collection to research this article.<br />
# CCITT stands for International Consultative Committee on Telephone and Telegraph. This is an arm of the United Nations and the coordinating body of telecommunications companies. In most countries telephone and data communications are provided by a government monopoly, and therefore governments are members of CCITT; in the US the State Department is the official member body. A few international technical organizations for example, the International Standards Organization are also members.<br />
# Specifically noted were the Walden Message-Switching Protocol, ARPA H-H Protocol, NPL High-Level Protocol, CYCLADES Protocol, and EPSS Protocol.<br />
# “E.g. flow control; error detection and handling; retransmission and acknowledgment mechanisms; ways to determine current state of process at ‘other’ end of the conversation; message sequencing; synchronization; addressing problems.”<br />
# E. Aupperle, '''V. Cerf''', '''B. Kahn''', '''A. McKenzie''', R. Metcalfe, R. Scantlebury, D. Walden, and H. '''Zimmermann''' [CORRECTION 2011/04/24: According to recent private correspondence, '''Kahn''' did not attend this meeting.]<br />
# The reference to “international nodes” reflects the unstated view that each network would be national in scope, with the implication that each nation would have one (or at most a few) networks. This was certainly the CCITT worldview.<br />
# They specifically mention that “G. Grossman and G. LeLann made contributions after that meeting.”<br />
# University College London, Bolt Beranek and Newman, and Stanford University<br />
# INWG 74, “Internetwork Host-to-Host Protocol<br />
# R. Tomlinson, well known as the creator of network email, in INWG Protocol note 2 (a separate series of INWG notes), Sept. 1974<br />
# Also published in ACM SIGCOMM’s Computer Comm. Rev., vol. 6, no. 1, 1976.<br />
# Ironically, in response to a question about changing the Internet architecture at his Turing Lecture in Aug. 2005, Bob said “changing that is much more difficult now, with all of those investments, than it would have been 20 or 30 years ago when basically it was just a big research experiment.” http://www.acm.org/sigcomm/sigcomm2005/webcast.html<br />
# RFC 760, also published as Internet Experiment Note (IEN) 128, available online at http://www.faqs.org/rfcs/<br />
# I became chair after D. Barber, and C. Sunshine followed me as chair.<br />
# It clearly would not have made any difference to the CCITT’s adoption of X.25 in Aug. 1976.<br />
# J. Day, Patterns in Network Architecture, Prentice Hall, 2007, pp. 355–358<br />
# J. Abbate, “Privatizing the Internet: Competing Visions and Chaotic Events, 1987–1995,” IEEE Annals of the History of Computing, vol. 32, no. 1, 2010, pp. 10–22.<br />
# In the face of widespread misunderstanding, and mistrust, of his vision by almost everyone, including me. <br />
# Senator Gore created and introduced the High Performance Computing and Communication Act of 1991 (HPCA), which was instrumental in the NSF efforts to make the Internet available “everywhere.”<br />
# Unix was created by K. Thompson, D. Ritchie, M.D. Mcllroy, and J. Ossanna at Bell Labs.<br />
# The Berkeley System Distribution (BSD) version of Unix was heavily supported by DARPA.<br />
# Hypertext was probably invented independently by T. Nelson at Brown University and D. Englebart at Stanford Research Inst., but Berners-Lee deserves credit for developing a network-based version.<br />
# Invented by D. Englebart, championed by Xerox PARC, and popularized by the Apple Macintosh.<br />
# Mosaic, developed by Marc Andreessen and Eric Bina at the National Center for Supercomputer Applications at the Univ. of Illinois funded by the Gore Bill.<br />
# AltaVista, developed by Louis Monier and Michael Burrows at Digital Equipment Corporation's Western Research Laboratory.</div>Sysophttp://iuwg.net/index.php/Louis_Pouzin_/_IRIALouis Pouzin / IRIA2015-03-14T17:48:45Z<p>Sysop: /* Related contributions about the technology initial basis */</p>
<hr />
<div>Les concepts fondamentaux de l'Internet ont été avancés par '''Louis Pouzin''' au début des années 1970 et reprises au seing de l''''[http://alexmckenzie.weebly.com/inwg-and-the-conception-of-the-internet-an-eyewitness-account.html INWG]'''. La technologie "Internet" de l'INWG/IETF étant un fork de cette approche elle manque de certains principes clés et a eu sa propre évolution. <br />
<br />
L'étude des documents fondateurs et de l'expérience acquise permet de conduire à une troisième forme d'innovation aux côtés de l''''innovation incrémentale''' (qui poursuit sur la ligne des résultats acquis) et l''''innovation disruptive''' (qui ne le fait pas et introduit une invention) : c'est l''''innovation fondamentale''' qui permet de reprendre en compte des principes oubliés et de corriger ce qui s'est ensuite avéré comme un moindre avantage.<br />
<br />
Sont dès 1973 ainsi explicités les concepts fondamentaux de '''Catenet''', et de '''PSN''' (''enfin officialisé par la FCC mi-mars 2015 - pas encore dans la loi locale ! - '''42 ans''' pour traverser l'Atlantique d'Est en Ouest ! Nos DandyYankees énarquiens pourraient y réfléchir.'').<br />
<br />
<br />
* '''[http://iuwg.net/images/Pouzin-1973.pdf interconnection of packet switching networks]'''<br />
* '''[http://iuwg.net/images/197408-Pouzin-Cigale the PS Machine of Cyclades.pdf Présentation de Louis Pouzin IFIP, Stockholm (Aug 1974)]'''<br />
<br />
''(nous travaillons sur la transposition en page de travail Blik de ces documents de base).''<br />
<br />
<br />
==== Related contributions about the technology initial basis ====<br />
<br />
* '''[[INWG and the conception of the Internet - Alex McKenzie]]''' (Commented)<br />
* '''[http://www.historyofcomputercommunications.info History of the Computer Communications - James Pelkey]'''<br />
* '''[http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf How in the Heck Do You Lose a Layer!? (slides) - John Day]''' <br />
* '''[http://pouzinsociety.org/images/How_in_the_Heck_do_you_lose_a_layer.pdf How in the Heck Do You Lose a Layer!? (paper) - John Day]'''</div>Sysophttp://iuwg.net/index.php/Letter_to_Lawrence_E._Strickling,_Assistant_Secretary,_NTIALetter to Lawrence E. Strickling, Assistant Secretary, NTIA2015-03-14T11:03:04Z<p>Sysop: </p>
<hr />
<div><br />
'''The Honorable Lawrence E. Strickling <br/>Assistant Secretary for Communications & Information<br/>National Telecommunications & Information Administration<br/>United States Department of Commerce<br/>1401 Constitution Ave., N.W.<br/>Washington, DC 20230 '''<br />
<br />
<br />
Saint-Vincent de Barbeyrargues, March 11, 2015<br />
<br />
<br />
Dear Assistant Secretary Strickling,<br />
<br />
On March 14, 2014, you asked the Internet Corporation for Assigned Names and Numbers (ICANN) to convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the Internet’s domain name system (DNS). You also have informed ICANN that you expected that in the development of the proposal, ICANN will work collaboratively with the directly affected parties, including the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), the Internet Society (ISOC), the Regional Internet Registries (RIRs), top level domain name operators, VeriSign, and other interested global stakeholders.<br />
<br />
Shortly after March 14, 2014, ICANN launched a multistakeholder process and discussion to gather community views and input on the principles and mechanisms for a different issue: the transitioning of NTIA's stewardship of the IANA functions.<br />
<br />
Following a month-long call for input on the community-driven draft proposal, on June 6, ICANN posted the Process to Develop the Proposal and Next Steps.<br />
<br />
Then, following a call for names, the IANA Stewardship Transition Coordination Group (ICG) was formed, comprising individuals selected by each represented community. These 30 individuals represent 13 communities of both direct and indirect stakeholders who together will deliver a proposal to the NTIA recommending a transition plan of NTIA’s stewardship of IANA functions to the Internet community, consistent with the key principles that you outlined in your March 14 announcement. <br />
<br />
The ICG coordinates with 13 “communities”, which are: <br />
:* At-Large Advisory Committee (ALAC) ''(*)''<br />
:* Address Supporting Organization (ASO) <br />
:* Country Code Names Supporting Organisation (ccNSO and non-ccNSO Country Code Top-Level Domain [ccTLD] operators, as selected by the ccNSO) <br />
:* Generic Names Supporting Organization (GNSO). GNSO seats from non-Registry representation <br />
:* Generic Top Level Domain Registries (gTLD Registries) <br />
:* Governmental Advisory Committee (GAC) <br />
:* International Chamber of Commerce/ Business Action to Support the Information Society (ICC/BASIS) <br />
:* Internet Architecture Board (IAB) <br />
:* Internet Engineering Task Force (IETF) <br />
:* Internet Society (ISOC) <br />
:* Number Resource Organization (NRO) <br />
:* Root Server System Advisory Committee (RSSAC) <br />
:* Security and Stability Advisory Committee (SSAC) <br />
<br />
None of them represent the directly affected largest party, i.e. the lead and end users and the civil society organizations. As a part of this large and open community, a pioneer of the international network, and a member of the Libre community, I considered that my best chance to get my position heard would be through the technical community open, collective, and balanced work.<br />
<br />
Does RFC 3869 of the IAB not state? <br />
<br />
:“The principal thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble. In addition to issues about which projects are funded, the funding source can also affect the content of the research, for example, towards or against the development of open standards, or taking varying degrees of care about the effect of the developed protocols on the other traffic on the Internet.” <br />
<br />
while the RFC 6852 from the same IAB states: <br />
<br />
:“We embrace a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status.” <br />
<br />
:“In this paradigm standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally. These voluntary standards serve as building blocks for products and services targeted at meeting the needs of the market and consumer, thereby driving innovation. Innovation in turn contributes to the creation of new markets and the growth and expansion of existing markets.” <br />
<br />
The IETF document preparation work has been carried out in three phases: <br />
<br />
:* A “status quo” position decided by the RFC 3774 socalled “IETF affinity group” documented in a WG/IANAPLAN charter. <br />
:* A work accomplished by that WG/IANAPLAN <br />
:* A review by the whole IETF mailing list open to everyone but me, (I am the moderator of the iucg@ietf.org non-WG mailing list of the Internet Users Contributing Group) <br />
<br />
This consensus leads to a technological fork of the internet architecture at a time where the RFC 6852 paradigm opens a permissionless innovation area. To avoid this leading to a technical jeopardy, the IETF position document should address a certain number of questions permitting other SDOs, Libre projects, and other reentrant architectures to transparently use the same basic catenet infrastructure without mutual negative interferences. To that end, the IETF consensus should be enriched by the responses to a certain number of questions because at this stage it is not sufficiently understandable.<br />
<br />
RFC 2026 defined the internet standardization process that addresses this situation through the appeal process. I am, therefore, appealing to the IESG, with the intent to ensure that the IAB and ISOC also address what belongs to their own areas of responsibility.<br />
<br />
The text of this appeal is temporarily at the IESG URL: '''http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf''' ''(**)''<br />
<br />
Respectfully yours,<br />
<br />
Jean-François C. (Jefsey) MORFIN<br/>Moderator iucg@ietf.org<br/>IETF contributions and appeals are in private capacity.<br />
<br />
<br />
''(*) This line is ommited by error in the initial letter and IESG published copy.<br/><br />
''(**) This was updated after the IESG acknowledged the appeal.<br />
<br />
<br />
----<br />
<br />
<br />
Please consult the '''[http://www.ietf.org/iesg/appeal.html IESG response]'''.<br />
<br />
<br/></div>Sysophttp://iuwg.net/index.php/20150313_-_JFCM_-_Appel_de_la_d%C3%A9cision_de_l%27IETF_conduisant_%C3%A0_une_scission_technologique_de_l%27internet20150313 - JFCM - Appel de la décision de l'IETF conduisant à une scission technologique de l'internet2015-03-13T14:00:28Z<p>Sysop: </p>
<hr />
<div>__TOC__<br />
<br />
<pre><br />
At 21:06 12/03/2015, xxxxxxxxxxx wrote:<br />
> Pour tenter de faire "simple", cela parle de nous, de notre<br />
> porte-monnaie, et de notre mise en esclavage mental à travers le<br />
> mécanisme concrêt de la gouvernance pratique de notre outil de<br />
> communication digitale.<br />
<br />
Bon... Au risque de passer pour un con (mais ça, ça me gêne pas du<br />
tout), j'ai décroché assez vite de ton Wiki, au moment de la "Note<br />
architectonique". <br />
</pre><br />
<br />
<br />
Tu ne passes pas pour un con, mais moi ! <br/><br />
Tu mets très bien le doigt où cela fait mal. Le manque de mots pour décrire ce qui nous tombe dessus.<br />
<br />
==== La renormalisation digitale ====<br />
<br />
Ceci vient de ce qu'il y a une profonde rupture entre :<br />
* le monde que nous connaissons tous (l'internet en est un '''petit''' bout)<br />
* et celui que j'ai professionnellement abordé il y a quarante ans avec sa composante digitale, et qui est en train de nous rattraper<br />
<br />
Mon problème est que je ne suis pas un prophète qui fait de la science-fiction et qui peut utiliser les mots de tout le monde pour se faire comprendre de ceux qui ne sont pas encore informés; mais un tacheron qui parle du présent encore mal connu de tous et controversé entre chercheurs, experts, politiques aux commmandes, etc et où la gouvernance est totalement nouvelle (c'est pourquoi certains peuvent en profiter pour rendre me shmilblick opaque (business) ou pompeux (politiques) et en tirer grand avantage pour nous rouler) <br />
<br />
Si tu veux, il y a un gigantesque délit d'initiés à notre détriment en cours.<br/><br />
Il s'appelle la Crise.<br />
<br />
====Nous sommes tous constitutionnellement en "contre-guerre"====<br />
<br />
Depuis quarante ans, mon boulot est la contre-guerre (encore parfois un peu solitaire) pour s'y opposer. <br />
<br />
Ma doctrine (faute de doctrine française encore établie) est que cela passe par :<br />
* l'enracinement de chacun dans sa digitalité,<br />
* le contrôle de son relationnel <br />
* la protection cohérente de ses données privées, <br />
* la maîtrise de son espace d'échanges numériques. <br />
<br />
C'est à dire : je pacifie le territoire commun en aidant chacun à implanter solidement son système judicieusement avec précaution; à organiser la protection de ses échanges de concert avec ses relations familliales, de travail, de culture, nationales, mondiales; de façon à être de taille à optimiser et sécuriser ses relations extérieures.<br />
<br />
La contre-guerre est une notion nouvelle, en fait héritée d'Einstein. Dans un espace à quatre dimensions, il faut occuper et se protéger aussi dans le temps. Non seulement à l'intérieur et à l'extérieur, mais aussi à l'ultérieur. Il faut donc se battre aujourd'hui contre ce qui va plus tard nous cnduire à de vrais conflits. Cela est dans notre Constitution et c'est une obligation pour les citoyens qui en sont informés : cela s'appelle le "principe/devoir de précaution". http://fr.wikipedia.org/wiki/Bloc_de_constitutionnalit%C3%A9#Charte_de_l.27environnement. <br />
<br />
==== Le cyberespace ====<br />
<br />
Ceci résulte aussi de ce que notre environnement de vie (Lithosphère, Hydrosphère, Pedosphère [surface de la terre], Atmosphère, Biosphère, Spatiosphere) s'étend maintenant à <br />
<br />
* la '''digisphère''' : pense simplement aux nanotechnologies, aux ordinateurs quantiques, à tous ces trucs discontinus sous leur continuité apparente <br />
* où nous sommes dans une période de colonisation initiale. <br />
:* La stratégie '''"Status-quo"''' y était une politique de protection des acquis,<br />
:* Celle de '''"permissionless innovation"''' est la coopétition pour de nouveaux territoires digitaux. <br />
:* La '''multipartieprenance''' proposée par les US, une coalition des dominants pour être encore plus dominants.<br />
<br />
Pour prendre une métaphore maritime : sur la mer du cyberespace il y a <br />
:*des '''marines''' impériales (USCyberCommand/NSA, GCHQ, [http://venturebeat.com/2014/05/22/former-kgb-general-snowden-is-cooperating-with-russian-intelligence/ FSB], China), <br />
:* les '''pirates''', <br />
:* et les''' corsaires''' avec ou sans lettre de marque (soutien officiel des Etats).<br />
<br />
#Il semble que notre marine française soit un peu tenue à l'écart par les contraintes de coordination européenne et notre non-appartenance aux "5-Eyes". Notre Amiral Cybernétique, le VA Arnaud de Coustillière en a une position un peu étrange : la cyberguerre serait un abus de langage (http://www.rslnmag.fr/post/2015/01/22/La-cyberguerre-un-abus-de-langage-Interview-du-Vice-Amiral-Coustilliere-officier-general-a-la-Cyberdefense.aspx). Mais c'est du journalisme. Quoique, le langage était un peu différent un an avant : http://www.rslnmag.fr/post/2015/01/22/La-cyberguerre-un-abus-de-langage-Interview-du-Vice-Amiral-Coustilliere-officier-general-a-la-Cyberdefense.aspx<br/><br />
#nos pirates ... sont des pirates dont nous savons peu de choses.<br/><br />
#Il nous reste donc l'action de corsaires citoyens. Nous. Les "Bitcanniers" ?<br/><br />
<br />
<pre><br />
At 21:17 12/03/2015, xxxxxxxxxxxxxx wrote:<br />
> Au passage, si d'autres personnes ont compris ce dont il s'agit, je<br />
> suis preneur de messages privés pour éclairer ma lanterne.<br />
<br />
Je crois que le soucis de Jefsey Morfin, c'est que même les gens de l'IETF<br />
ne comprennent pas ce dont il s'agit.<br />
</pre><br />
Très exactement. <br />
<br />
Les initiés militaro-politiques (NSA/USCC [http://fr.wikipedia.org/wiki/United_States_Cyber_Command]) (voir Post-Scriptum sur les US) ont pris le contrôle sur les techniciens en créant l'IETF (1986) pour y entraîner les techniciens à s'investir dans le NSA-compatible jusqu'à ce qu'ils aient suffisament confiance dans le pli donné (ils ne cherchaient pas à les brider), pour s'en retirer officiellement et laisser libre cours à leur innovation dans le cadre défini. Ils ont transféré la tutelle à l'ISOC qu'ils avaient fait sponsoriser par leur fournisseurs. Attention : il s'agit simplement pour l'USCC/NSA de coordonner la technologie des appels d'offres qu'ils font et des propositions qu'ils reçoivent. <br />
<br />
Ils (militaro-industriel) ont profité que tout le monde dans un premier temps utilisent leurs solutions pour vendre à la NSA de quoi espionner tout le monde. Ceci est en train de changer, simplement parceque (bien que multiplié par trois grâce à Snowden) les autres marchés se développent pour des solutions hors TCP/IP. Ils vont perdre le contrôle de l'homogéneité technique. <br />
<br />
====Ce qu'ils font ====<br />
<br />
Ils sont donc en train de faire comme pour le NSA-compatible pour la gouvernance de l'internet (donc niveau politico/économique) en transférant leur implication exécutive (NTIA, càd responsabilité des télé/datacoms de la Maison Blanche) à l'ICANN qui se trouve ainsi :<br />
* à la tête du IANA (cf. infra) - à elle d'en profiter pour établir son monopole sur le catenet lui-même (les ressources partagées en réseau par tout le monde).<br />
* qui est soumise (vu son implantation géographique) à la loi Américaine et donc à la FCC (càd. responsabilité des télé/datacoms du Congrès) sans que cela ne fasse de vagues puisque tout le monde est habitué.<br />
<br />
La décision qui conditionne cette prise en main a été publiée '''hier''' (le 15 septembre 2015 est visé pour la transition), dans '''six mois'''. <br />
<br />
====NB:====<br />
:* En 2001 je prévenais : https://www.mail-archive.com/listegenerale@franceatlarge.org/msg00049.html<br />
:* Mon appel d'avant-hier fait 70 pages. <br />
:* La matière du projet que j'interroge fait selon la décision de la FCC ... 400 pages. https://apps.fcc.gov/edocs_public/attachmatch/FCC-15-24A1.pdf. <br />
<br />
====Il faut du temps pour étudier .... et débattre de la forme au lieu du fonds.====<br />
<br />
Il introduit enfin le concept de PSN (Packet Switch Network) pour ouvertement réclamer la possession du Catenet (nos resources netdigitales globales partagées). Tu en trouveras un premier résumé pour les quiddams comme nous sous http://telefrieden.blogspot.fr/. Tout le monde va se focaliser sur la net neutralité, la constitutionalité de la décision, etc. ce qui fera que personne ne s'intéressera au problème de fond (architectonique) :<br />
<br />
* à qui cela appartient (pas seulement aux US et Google)<br />
* qui est concerné (en l'occurence les citoyens yankees : nos lois sont votées au Palais Bourbon)<br />
* qui fait quoi : le Libre est justement que n'importe qui peut faire ce qu'il veut (avec la différence entre les relationnels et les logiciels libres, que pour les relationnels libres cela compatible en temps réel et de plus en plus intra-applicatif - ASAP: application as a protocol).<br />
<br />
==== Le IANA====<br />
<br />
Dans les deux actions ils ont utilisé le "IANA", (http://iana.org), c'est à dire la base de données des noms, adresses et paramètres qui est sensée être le coeur de l'internet. En fait de son plan d'adressage, et du fichier racine de la CLASSe "IN" (ICANN/NTIA?) alros qu'il y en a 35000 autres et 256 par utilisateurs, soit des millards de millards. Comme d'hab, le conflit se repose sur un petit mensonge US.<br />
<br />
Le IANA a été créé et géré par Jon Postel avec le titre officiel de '''Czar''' de l'internet (RFC 433 - RFC 2468). Le mécanisme en place était que le référent ultime du IANA. Selon le schéma qui lui a été présenté et signé:<br />
* ce IANA deviendrait "iana.arpa" sous contrôle de l'IAB. (".arpa" est bien sous contrôle de l'IAB (internet architecture board))<br />
* et la pratique opérationnelle sous ICANN (http://iana.org) qui peut en payer le coût.. <br />
<br />
Etait. Cette fois-ci, l'IAB abdique du contrôle de l'ICANN en cas de clash. Ce contrôle revient au pire à l'ISOC (qui est propriétaire de ".org"), c'est à dire au lobby des sponsors. Ceux-ci sont toutefois à la manoeuvre puisque cela passe sous la loi, américaine, et donc la FCC, donc le lobbying au Congrès (le projet public est sous http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/ - voir qui sont les sponsors de ce contractant de l'ISOC : http://gsnetworks.org/sponsorship/ (il faut cliquer manuellement pour les voir. Le Google est en tête, le State Departement se mêlle aux autres.)<br />
<br />
==== Et nous et nous et nous ? ====<br />
<br />
Et nous la-dedans. On est empètrés dans l'Europe. Ceci fait que la réaction ne peut être que citoyenne. Après le 11 septembre il y a donc eu un gros travail orienté sécurité. J'ai alors prévenu de notre fenêtre de 15 jours pour nous imposer au plan US, et averti des 30 ans que cela nous prendrait pour remonter la pente autrement. https://fr.groups.yahoo.com/neo/groups/icann-fra/conversations/messages/1047<br />
<br />
La conséquence est décrite dans la suite donnée à la fin de ce texte sous http://iuwg.net/index.php/Internet_:_15_jours_pour_convaincre_-_30_ans_%C3%A0_subir. Cette fois là, les choses étaient bloquées par la stratégie stérilisante du "status-quo" (keep NSA-compatible). Aujourd'hui le paradigme se veut "permissionless innovation" : cela donne plus de marge de manoeuvre. Au lieu d'une association informelle porteuse d'un banc-test, le projet est celui d'une société (coopérative, mais une vraie SA) qui par là sera indépendante du "lobby des sponsors"<br />
<br />
Pas mal brouillon.<br/><br />
Mais le sujet et très vaste et tant confusé par tout ce que l'on blablate sur lui.<br />
<br />
<pre><br />
Dommage, il y avait plein de mots nouveaux après,<br />
qu'il m'aurait été agréable d'apprendre pour les replacer à l'apéro<br />
entre potes par exemple :-P<br />
</pre><br />
<br />
Si tu as le coeur bien accroché tu peux essayer le [http://lerda.org/index.php/Vocabulaire Vocabulaire du LERDA]. <br />
<br />
Sursum Corda<br />
jfc<br />
<br />
<br />
====PS====<br />
<br />
Dans cette affaire nous avons a bien comprendre que nous sommes confrontés aux fournisseurs (militaro-industriel) du système qui nous protège. Il est américain, car il doit être national du pays dominant. Cela n'a rien à voir avec les Américains eux-mêmes.<br />
<br />
;Militaro-industriel : Pour comprendre de dont il s'agit le texte clé (très très court) est un paragraphe de la conclusion de mandat de "Ike", Dwight D. Einsenhower. Tu le trouves sous http://fr.wikipedia.org/wiki/Discours_de_fin_de_mandat_de_Dwight_D._Eisenhower. Ensuite tu peux aller sur http://icp.ge.ch/po/cliotexte/deuxieme-moitie-du-xxe-siecle-guerre-froide/discours.eisenhower.html pour avoir le texte intégral en français. C'est le diagnostique du meilleur expert : vainqueur américain de la WWII et deux fois président. <br />
<br />
<br />
;République Américaine : Un bon américain ne conçoit pas son pays comme une démocratie, mais comme une République. Comme nous. Mais fédérale. (c'est pourquoi il est absurde de vouloir les copier pour l'Europe dont le projet obéit à un projet confédéral, contre lequel ils ont conduit une guerre civile refondatrice. Nous on a aussi conduit bien des guerres européenns pour savoir ce qui nous convient. <br />
<br />
:Et il sait que cette République, en tant qu'empire dominant, est en danger car <br />
:* il lui revient d'être le gendarme du monde, <br />
:* sauf à ce que son "ile" géographique (comme l'Angleterre des XVIII/XIX siècles) ne disparaisse <br />
:* devant les empires du "continent eurasiatique".<br />
<br />
:Le bouquin de référence à ce sujet est certainement "The Gand Chessboard" http://en.wikipedia.org/wiki/The_Grand_Chessboard de Zbigniew Kazimierz Brzezinski, co-fondateur de la TriLaterale, conseiller des affaires internationales de Bush et d'Obama, dont la politique de "containment" a réduit l'URSS et théoricien de la stratégie actuelle du "titytainment", le "des jeux et du pain" (panem and circenses) qui nous conduit.<br />
<br />
<br />
;le security-industriel: Si tu veux bien comprendre le coeur de la politique des professionnels de la sécurité/défense digitale des US, il te faut lire des trucs de Richard Clarke. http://fr.wikipedia.org/wiki/Richard_Clarke. <br />
<br />
:C'est lui qui était dans le fauteuil du Président dans la War-Room de la Maison Blanche le 11 septembre, Condolezza Rice '''volontairement à ses côtés'''. <br />
<br />
:Il est pour nous surtout l'auteur de la doctrine de sécurité digitale qui a été mise en place ensuite après un effort consequent d'écoute du public et des industrie. Cette doctrine établit le risque cybernétique pour les Etats-Unis au niveau "équivalent nucléaire". Elle a donné lieu au PCIPB (President's Critical Infrastructure Protection Board) et à la doctrine de sécurité cyber (http://newsbreaks.infotoday.com/NewsBreaks/PCIPB-Releases-National-CyberSecurity-Strategy-Recommendations-17085.asp). Tu trouveras une bonne introduction en ce qui concerne la situation sous http://en.wikipedia.org/wiki/Cyber-security_regulation.<br />
<br />
:*Tu as là, non-pas des journalistes, des activistes, ou même des experts. Tu as les gens qui ont décidé et que suivent ceux qui agissent et manipulent pour cela les gens, les Etats, et tout particulièrement la face peu accessible à la démocratie participative des technologies (en raison de leur complexité), '''actuellement'''. <br />
<br />
:*La stratégie semble manifestement un recentrage de maturité : l'exécutif (NTIA) se tourne vers la sécurité et le législatif (FCC) vers le fonctionnement ordinaire du "PSN" américain et de son glacis mondial du Catenet. C'est très exactement ce qu'avait prévu Vint Cerf dans son document IEN 48 de 1978. <br />
<br />
:Sauf que cela a mis plus de temps et de dégats que prévu pour la raison simple que TCP/IP n'a pas de couche OSI six "présentation", là où se traite la sécurité, l'intelligence et les langues. Cette couche a été implémentée de bric et de broc à travers de multiples patchs (Web, IDNs, encryption, etc.) ils ont besoin de la consolider (appel de l'IAB en ce sens https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ : durcir le protocol stack d'IP). Ce sont sans doute des usines à gaz vu ce qui est déjà déployé. <br />
<br />
:L'approche Relationnels Libres que je suggère serait de revenir à une architecture/autorité distribuée et non plus technocratico/hierarchique :<br />
<br />
:* services commun de transport de données à travers le Catenet (interactif, CDN, mémorisation locale/streaming, etc.) de bout en bout.<br />
:* protocoles de desserte frange à frange (conforme à l'architecture de l'Internet - réseau de transport stupide de datagrmmes de bout en bout - tout le reste à la frange)<br />
:* interapplications (réparties de toutes les manières dont chacun le veut, et avec toutes les formes d'intelligence) sur l'interface utilisateur intelligente (IUI) située et contrôlée sur sa machine sur machine virtuelle sécurisée.</div>Sysophttp://iuwg.net/index.php/BlikBlik2015-03-13T13:32:40Z<p>Sysop: Created page with " * 20150313 - JFCM - Appel de la décision de l'IETF conduisant à une scission technologique de l'internet"</p>
<hr />
<div><br />
* [[20150313 - JFCM - Appel de la décision de l'IETF conduisant à une scission technologique de l'internet]]</div>Sysophttp://iuwg.net/index.php/Internet_:_15_jours_pour_convaincre_-_30_ans_%C3%A0_subirInternet : 15 jours pour convaincre - 30 ans à subir2015-03-13T11:07:59Z<p>Sysop: /* en raison de quuoi ... */</p>
<hr />
<div><br />
'''J-F C. (Jefsey) Morfin'''<br/><br />
'''2 oct. 2002'''<br/><br />
[note pour les rédacteurs de e-zines qui me taquinent : vous pouvez utiliser<br />
sans problème]<br/><br />
''NB: ce texte [https://fr.groups.yahoo.com/neo/groups/icann-fra/conversations/messages/1047 est en ligne]''<br />
<br />
<br />
__TOC__<br />
<br />
<br />
Chacun peut comprendre que les réseaux de transmission de données publics<br />
répondent à un besoin fondamental de notre société actuelle. Chacun peut<br />
comprendre que sans eux, notre économie, nos relations humaines, nos<br />
emplois, notre vie culturelle, notre santé, notre enseignement, notre futur<br />
seraient très rapidement et très gravement compromis.<br />
<br />
Après le 11 septembre la Maison Blanche a demandé un rapport sur l'état de<br />
ces réseaux (accaparés par la technologie TCP/IP à la suite du Web et de la<br />
bulle Internet). Ce rapport est très clair : le réseau est une passoire où<br />
l'insécurité se développe à une vitesse que l'on pourrait qualifier de<br />
foudroyante. Cette insécurité entraîne une instabilité potentielle du<br />
système et met gravement en péril l'infrastructure locale, régionale,<br />
nationale et globale dans les domaines les plus divers allant des<br />
transports, aux systèmes bancaires, à la défense nationale, la protection<br />
des biens et des personnes, la formation et la santé avec à la clé des<br />
milliers voire des millions de vies en jeu, potentiellement dans la minute,<br />
sans possibilité de parade puisque le système électrique, les média, les<br />
urgences médicales, la navigation aerienne, etc. en dépendent. Et que les<br />
exemples de situations réelles accidentelles, criminelles ou terroristes<br />
surabondent : leur succès ou leur conjonction catastrophique ne sont<br />
manifestement qu'une question de temps.<br />
<br />
;Cette évaluation est exacte.: Elle est encore partielle car elle est basée sur une culture américaine qui se considère comme le centre du monde en terme de réseau et a donc encore à prendre la correcte mesure de la menace globale (un e-terroriste n'accédera pas nécessairement le réseau à partir de Chicago comme un pirate de l'air doit le faire) et des implications de politique étrangère que cela entraine (cf. la position Bush/Blair actuelle). Il est certain que les auteurs en ont conscience et qu'ils se réservent les deux mois à venir pour sensibiliser l'opinion à ce sujet à travers une série de meetings dans les grandes villes. Les relations avec l'Iraq tombent (?) d'ailleurs à point nommé pour être un exemple et un test de méthodologie politique.<br />
<br />
;Le plan proposé est simple : prendre les moyens de sécuriser les Etats-Unis et ses ordinateurs, et le faire. Il y a un problème: on le résout. La manière proposée est certainement adéquate, par l'addition de la coordination fédérale et des forces économiques directement menacées ou visant à en tirer un large profit. Ici on travaille à défendre sa peau, celle de sa famille et des siens, à préserver leur mode de vie, et aussi à gagner de l'argent tous ensemble.<br />
<br />
;Un seul détail : le réseau est mondial et nous ne sommes cités que comme source d'idées à ne pas oublier. En aucun cas comme partenaires. Les intérêts des Etats Unis à défendre sont listés à travers le Monde, l'Afrique n'est pas mentioniée. Nous ne sommes pas dans l'arche de Noë.<br />
<br />
====Nous nous trouvons donc à une croisée des chemins.====<br />
<br />
1. ou nous laissons faire, et la technologie Internet sera totalement<br />
revue, des licences s'appliqueront partout pour des raisons officiellement<br />
sécuritaires mais en réalité aussi financières. Au cri de "nous nous<br />
protégeons, nous pouvons aussi vous protéger, mais après tout le Net c'est<br />
nous qui l'avons fait". Et nous aurons un réseau à deux vitesses : Nord<br />
dépendant des USA, Sud en GPL peu compatible et ouvert, avec tous les<br />
déséquilibres, les vindictes et les instabilités qui en résulteront et qui<br />
ne profiteront à personne. The digital divide devient le digital gap.<br />
<br />
2. ou nous disons, et surtout nous faisons en sorte, que cette révision -<br />
qui est nécessaire - soit universelle : avec nous et ouverte à tous. En se<br />
souvenant que c'est Louis Pouzin et l'Inria qui ont apporté les zones de<br />
l'Internet, un protocole de bout en bout qui marche, un financement à un<br />
moment critique, que nous avons créé le nommage ensemble, que le Transpac<br />
était français; le Videotext européen, l'ISO par l'UIT et surtout ... qu'à<br />
réseau global il faut un effort de développement global. Mais nous devons<br />
le dire et le faire de façon compréhensible et acceptable pour des gens qui<br />
se considèrent en guerre, et qui se lancent dans un véritable projet<br />
Manhattan II ou Apollo II.<br />
<br />
==== Nous avons pour cela 15 jours.====<br />
<br />
15 jours car nous sommes dans une logique de riposte rapide à une situation<br />
de danger qui se dégrade rapidement. Pour le comprendre, il suffit de<br />
regarder les rapports de son Zone Alarme, le nombre des ses spams et les<br />
alertes Virus. Le rapport de Richard Clarke (M. CyberSécurité de la Maison<br />
Blanche) montre bien l'état d'esprit. Même s'il y a dramatisation, cette<br />
dramatisation est une composante de la situation.<br />
<br />
Un processus de réorganisation de l'Internet a été entrepris pour héberger<br />
l'effort engagé. Il passe par l'ICANN (organisme chargé par le gouvernement<br />
amérciain de privatiser/gérer sa participation dans l'Internet) dont la<br />
reconstruction, telle qu'opposée par la plus part, sera pourtant bouclée le<br />
27 octobre; lors de sa réunion de Shanghaï. Il n'y a pas à se demander<br />
pourquoi : l'ICANN est controversée pour la forme par le NTIA qui l'a<br />
reconduite dans ses fonctions avant la date prévue.<br />
<br />
Il passe par la finalisation du rapport CyberSpace Security de Richard<br />
Clarke, évoqué plus haut, qui se fera sans doute avant la fin de l'année.<br />
<br />
Il passe par la stabilisation par "MicroSign" (accord Microsoft et Verisign<br />
- le gestionnaire des ".com/.net") du support des noms de domaines<br />
"internationalisés" (comprendre "pour les Américains") avec à la clé une<br />
prise en main du DNS (nommage mondial, et donc de l'URL qui a toutes les<br />
chances de devenir la "télécommande du réseau quotdien".<br />
<br />
Il passe par le transfert de ".org" à l'ISOC dont on peut attendre à terme<br />
que les 18 millions de dollars annuel des organisations à but non lucratif<br />
financent la stablité de l'ICANN et des structures de gestion de l'Internet<br />
reprises en main pour plus d'efficacité.<br />
<br />
Ceci créera des "avantages acquis pour les Etats-Unis" qui seront sans<br />
doute irréversibles avant longtemps.<br />
<br />
==== Sinon ====<br />
<br />
Dans notre vie de tous les jours cela ne changera pas grand chose : nous<br />
serons simplement sous un contrôle de fait peu à peu accru des Etats Unis<br />
et du FBI/CIA en terme de sécurité (la protection du "Homeland" étant la<br />
priorité). L'accès à l'information sera de moins en moins partagé. Nos lois<br />
et nos usages devront peu à peu se conformer aux décisions du Congrès qui<br />
se considère légalement comme le maître de l'Internet. Bien des innovations<br />
techniques et sociales originales de la France (Minitel) et de l'Europe<br />
(subsidiarité) seront reléguées pour des décennies jusqu'à être réinventées<br />
et proposées sous licence. Difficultés accrues pour l'exception culturelle.<br />
Les irritations personnelles, politiques et religieuses iront<br />
s'accroissant. Wall Street sera un peu plus le centre du monde, et sans<br />
doute son centre de catastrophe - le 11/9 a montré ce qu'il en est ou ce<br />
qu'il peut en être.<br />
<br />
Le SMSI III pourra se tenir à Herndon ou Seattle.<br />
<br />
==== Il y a-t'il une alternative ? ====<br />
<br />
Oui.<br />
<br />
Elle est simple car il ne s'agit pas de s'opposer à un effort nécessaire,<br />
mais d'y participer pour qu'il puisse naturellement s'équilibrer. Elle se<br />
fera nécessairement car il n'est pas possible que toute la planète dépende<br />
dans le long terme d'une pensée technique, légale, sociale, culturelle<br />
unique. Elle est d'ailleur demandée par nos amis americains qui se voient<br />
seulement confronté à un problème grave au quel ils s'estiment les seul à<br />
vouloir répondre correctement.<br />
<br />
==== Les options ====<br />
<br />
La question est quand et à quel prix. Et que se passera-t-il (ne se<br />
passera pas) entre temps.<br />
<br />
Au cours d'un récent échange rapide avec un responsable européen nous les<br />
avons évalués.<br />
<br />
* avant le 15 septembre 2002 : gratuit, immédiat, de soi.<br />
* avant le 31 décembre 2002 : cher, une ou plusieurs années, à négocier<br />
* après : très cher; une dizaine d'années, à conquérir.<br />
<br />
A ma connaissance, il n'y a qu'un projet qui puisse prendre date avant le<br />
15 septembre et être opérationnel avant la fin de l'année. Il consiste à<br />
créer un système multiple de serveurs racines expérimental à la disposition<br />
des développeurs du monde entier (pays en développement compris)<br />
pour permettre de disposer d'un système de test, de validation, de<br />
secours, d'expérience.<br />
<br />
Ce système est techniquement et stratégiquement nécessaire, il est même<br />
demandé par les documents de l'ICANN (ICP-3). Il sera soit inclus dans la<br />
proposition finale américaine sous la forme d'un système national sous<br />
contrôle de la Maison Blanche, ou il sera global parque nous l'aurons<br />
proposé et annoncé auparavant.<br />
<br />
Il requiert au départ 300 KF, une poignée d'entrepreneurs, 40 PC maximum,<br />
un peu de volonté politique et des relations. Et du temps ?.<br />
<br />
====Ce système n'est pas seulement un rêve.====<br />
<br />
Je vous en ai souvent entretenu comme d'un projet. Il est aujourd'hui en<br />
passe d'être opérationnel. Il comprend déjà 10 machines sur les 40<br />
maximales de la configuration de base. Il tourne au quotidien et résout. Il<br />
inclut des participations effectives ou des engagements formels de France,<br />
d'Allemagne, du Sénégal, du Canada, des USA, de Belgique et des intérêts<br />
affichés d'Afrique du Sud, du Pérou, d'Argentine, de Chine, de Malaisie, de<br />
Corée.<br />
<br />
Mais il va crever dans la dernière ligne droite du manque d'argent (50 KF<br />
d'urgence), d'un ou deux traducteurs pour mettre à jour son site sous<br />
http://dot-root.com ? et de soutien informationnel.<br />
<br />
==== De quoi a-t-il réellement besoin ? ====<br />
<br />
# '''de serveurs de noms''' : des pentium en ligne avec une adresse IP stable. Il n'est pas besoin de puissance aujourd'hui car c'est du test de procédure et de développement. Le but est de montrer le nombre pour la presse et l'ICANN.<br/><br/><br />
# '''de compétences''' : tous ceux qui s'intéressent au DNS et à sa stabilisation dans un cadre de souveraineté nationale, de protection culturelle, de développement de l'internet de proximité, d'industrialisation d'outils réseau au quotidien, etc.<br/><br/><br />
# '''de correcteurs anglicisant''' : pour créer un site solide (un beau SPIP - on rendra à uzine.net une version internationale !) et quelques drafts IETF pour expliquer ce qui est fait.<br/><br/><br />
# '''de bouche à oreille''' : pour que la presse en parle : ce qui compte n'est pas d'être opérationnel tout de suite, mais d'être reconnu avec des mots et des projets d'envergure. Et il y en a à supporter.<br/><br/><br />
# '''de directeurs de recherches''' prêts à inscrire un projet DNS ou protection réseau utilisant la plate-forme dot-root pour montrer que nous sommes sérieux. Les sujets surabondent si on trouve le temps de les documenter. Plusieurs TLDs de test réel sont prévus : pour les universitaires puisque ".edu" est politiquement réservé aux USA, ".telco" pour que les opérateurs approchent l'internet, etc.<br/><br/><br />
# '''de grandes entreprises sponsor''' qui participeront à un projet test de valorisation des marques par le nommage Internet dont elles ne pourront que tirer avantage sans ennuyer tout le monde.<br/><br/><br />
# '''des idées de la part de chacun'''. Pour l'instant nous sommes une poignée à défendre ce projet. Plus nous serons, plus de pays et d'académies seront représentés, mieux cela sera pour tous.<br/><br/><br />
<br />
== Suite reçue ==<br />
<br />
''Bien sûr,cela n'a pas convaincu beaucoup de monde, ni rapidement. Toutefois, le projet communautés du Libre "dot-root" a pu voir le jour et rassembler jusqu'à 30 serveurs de nommage, permettannt une expérience communautaire grandeur nature dont le rapport à été fait à RENATER. Ce rapport est à retrouver et à publier. <br />
<br />
''De ce projet est né la longue marche vers le projet actuel de la '''[http://catenet.coop Compagnie Coopérative du Catenet SCIC (CCC SCIC)]''' avec quelques métaretombées significatives dont il sera peut-être un jour intéressant de faire l'histoire (tout est en archive, mais en vrac !!!). Tout ceci est parti de la recherche INTLNET de la bonne manière de mettre à niveau la production de l'INTLFILE (le "root" actuel (les données à compiler, les mises à jour, leur présentation). Cette tâche n'est pas achevée !''<br />
<br />
==== ''en raison de quuoi ...'' ====<br />
<br />
''Dans notre vie de tous les jours cela n'a pas changé grand chose : <br />
<br />
* ''nous avons simplement bien été sous un contrôle grandissant de la NSA.<br />
* ''L'accès à l'information est bien de plus en plus googlisé<br />
* ''Nos lois, nos usages et nos débats se conforment bien peu à peu aux décisions de la FCC du Congrès<br />
* ''Obama lui demande bien la maîtrise légale de l'internet "qui est à eux"<br />
* ''nos innovations techniques et sociétales sont bien réinventées (y compris nous-mêmes) qui devenons le produit/cadeau publicitaire.<br />
* ''Les irritations personnelles, politiques changent bien; et les irritations religieuses ont bien conduit à l'Etat Islamique. <br />
* ''Wall Street s'est bien installé comme centre du monde et des catastrophes - comme l'a montré la crise des subprimes.<br />
* ''Le SMSI III (2025++ ?) pourra sans doute s'abstenir de se tenir : remplacé par la multipartieprenance des multiprenances.</div>Sysophttp://iuwg.net/index.php/ArchivesArchives2015-03-13T11:07:18Z<p>Sysop: </p>
<hr />
<div><br />
* [[Internet : 15 jours pour convaincre - 30 ans à subir]] - article 2002 - https://fr.groups.yahoo.com/neo/groups/icann-fra/conversations/messages/1047<br />
* [[Some Principles of the Internet - Jay Hauben]]</div>Sysophttp://iuwg.net/index.php/Sch%C3%A9ma_de_pens%C3%A9e_de_l%27appel_%22iana.arpa_404%22Schéma de pensée de l'appel "iana.arpa 404"2015-03-13T07:50:24Z<p>Sysop: </p>
<hr />
<div><center>'''''[[travail de mise en place en cours ...]]</center><br />
<br />
Cette page est destinée à un debriefing commun des idées d'"iana.arpa 404" et de celles du débat qu'il a ouvert.<br />
<br />
Son propos dans un premier temps est de reprendre les concepts du document. Ensuite il sera de les mettres à jour dans la perspective d'un appel probable à l'AIB et sans doute à l'ISOC et des leçons à en tirer.<br />
<br />
<br />
----<br />
<br />
<br />
<br />
<center>''' "iana.arpa 404" '''</center><br />
<br />
<br />
__TOC__<br />
<br />
{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
<br />
<!--/fr--><br />
|<br />
|valign="top"|<br />
<!--en--><br />
== Preliminary notes ==<br />
<br />
=== nature of the appeal ===<br />
<br />
This appeal is precautionary (*) and, therefore, lengthy. This is because the appealed decision, <br />
<br />
:* necessarily leads to a fork, or several forks of the internet technology, <br />
:* but does not consider the conditions or the efforts that are needed to prepare for this to happen seamlessly, <br />
:* while the common interest is to keep these forks totally compatible and their SDOs in good coopetitive relations. <br />
<br />
It is hoped that the IESG, the IAB and ISOC will make sure that their responses may serve as a guidance <br />
for further cooperation in the normative area. Such a cooperation should be based upon the modern <br />
paradigm for standards, that every global communities should endorse, while hopefully adhering to an <br />
OpenStand Council where common technical issues of interest shall be jointly addressed. <br />
<br />
(*) along the French constitutional duty of precaution for every citizen being aware of a scientific risk. <br />
<!--/en--><br />
|}<br />
{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
<br />
<!--/fr--><br />
|<br />
|valign="top"|<br />
<!--en--><br />
=== structure of the document === <br />
<br />
The appealed document is a structured document. This structure comes f rom the ICANN questionnaire <br />
that it responds to. For better readability, this document respects this structure and intersperses <br />
comments. They are labeled as "Appeal comment:" and usually followed by one or two questions. For <br />
easier consideration and response, a list of the resulting clarification questions is provided at the end of <br />
the document. <br />
<!--/en--><br />
|}<br />
{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
<br />
<!--/fr--><br />
|<br />
|valign="top"|<br />
<!--en--><br />
== Appeal Introduction == <br />
<br />
This appeal results from the lack of clarity and transparency of the WG/IANAPLAN draft-ietf-ianaplan-icg- <br />
response-09 authorized for RFC publication by the IESG on January 7, 2015. Its purpose is: <br />
<br />
:* to obtain an authoritative guidance over what it seems to imply; i.e. an internet normative fork between: <br />
<br />
::* a single global authoritative documentation and its single authoritative IANA annex <br />
::* and a multi-supported inter-technology permissionless innovation and open use,<br />
<br />
<!--/en--><br />
|}<br />
<br />
{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
<br />
<!--/fr--><br />
|<br />
|valign="top"|<br />
<!--en--><br />
<br />
<!--/en--><br />
|}<br />
<br />
{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
<br />
<!--/fr--><br />
|<br />
|valign="top"|<br />
<!--en--><br />
<br />
<!--/en--><br />
|}<br />
<br />
{|<br />
|width="600"|<br />
|width="50"|<br />
|width="600"|<br />
|-<br />
|valign="top"|<br />
<!--fr--><br />
<br />
<!--/fr--><br />
|<br />
|valign="top"|<br />
<!--en--><br />
<br />
<!--/en--><br />
|}</div>Sysophttp://iuwg.net/index.php/IANAPLAN_Appel_%C3%A0_l%27IESG_-_HistoriqueIANAPLAN Appel à l'IESG - Historique2015-03-13T06:54:48Z<p>Sysop: Created page with "''Cette page est destinée à l'historique des points soulevées, motivations rencontrées et suivis de la procédure d'appel de JFC MORFIN auprès de l'IESG, et probablement..."</p>
<hr />
<div>''Cette page est destinée à l'historique des points soulevées, motivations rencontrées et suivis de la procédure d'appel de JFC MORFIN auprès de l'IESG, et probablement de l'IAB et de l'ISOC (procédure d'escalation ordinaire) concernant les modalités de transition du IANA par le '''NTIA''', responsable des datacommunications au sein de l'exécutif américain où il est l'équivalent de la '''FCC''' au niveau législatif.''<br />
<br />
''Manifestemet la stratégie de l'administration Obama peut être lue comme visant à transférer <br />
* ''la supervision '''opérationnelle''' d'une part de l''''Internet''' par le NTIA (ce qui a une nature de '''dominion de circonstance''' de plus en plus politiquement et techniquement remis en cause par l'avancement de la demande et la contestation multilaterale),<br />
* ''vers une supervision '''juridictionnelle''' définitive du '''Catenet''' mondial par la FCC (ce qui correspond à une '''colonisation stable de la digitalité mondiale''').<br />
<br />
<br />
<br />
----<br />
<br />
<br />
'''20150311''' : j'ai envoyé mon appel à l'IESG contre l'illisbilité pratique de leur position concernant la transition demandée à l'ICANN par le NTIA.<br />
<br />
Il a été enregistré par l'IESG (Internet Engineering Steering Group)à l'URL : <br />
<br />
<center><big>'''http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf'''.</big></center><br />
<br />
'''Attention''' : le document fait '''72 pages''' (et pose '''36 questions''' clé) ! <br />
<br />
Cet appel est placé dans le cadre du devoir de précaution constitutionnel pour chaque citoyen français informé du danger que représente un développement technique. <br />
<br />
Un commentaire et un suivi en seront maintenus sous http://iuwg.net/index.php?title=IANAPLAN_Appeal_to_the_IESG.<br />
<br />
<br />
----<br />
<br />
<br />
Le danger est l'incompréhensibilité ménagée par l'"affinity group" des leaders de l'ICANN/IETF (le nom en est défini par la RFC 3774 sur le problème de l'IETF). Elle est destinée à <br />
<br />
* aider à perpétuer la dominance américaine sur le '''Catenet''' (la concaténation globale des ressources digitales mises en partage : le "réseau des réseaux" de Louis Pouzin) <br />
* afin de continuer à en contrôler les utilisations "locales" (c'est à dire à nos réseaux virtuels "glocaux" - ou "VGN" : virtual glocal networks - le concept est explicité dans le "paradigme de Cerf" repris dans le document). <br />
* par passage sous un maillage (multipartieprenance) de droit contractuel (privé et multilatéral [TIPP, TAFTA, ICANN]) et sous animation/référence technico-juridique de la FCC.<br />
<br />
Cet appel se positionne dans le contexte actuel tel que reconnu par <br />
* le document OpenStand (RFC 6852) cosigné par IEEE/IETF/IAB/ISOC/W3C <br />
* selon lequel nous sommes dans une coopétition normative multitechnologies.<br />
<br />
Le gouvernement américain cherche à :<br />
* positionner les retombées de son investissment internet (Obama: l'internet est à nous) pour établir une dominance juridique définitive sur le '''Catenet''',<br />
* avant que cette technologie internet d'utilisation du Catenet ne rentre dans le rang du''' multi-technologie initial''' - qu'ils ont réussi à contrer, en fait contre la France, pendant 30 ans.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
<br />
== Communiqué initial ==<br />
<br />
Pour information j'ai envoyé mon appel à l'IESG contre la décision de publier une position stérilisante, car volontairement illisible concernant la transition demandée à l'ICANN par le NTIA (exécutif américain) pour en fait utiliser le contrôle politique américain encore rémanent de l'internet pour établir le contrôle juridique de tout le catenet (concaténation de la globalité des ressources digitales mises en partage) de la FCC et donc du Congrès américain et de ses lobbys militaro-industriels avant que ne s'installe le "multi-technologies" par l'"innovation sans permission".<br />
<br />
1. Vous trouverez le texte de cet appel (71 pages) sous : https://www.dropbox.com/s/ckqaaq0ngqed0ie/iesg-appeal-inanaplan.pdf?dl=0 et normalement listé, d'ici quelques heures, sous http://www.ietf.org/iesg/appeal.html - à moins que les YankIETF fassent de la résistance.<br />
<br />
2. Je le place dans le cadre du devoir de précaution constitutionnel pour chaque citoyen français informé du danger que représente un développement technique. Je l'ai aussi adressé à l'Assistant Secretary L.E. Strickling, patron du NTIA. Normalement la procédure d'appel et les délais impartis retardent la procédure jusqu'à quatre mois et permettent à chacun d'en profiter pour poser des questions de fond sur la gouvernance et la souveraineté de la digisphère. <br />
<br />
3. Il importe peu que l'on soit d'accord ou non avec moi. Le but est de permettre à chacun de se positionner dans un débat qui est fondamental à tout droit de l'internet, du digital, du numérique et sans doute de la société actuelle. Je maintiens son commentaire et son suivi sous http://iuwg.net/index.php/IANAPLAN_Appeal_to_the_IESG. En prenant date, il importe en fait peu que les responsables de l'IETF (standardisation), IAB (architecture), ISOC (sponsoring), NTIA (politique), etc. répondent. Leur absence de réponse ne ferait que légitimer de façon claire le bien-fondé de chacun à considérer son droit/devoir de précaution pour ses biens digitaux et l'accès aux services numériques qu'il utilise, et donc de rechercher ensemble des solutions plus claires, transparentes, neutres et stables.<br />
<br />
Je suis preneur de toute coopération, aide et assistance à ce sujet que j'entends, pour ce qui me concerne, canaliser à travers la création d'une société coopérative d'intérêt commun indépendante de tout sponsor, statutairement fondée sur l'omnipartieprenance (1 homme = 1 voix), permettant d'apprendre la coopération numérique en coopérant au niveau du réel "glocal", et dont l'objectif sera de fournir à chacun les moyens et relationnels libres lui assurant sa maîtrise digitale et la protection de son "privatoire" c'est à ce qui fait sa personne privée et dont trop d'intérêts politiques, stratégiques, commerciaux, économiques cherchent à le priver.<br />
<br />
== Propos ==<br />
<br />
Par cet appel je cherche aussi des réponses:<br />
<br />
<br />
==== Savoir qui est à la manoeuvre ? ====<br />
<br />
L'un des propos de cet appel est de voir qui est aux commandes en voyant qui va répondre au final : IESG, IAB, ISOC ou NTIA (le document a été personnellement annoncé à Lawrence Strickling, le patron du NTIA).<br />
<br />
Il est aussi de savoir qui, en France, en Europe et dans le monde est suffisament informé, compétent, motivé, etc. pour contribuer à la construction commune nécessaire, selon une vision adhoc pragmatique et adaptée à la singularité technologique que nous vivons qui :<br />
* n'est que "techno-logique" (on facilite notre raison logique cérébrique naturelle avec de la cérbrique artificielle auxillaire) <br />
* et n'en est pas pour autant "post-humaine" et conduisant à "''l'homo gougliensis''" !<br />
<br />
<br />
==== Le contexte de lancement de la CCC SCIC ====<br />
<br />
Le pas suivant sera la création de la '''Compagnie Coopérative du Catenet/SCIC''', c'est à dire <br />
<br />
* une structure d'entreprise Relationnels Libres, <br />
* indépendante de sponsors commerciaux extérieurs (ce que ne sont pas les fondations subventionnées par Google). <br />
* par un statut de SCIC où elle cherchera l'équilibre sans exclusive à la française mais honni par les US : Développement En Coopération Libre, Institutionnel, Commerce ('''DECLIC'''). Les US n'acceptent d'institutionnel que si c'est le Gouvernement Fédéral et les achats de l'Armée, autrement ils privilégie l'"initiative privée" qui rapidement (en fonction de sa taille) dépend de l'"industrie washingtonienne", c'est à dire du Gouvernement Fédéral. Comme ils expliquent si bien, les US ne sont pas une démocratie mais une République (impériale : c'est à dire un protecteur des échanges périphériques au bénéfice de l'économie centrale).<br />
<br />
<br />
==== Nécessité d'un débat architectonique ====<br />
<br />
Un autre propos est de tenter de lancer un débat architectonique qui nous replace dans la réalité des choses vues par tous et pas seulement dans la virtualité des banques. <br />
<br />
Une SCIC est une entreprise commerciale qui n'a pas à distribuer de dividendes et donc ne dépend pas des marchés, mais de ses utilisateurs et employés.</div>Sysophttp://iuwg.net/index.php/Explication_fran%C3%A7aiseExplication française2015-03-12T13:06:18Z<p>Sysop: </p>
<hr />
<div>Les commentaires que je reçois pour l'instant au sujet de mon appel "iana.arpa 404" sont essentiellement la demande d'"une explication en français pour les nuls" :-). <br />
<br />
Je vais m'y attacher ici en tenant compte de vos questions et suggestions (merci de votre aide !)<br />
<br />
<br />
:1. '''les choses sont simples à ne pas comprendre''' : <br />
::c'est l'intérêt et la contribution de beaucoup qui y trouvent (''un [tès] fort'') avantage à ce que précisément, par le flou et la complication, la complexité très réelle de ce qui se passe ne puisse pas être comprise.<br />
<br />
:2. '''mon appel est de tactique digitale''' ''(en gros, cf. plus loin : informatique)''.<br />
:: Il s'inscrit dans le cadre de la politique de co-domination impériale des Etats-Unis dont la stratégie numérique ''(en gros des services sur les écrans)'' est en transition. <br />
::ll vise à forcer les tricoteurs à commencer, <br />
::*soit à en détricoter la complication ''(volontaire ou par procrastination)'' à la racine du "tricotage" de leurs petits mensonges techniques et des gros non-dits politiques qu'ils avalisent.<br />
::* soit à montrer par leur possible mauvaise foi par absence de réponse ou langue de bois<br />
::Ceci est donc en parallèle avec les efforts qui visent à en démêler l'écheveau politique.<br />
<br />
<br />
La difficulté pour moi est que mon univers se focalise sur le second point qui est la partie immergée de l'iceberg, alors que la plus part des gens en connaissent ce qu'on leur vend de la partie immergée. Toute aide pour mieux explorer, analyser, répondre et faire comprendre est donc bien venue. Mon ambition est d'en proposer la structuration au sein d'une société coopérative d’intérêt collectif pour être réellement autonome et libre de tout "sponsor" commercial. Son rôle serait une architecture libre et complète nous donnant la maîtrise et la sécurité de nos réseaux digitaux et de leur utilisation numérique.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
== Le "pourquoi" et le "comment" ==<br />
<br />
Dans les deux cas (techne [le comment] et episteme[le pourquoi]) la motivation est la même: l'éthique qui vise à optimiser les choses pour tous et chacun et non seulement pour certains et quelques-un. <br />
<br />
Pour chercher à garder les choses clairement je parlerai :<br />
<br />
* d'éthique au nveau epistémique et moral. Que faire pour mon comportement naturel m'aide à poursuivre l'esthtique à laquelle j'ai décidé de tenir.<br />
* d'éthitechnique au niveau technique et pratique. Comment construire pour que l'objet construit soit plus simple à utiliser dans le sens de mon éthique.<br />
<br />
Elles se rejoignent donc toute deux par leur recherche opérationnelle et quotidienne d'une même esthétique.<br />
<br />
== <br/> Les esthétiques en présence ==<br />
<br />
Plusieurs esthétiques sont en concurrence.<br />
<br />
* la mienne est celle du consensus officiel du sommet mondial pour la société de l'information, déclaration de Tunis, qui veut que la société de l'information soit "people centered, à caractère humain, centrada en la persona".<br />
<br />
* d'autres visent :<br />
<br />
:* un ordre philosophique ou religieux (pour l'instant techniquement peu ou pas défini).<br />
<br />
:* des dominations impériales : c'est à dire de grands systèmes politique basés sur la diversité d'échanges commerciaux internes protégés par une forte puissance militaire et un tissus d'accords extérieurs favorables. Nous sommes familiers avec la géo-politique des empires actuels, mais peut-être moins avec son histoire à long terme et donc ses résurgences.<br />
<br />
:* une supprématie matérielle : par exemple, l'unification financière mondiale par la monnaie assurant le libre échange des biens, des idées, des personnes pour le bien de ceux que Richard B. Fuller appelle astucieusement les "Grands-Pirates" (*) pour avoir visiblement émergé lors de l'apparition des grands réseaux maritimes.<br />
<br />
== <br/> Note architectonique ==<br />
<br />
Si l'on ne veut pas se sentir perdu ou entrainé vers une "théorie du complot" où ces Grands-Pirates seraient coalisés il faut se replacer dans la réalité scientifique la plus basique : c'est cela l'architectonique. La science de la compréhension concrête du réel à la base. Elle a été identfiée par Aristote qui en disait que c'est "la science" de la ''politique'' qu'il définit comme l'''art'' de la conduite des hommes libres.<br />
<br />
Le changement actuel est simplement que devant la connaissance et le nombre de gens accumulés par l'humanité, l'apport de sa pensée logique à notre cérébrique naturelle de suffit plus. Il faut que l'on se facilite les choses par des machines, jusqu'à et y compris notre intelligence naturelle : nous sommes dotés dune intelligence artificielle auxiliaire et l'avons mise en réseau.<br />
<br />
Les "hommes libres" d'Aristote sont devenus des hommes libres '''intelligemment interconnectés''' (dans l'Appel je les appelle des "IUsers" : utilisateurs intelligents.<br />
<br />
Les "Grands Pirates" ne sont donc que les opérateurs mathématique d'équilibre des ensembles dont la théorie montre que leurs mouvements sont soumis, comme les planètes [là où Poincaré les a découverts], la météo, les foules, etc. à des attracteurs. On peut les comprendre comme le parcours des centres de gravité des parcours des éléments des systèmes à trois corps et plus. <br />
<br />
Ceci fait que l'univers est en fait un maillage dynamique d'attracteurs qui s'"attractent" entre eux, chacun résultant du graphe ses composants. Nous sommes, par exemple, en train de voir le développement des bases de données orientées graphe (Neo4j, GraphDB, etc. : il suffit de regarder "le Bleu" dans NCIS pour en toucher la puissance).<br />
<br />
Je fais allusion dans l'appel à <br />
<br />
* l'"agorique" comme nom donné à la théorie du syllogisme étendue par les réseaux de <br />
:* discours dialectiques [raison logique], <br />
:* aux discours monolectiques [expérimentation cybernétique].<br />
:* et polylectiques [3 à n corps - agorique des marchés]).<br />
* l'''intellition'', comme nom donné à la science de l'intelligence des choses entre elles. C'est ce que l'on appelle la capacité de '''religion''' c'est à dire de '''re-ligere''' les choses entre elles (hypertexte [lien vers page] de Doug Engelbart ou interliens des ontologies [lien vers idée]. L''''intellition''' est la discipline de ce qui fait sens à partir de toutes les '''informations''' réunies par la '''communication'''.<br />
<br />
Par exemple, la Liberté de la Presse professionnellement ou PRISM (NSA) industriellement sont solution d'intellition.<br />
<br />
== <br/>Mon intervention tactique ==<br />
<br />
Pour l'instant sur le catenet (réseau de la globalité des ressources digitales mise en partage) règne sans partage le code de la route de l'internet après avoir politiquement évincé ce qui ne lui était pas NSA-compatible [essentiellement technocratiquement hiérarchique vs. holo/omnicratiquement distribué].<br />
<br />
Les US tentent d'utiliser cette domination au niveau de l'usage protocolaire avant qu'elle ne s'effrite pour prétendre à une propriété légale du catenet (nos machines, lignes, savoirs, etc.) lui-même (cf. Obama : l'internet est à nous au départ) par droit de premier usage.<br />
<br />
Ma position est :<br />
<br />
* 1. de remettre en cause ce premier usage au point de vue historique car il est manifestement partagé et matériellement devancé par la région de Versailles :-) <br />
<br />
* 2. de remettre en cause la qualité générale de ce premier usage. Ils ont trés certainement inventé TCP/IP mais le Catenet a été identifié par Louis Pouzin pour y faire échanger ses datagrammes sous une architecture plus puissante et générale comprenant entre autre la couche six "présentation" assurant le "non-NSA-compatible" (encryptions, formats, intelligence, multilinguisme)<br />
<br />
* 3. de me faire expliquer en quoi l'abdication des soi-disant premiers arrivants (les architectes et ingénieurs de l'IAB) quant au contrôle de l'ensemble nous assurait d'une stabilité technique par l'emprise d'un commercial opérationnel trop important pour mourrir ("too real to die").<br />
<br />
* 4. de me dire comment ils voyaient l'interopérabilité de leur technologie internet avec les nouvelles architectures se déployant sur le catenet en concurrence ou complément avec/de leur architecture internet (dont celle que je propose aux relationnels libres) puisque tout leur discours face à la "permissionless innovation" est un "status-quo" pratique. <br />
<br />
::En fait, ils veulent une innovation à partir ou en corrélation avec leur niveau internet, et non à partir de notre niveau catenet où ils ne contrôlent rien <br />
<br />
:: ce sont les ISP qui contrôlent et qui sont prêts à tout supporter du moment qu'ils gagnent plus surement leur argent - c'est cela la "neutralité du net" : du catenet, pas de l'internet !). <br />
:: c'est notre multitude qui contrôlons au final par nos machines, nos boîtes, nos connexions, nos paiements.<br />
<br />
::Pour bien métaphoriser : l'internet c'est Obama, le catenet c'est nous. Cela marche mieux ensemble si on est un Yankeezen. D'où le besoin de TPP et TAFTA pour s'assurer que tout cela soit régulé en bon ordre par la FCC. Et que l'ensemble digital "US/OTAN commercial/OTASE commercial" compris dans les semaines qui ont suivi le 11 septembre, entraîne les BRICS dans son sillage économique.<br />
<br />
== <br/>Digital / Numérique ==<br />
<br />
Comme d'hab, actuellement tout au moins, notre souci français est de faire comme les Anglo-Saxons tout en faisant croire que non. Les A-S disent "digital", nous dirons "numérique", quitte à se planter tous les deux !<br />
<br />
Encore une fois la différence théorique a <br />
* des racines théoriques grecques (Démocrite [atome] et Aristote[continuité]), <br />
* des racines pratiques et manufacturières françaises (Basile Bouchon) <br />
* et des racines économiques anglo-saxonnes (Charles Babbage) puis Holerith.<br />
<br />
<br />
==== La métaphore du "pattern" (broderie) ====<br />
<br />
:Bouchon est le tisserand lyonnais inventeur du digital. Il a pris une bande de papier (continue) et y a fait un trou avec son doigt pour dire que cela faisait 1 dans une bande de 0. Son ouvrier Jean-Baptiste Falcon a trouvé que c'était plus solide en carton et inventé la carte perforée. Et Joseph Jacquard a finalisé les trois couches :<br />
<br />
:* la discontinuité digitale des points à l'endroit qui forme la broderie dont de loin notre perception va créer la continuité de l'image. ''(Ce que l'on voit à l'écran)''.<br />
<br />
:* la toile, le cas échéant multipièce du catenet (le réseau des réseau) qui sert de support : complexus en latin veut dire ... toile. Le cyberespace, nouvel environnement de l'homme - comme nous le montre le Livre Blanc de notre Défense. ''(L'écran)''<br />
<br />
:* la continuité numérique des fils de l'envers que nous ne voyons que comme complication. ''(tout ce qu'il y a derrière l'écran)''.<br />
<br />
==== La métaphore d'Euclide ====<br />
<br />
:Nous savons tous qu'entre deux points d'Euclide passe une droite où le segment entre ces deux point a une infinité de points.<br />
<br />
Entre deux pixels il n'y a rien. Et cela marche !<br />
<br />
==== La métaphore mathématique ====<br />
<br />
:http://fr.wikipedia.org/wiki/Math%C3%A9matiques_discr%C3%A8tes. Les mathématiques informatiques et donc leurs réseaux relèvent en très forte partie des mathématiques discrètes ou digitale par opposition aux mathématiques numériques ou continues.</div>Sysophttp://iuwg.net/index.php/IANAPLAN_Appeal_to_the_IESGIANAPLAN Appeal to the IESG2015-03-11T17:13:37Z<p>Sysop: </p>
<hr />
<div><br />
Cette page est obsolete et remplacée par [[IANAPLAN_Appel_à_l'IESG_-_Historique]]<br />
<br />
<br />
----<br />
<br />
<br />
''Cette page est destinée au points, motivations et suivi de l'appel de JFC MORFIN auprès de l'IESG, et probablement de l'IAB et de l'ISOC (procédure d'escalation ordinaire) concernant les modalités de transition du IANA par le '''NTIA''', responsable des datacommunications au sein de l'exécutif américain où il est l'équivalent de la '''FCC''' au niveau législatif.''<br />
<br />
''Manifestemet la stratégie de l'administration Obama peut être lue comme visant à transférer <br />
* ''la supervision '''opérationnelle''' d'une part de l''''Internet''' par le NTIA (ce qui a une nature de '''dominion de circonstance''' de plus en plus politiquement et techniquement contesté),<br />
* ''vers une supervision '''juridictionnelle''' définitive du '''Catenet''' mondial par la FCC (ce qui correspond à une '''colonisation stable de la digitalité mondiale''').<br />
<br />
<br />
<br />
----<br />
<br />
<br />
'''20150311''' : j'ai envoyé mon appel à l'IESG contre l'illisbilité pratique de leur position concernant la transition demandée à l'ICANN par le NTIA.<br />
<br />
Il a été enregistré par l'IESG (Internet Engineering Steering Group)à l'URL : <br />
<br />
<center><big>'''http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf'''.</big></center><br />
<br />
'''Attention''' : le document fait '''72 pages''' (et pose '''36 questions''' clé) ! <br />
<br />
Cet appel est placé dans le cadre du devoir de précaution constitutionnel pour chaque citoyen français informé du danger que représente un développement technique. <br />
<br />
Un commentaire et un suivi en seront maintenus sous http://iuwg.net/index.php?title=IANAPLAN_Appeal_to_the_IESG.<br />
<br />
<br />
----<br />
<br />
<br />
Le danger est l'incompréhensibilité ménagée par l'"affinity group" des leaders de l'ICANN/IETF (le nom en est défini par la RFC 3774 sur le problème de l'IETF). Elle est destinée à <br />
<br />
* aider à perpétuer la dominance américaine sur le '''Catenet''' (la concaténation globale des ressources digitales mises en partage : le "réseau des réseaux" de Louis Pouzin) <br />
* afin de continuer à en contrôler les utilisations "locales" (c'est à dire à nos réseaux virtuels "glocaux" - ou "VGN" : virtual glocal networks - le concept est explicité dans le "paradigme de Cerf" repris dans le document). <br />
* par passage sous un maillage (multipartieprenance) de droit contractuel (privé et multilatéral [TIPP, TAFTA, ICANN]) et sous animation/référence technico-juridique de la FCC.<br />
<br />
Cet appel se positionne dans le contexte actuel tel que reconnu par <br />
* le document OpenStand (RFC 6852) cosigné par IEEE/IETF/IAB/ISOC/W3C <br />
* selon lequel nous sommes dans une coopétition normative multitechnologies.<br />
<br />
Le gouvernement américain cherche à :<br />
* positionner les retombées de son investissment internet (Obama: l'internet est à nous) pour établir une dominance juridique définitive sur le '''Catenet''',<br />
* avant que cette technologie internet d'utilisation du Catenet ne rentre dans le rang du''' multi-technologie initial''' - qu'ils ont réussi à contrer, en fait contre la France, pendant 30 ans.<br />
<br />
<br />
__TOC__<br />
<br />
<br />
<br />
== Communiqué initial ==<br />
<br />
Pour information j'ai envoyé mon appel à l'IESG contre la décision de publier une position stérilisante, car volontairement illisible concernant la transition demandée à l'ICANN par le NTIA (exécutif américain) pour en fait utiliser le contrôle politique américain encore rémanent de l'internet pour établir le contrôle juridique de tout le catenet (concaténation de la globalité des ressources digitales mises en partage) de la FCC et donc du Congrès américain et de ses lobbys militaro-industriels avant que ne s'installe le "multi-technologies" par l'"innovation sans permission".<br />
<br />
1. Vous trouverez le texte de cet appel (71 pages) sous : https://www.dropbox.com/s/ckqaaq0ngqed0ie/iesg-appeal-inanaplan.pdf?dl=0 et normalement listé, d'ici quelques heures, sous http://www.ietf.org/iesg/appeal.html - à moins que les YankIETF fassent de la résistance.<br />
<br />
2. Je le place dans le cadre du devoir de précaution constitutionnel pour chaque citoyen français informé du danger que représente un développement technique. Je l'ai aussi adressé à l'Assistant Secretary L.E. Strickling, patron du NTIA. Normalement la procédure d'appel et les délais impartis retardent la procédure jusqu'à quatre mois et permettent à chacun d'en profiter pour poser des questions de fond sur la gouvernance et la souveraineté de la digisphère. <br />
<br />
3. Il importe peu que l'on soit d'accord ou non avec moi. Le but est de permettre à chacun de se positionner dans un débat qui est fondamental à tout droit de l'internet, du digital, du numérique et sans doute de la société actuelle. Je maintiens son commentaire et son suivi sous http://iuwg.net/index.php/IANAPLAN_Appeal_to_the_IESG. En prenant date, il importe en fait peu que les responsables de l'IETF (standardisation), IAB (architecture), ISOC (sponsoring), NTIA (politique), etc. répondent. Leur absence de réponse ne ferait que légitimer de façon claire le bien-fondé de chacun à considérer son droit/devoir de précaution pour ses biens digitaux et l'accès aux services numériques qu'il utilise, et donc de rechercher ensemble des solutions plus claires, transparentes, neutres et stables.<br />
<br />
Je suis preneur de toute coopération, aide et assistance à ce sujet que j'entends, pour ce qui me concerne, canaliser à travers la création d'une société coopérative d'intérêt commun indépendante de tout sponsor, statutairement fondée sur l'omnipartieprenance (1 homme = 1 voix), permettant d'apprendre la coopération numérique en coopérant au niveau du réel "glocal", et dont l'objectif sera de fournir à chacun les moyens et relationnels libres lui assurant sa maîtrise digitale et la protection de son "privatoire" c'est à ce qui fait sa personne privée et dont trop d'intérêts politiques, stratégiques, commerciaux, économiques cherchent à le priver.<br />
<br />
== Propos ==<br />
<br />
Par cet appel je cherche aussi des réponses:<br />
<br />
<br />
==== Savoir qui est à la manoeuvre ? ====<br />
<br />
L'un des propos de cet appel est de voir qui est aux commandes en voyant qui va répondre au final : IESG, IAB, ISOC ou NTIA (le document a été personnellement annoncé à Lawrence Strickling, le patron du NTIA).<br />
<br />
Il est aussi de savoir qui, en France, en Europe et dans le monde est suffisament informé, compétent, motivé, etc. pour contribuer à la construction commune nécessaire, selon une vision adhoc pragmatique et adaptée à la singularité technologique que nous vivons qui :<br />
* n'est que "techno-logique" (on facilite notre raison logique cérébrique naturelle avec de la cérbrique artificielle auxillaire) <br />
* et n'en est pas pour autant "post-humaine" et conduisant à "''l'homo gougliensis''" !<br />
<br />
<br />
==== Le contexte de lancement de la CCC SCIC ====<br />
<br />
Le pas suivant sera la création de la '''Compagnie Coopérative du Catenet/SCIC''', c'est à dire <br />
<br />
* une structure d'entreprise Relationnels Libres, <br />
* indépendante de sponsors commerciaux extérieurs (ce que ne sont pas les fondations subventionnées par Google). <br />
* par un statut de SCIC où elle cherchera l'équilibre sans exclusive à la française mais honni par les US : Développement En Coopération Libre, Institutionnel, Commerce ('''DECLIC'''). Les US n'acceptent d'institutionnel que si c'est le Gouvernement Fédéral et les achats de l'Armée, autrement ils privilégie l'"initiative privée" qui rapidement (en fonction de sa taille) dépend de l'"industrie washingtonienne", c'est à dire du Gouvernement Fédéral. Comme ils expliquent si bien, les US ne sont pas une démocratie mais une République (impériale : c'est à dire un protecteur des échanges périphériques au bénéfice de l'économie centrale).<br />
<br />
<br />
==== Nécessité d'un débat architectonique ====<br />
<br />
Un autre propos est de tenter de lancer un débat architectonique qui nous replace dans la réalité des choses vues par tous et pas seulement dans la virtualité des banques. <br />
<br />
Une SCIC est une entreprise commerciale qui n'a pas à distribuer de dividendes et donc ne dépend pas des marchés, mais de ses utilisateurs et employés.</div>Sysophttp://iuwg.net/index.php/ReligionReligion2015-03-10T23:55:36Z<p>Sysop: </p>
<hr />
<div>Il convient dans notre monde actuel de s'en tenir au mot juste des choses car notre monde - comme le montre la NSA - est de plus en plus mécanisé (''marges d'incertitudes réduites au sein de systèmes organisés'') et donc tributaire de la "'''mécalinguisation'''". Ceci a des avantages pour avancer plus loin et se mieux comprendre mais aussi des désavantages car des flous admis depuis des siècles d'habitudes vont en être remis en question. La langue française est ainsi la plus "mécanisée" (on dit métalinguistique ou auto-documentée) pour une raison très simple : l'arrêt de Villers-Coterêt a fait de la langue française la langue de la loi, et par là de son dictionnaire de l'Académie un livre ... de droit). La Révolution avait même un temps supprimé l'Académie pour la remplacer par la Covention, car la langue de la Loi devait être écrite par la Loi.<br />
<br />
<br />
Ainsi, le mot religion, par exemple, signifie la''' capacité de relier des choses entre elles''' en une suite tellement logique qu'elle peut en être '''comprise''' de façon cohérente avec d'autres ('''cum-prehendere''' - pris ensemble)et en devient vérité pour celui qui en a formé et validé la séquence "intelligente" (inte-legere, interlier). L'exemple type en est celui, bien connu pour se "faire une religion" au sujet des énigmes policières avec l'aide de ses "petites cellules grise" (''sa cérébrique naturelle'') : '''Hercule Poirôt'''.<br />
<br />
Une culture, un Etat, une famille, etc. peuvent ainsi se former une "religion" qui se transmet par l'éducation et qui en solidifie le corps social. C'est, par exemple, le cas de la "religion de l'Empereur" à Rome. L'Empereur est celui qui relie les entités de la société et en organise la protection mutuelle.<br />
<br />
Aujourd'hui, nous automatisons cette poursuite de la religion des choses et de leur intelligence, pour en préssurer l'information qui y est contenue (phénomène de l''''intellition''' du syllogisme - un discours implique une information nouvelle).<br />
<br />
Le mot, lors qu'il est prit dans un sens global, non seulement de compréhension scientifique du "comment" (techne) mais aussi du "pourquoi" (épistémé) de l'Univers, avec une référence métaphysique à un moteur premier ou un créateur appelé Dieu, l'on passe de "'''religion'''" à "'''Religion'''". Mais là encore il faudra utiliser le mot exact pour différencier ce qui est une compréhension ou une acceptation scientifique, philosophique, prudentielle ou théologique, plus ou moins empreinte de psychologie, sociologie, de libre-arbitre, de sentiments et de don de soi.<br />
<br />
Scientifiquement, la "religion" ("r" minuscule) est (au stade actuel de l'état du développement mathématique) l''''application de la théorie des graphes'''. Elle est passée du '''linéaire''', au '''hierachique''' (ex. nommage), au '''tabulaire''' (SQL), aux '''réseaux maillés''' (Neo4j, graphes, NoSQL).</div>Sysophttp://iuwg.net/index.php/Centizen_For_What%3FCentizen For What?2015-03-10T14:00:31Z<p>Sysop: </p>
<hr />
<div><br />
Nous avons eu hier à Montpellier la projection du film "Citizenfour", ce qui est sans doute un jeu de mots : « citizenfour » pour « citizen for », mais « for what ? ».<br />
<br />
''"'''centizen'''" est un calembour de ma facture : les "2 cents" auxquels les Yankees ont l'habitude d'évaluer leurs contributions : les four cents des citizens Edward et Lindsay, ont une allure certaine ! et vallent bien les milliards de dollars dépensé à nous épier ...''<br />
<br />
<br />
<br />
La discussion a été animée par deux journalistes qui ont fait assaut d'esprit (élevé mais) de chapelle en se focalisant de manière intéressante (ils sont les premiers concurrencés) pour leur suite professionnelle, sur leur ressenti de ce qui est en fait la nationalisation de l’industrialisation de leur métier (ils en ont oublié sa privatisation parallèle en cours, cf. in fine)<br />
<br />
Le public en a soulevé plusieurs points à murrir (il y en a d'autres que j'oublie)<br />
<br />
* "Snowden a fait appel à des journalistes pour l’aider" - <br/> qu’il a su manipuler en distillant les informations – au passage où sont les fichiers Snowden pour être si bien protégés de la NSA ?<br />
* "Etrangeté américaine de donner un Oscar au film sur la trahison d’un potentiel condamnable à mort selon une loi de 1840 qui n’aurait servi que sept fois".<br/> Ma remarque que l’Oscar avait été payé par la NSA a fait rire, mais pas encore réfléchir.<br />
<br />
* "La seule réponse possible est la loi appliquée par les Juges sous le contrôle des élus ("les politiques")".<br/> Très exactement ce qu’Obama est en train d’accomplir par le passage de témoin du NTIA à la FCC, avec le corollaire que -- pour que cela marche -- l’on ait une colonisation mondiale américaine de la digitalité puisqu’il faut la même loi, les mêmes circuits de Justice, les mêmes forces d’application, la même soumission aux mêmes accords de commerce, etc. soutenus par la même [[religion]] (ce qui relie) et éthique citoyenne.<br />
<br />
* "Pauvre Snowden qui a du se réfugier dans un pays totalitaire et quitter le pays des droits de l'homme".<br/> En etes-vous sûr demande une dame au vu du film que nous avons vu, d'un honnêtte brave jeune homme pourchassé par le violeur mondial de la vie privée et terminant en paix dans sa cuisine avec sa compagne.<br />
<br />
<br />
__TOC__<br />
<br />
==<br/> Snowden ==<br />
<br />
Le personnage concerné et partiellement inconscient de Snowden est convaincant. Ce n’est pas un acteur. C’est un électron libre ou un manipulé, ce qui revient au même dans l’impact de ce qu’il provoque : il ne pense pas que tout cela peut s’arrêter dans la seconde par le tir d’un snipper ou d’un drone. Il en a la garantie culturelle par ce que c’est ainsi qu’il a été éduqué à son pays, ou la garantie morale inculquée par ce qui lui a été dit dans le contexte culturel de la NSA, malgré le quotidien qu'il en avait et qu'il dénonce d'un total irrespect de la loi par ses chefs en situation de guerre globale.<br />
<br />
En tant qu’officier de marine (de la passerelle nautique au navigateur digital), je connais très bien le problème éthique à laquelle il est confronté. De Gaulle a fait modifier la conception de la discipline, force des armées, en ce qui concerne l’obéissance qu’il n’avait pas respectée et qui avait été l’axe de défense des prévenus de Nuremberg. '''Le subordonné n’a pas à exécuter un ordre illégal'''. Ceci est un dilemme monumental car précisément nous sommes là dans le domaine de la souveraineté nationale, c'est-à-dire la capacité constitutionnelle à la violence faite à l’ordre matérialisé par la Loi internationale. Il appartient donc au subordonné de décider si par l’ordre qu’ils lui donnent ses supérieurs violent les ordres qu’ils ont eux-mêmes reçu ou que permet la Constitution au Chef légitime de la Violence d'Etat pour la protection de ses concitoyens. <br />
<br />
Ceci est d’ailleurs antérieurement illustré dans le film par les réponses faites (à mon souvenir) postérieurement par ces supérieurs.<br />
<br />
==<br/> Le film ==<br />
<br />
A l’occasion de ce film bien monté d’une interview de huit jours, l’on se focalise sur les états d’âme (fondamentalement respectables, tout autant que ceux du personnel de Guantanamo, des banquiers français, etc.) d’Edward et des retombées sur Lindsay. Mais on oublie que ce qui en est le déclencheur est le formidable basculement sociétal de la '''singularité techno-logique''' dans laquelle nous sommes embarqués, où nous avons à bâtir un nouveau rapport personnel à des choses qui nous semblaient stables comme la Réalité, le Droit, la Politique, l’Economie, la Personne, la Pensée logique et la Raison par le fait que la '''techne''' devient pour nous la possibilité de manipuler (Virtualité) et d’étendre (Digitalité) notre espace vital. Dans ce contexte notre « religion », c'est-à-dire l’environnement mental que nous nous sommes construit pour relier entre elles les prémisses de l’environnement réel, est à mettre à jour, avec l’aide de notre '''épistémè''', notre capacité à comprendre le « pourquoi » à partir des progrès de notre science du « comment ».<br />
<br />
==<br/> Notre réponse ==<br />
<br />
Il est certain que la réflexion de '''Bernard Stiegler''' sur les '''pharmakons''' (Snowden en est-il un? ) qui peuvent nous y aider est première (pour reconstruire il faut d’abord survivre) mais nous ne pourrons faire l’économie d’une révision architectonique (science de la réalité) qui conditionnera nos industries (notre facilitation du réel confrontée à ses nouvelles perspectives) et de nos architectures (les moyens de le faire).<br />
<br />
Il n’en reste pas moins, que ce que joue assez finement Obama, il est d’ailleurs présenté dans le film, impliquant qu’Edward lui a coupé l’herbe sous le pied : c’est la transition d’une singularité ancienne (la singularité logique grecque) qui doit en être pragmatiquement violée, vers la singularité nouvelle (l’adjonction de la technique à la logique pour pouvoir traiter de la complexité, par une cérébrique qui dépasse la notre mais qui doit rester sous notre contrôle collectif [société] et individuel [personne]).<br />
<br />
Le problème que ne résout toutefois pas Obama semble-t-il, est le rapport de cette singularité à l’aspect financier de l’économie : tout cela coûte cher et les commissions demandées par le monopole radical (cf. Ivan Illich) des industries, du crime et de la corruption en place sont trop élevés. La seule réponse que nous pouvons y apporter est l’esprit ouvert (sur l’avenir en ne fermant/figeant pas les normes) : '''celui du Libre'''. Mais un Libre qui prenne en main non seulement le '''local''' (machine, logiciel applicatif, OS, etc. des logiciels libres) mais qui s’étende aux '''global''' par les Relationnels Libres ('''RelLibs''') et déverrouille l’emprise du '''NSA-compatible''', hérité de la pensée UNIX, auquel je suis confronté depuis 1985 (ils m’en ont mis à la porte de mon job, et depuis je rôde autour pour savoir comment le reprendre :-) !!!). <br />
<br />
Ce qui est en train de se passer est que l’expérience acquise à force de piéger la communication (les travaux de construction du centre de surveillance NSA, la suite des travaux qu’introduit Binney) font que nous sommes passés à l’échelle de l’'''intellition''' que tous continuent à ignorer superbement le principe, bien que ce soit le sujet et l’investissement principal actuel. <br />
<br />
* Claude Shannon nous a expliqué l’'''information''' (ce qui augmente la connaissance). <br />
*on a pris la part sur son transport pour en faire la base de la '''communication''' (ce qui étend le nombre de connaissants et augmente la concaténation de leurs connaissances – les '''big data''' au final). <br />
* mais personne n’a encore écrit une théorie de la communication dont l’épilogue serait necessairement l’'''intellition''' (ce qui permet de miner de l’information dans la connaissance réunie, l'information qui "fait sens"). <br />
: Le basculement des bases de données orientées '''graphe''' en est un exemple pratique actuel. Il s’agit du catenet sémantique : le réseau des réseaux de connaissance.<br />
<br />
Snowden marque en fait l'entrée en force de l'intellition dans la réalité '''actuelle''' et non-plus '''virtuelle'''. J'ai tendance à comprendre la stratégie Obamesque comme celle de Chirac lors des derniers essais nucléaires dans le pacifique. Il nous fallait finaliser notre expérience pour pouvoir simuler et non-plus expérimenter. Pour la NSA les choses en sont de même : les systèmes informatiques et de communication (les logs du fichier racine, les écoutes téléphoniques, etc.) ne sont plus absolument nécessaires. Ils ont suffisament de données d'expérience (données sur l'utilisation des données) pour ne plus en avoir absolument besoin. De la même façon que notre cerveau utilise, en fait, très peu de données des sens sur notre environnement pour nous permettre d'imaginer la nature du contexte auquel nous croyons (et à d'autres de l'illusionner).<br />
<br />
==<br/> Amateurisme personnel, artisanat journalistique cherchent industriel ==<br />
<br />
Nos journalistes en sont là. Leur intellition naturelle (fondée sur leur intelligence personnelle et de leurs collaborateurs <br />
<br />
* leur permet de qualifier le nouveau maire de Montpellier de Divers-Droite [exemple pris des questions d’hier soir] et non de Divers Gauche comme il s’est fait élire), <br />
* mais ne leur permet pas d’aller plus loin faute de moyens. Comme les services secrets de Sa Majesté ont fait mieux que PRISM (qui en parle à part Snowden ?), les journalistes britanniques (BBC et Press Association) sont allés plus loin : avec par exemple la base de données ontotext GraphDB (http://www.ontotext.com/customers/). <br />
<br />
Nous avons là simplement un déficit français typique : la référence n’est pas américaine mais en l’occurrence bulgare. Notre '''Dandyankisme parisien''' nous joue un autre tour :-) Les big-data ne sont pas une vue de l'esprit, mais des milliards de sources que certains analystes peuvent utiliser et d'autres pas. Plus besoin de protéger ses sources : elles s'appellent les réseaux sociaux.<br />
<br />
La question est donc celle de la limite éthique entre le '''privé''' (ce que je veut garder secret) et le '''privatoire''' (ce dont autrui peut s'estimer en droit de me priver). Les discussions actuelles de la loi chinoise à ce sujet et la réponse américaine est sans doute '''LE''' sujet que nous devrions suivre avec le plus d'attention si nous voulons tirer des enseignements de l'expérience.<br />
<br />
==<br/> Nous nous avons à aller plus loin. ==<br />
<br />
Notre problème est celui du financement. C’est un problème du paradigme précédent qui était celui du syllogisme linéaire et donc hierarchique. Il faut au sommet un réservoir à billets.<br />
<br />
L’apport du paradigme nouveau est celui du syllogisme maillé (qui réclame cette techno-logie que nos technocrates ont recherché dans l’organigramme et Louis Pouzin a trouvé dans le catenet : les chaînons manquants/intervenants sont tout azimut). L'apport en argent peut être diffus et il peut être en nature - possiblement donné.<br />
<br />
Nous avons déjà beaucoup investi (nos ordinateurs, boxes, logiciels, abonnements FAI, apprentissage) : il faut donc que nous travaillions à ce que '''le tout de ce catenet''' (les ressources digitales mises en partage) soit supérieur à '''la somme de ses parties sous NSA-compatibilité''' et son soutien par intérêt objectif du GAFA et du Département US du Commerce ). '' Au passage : qui connait l'adversaire : http://www.export.gov/advocacy/ ???''<br />
<br />
Obtenir ce tout supérieur à la somme des composants réunis, cela a un nom simple : l’'''intelligence maillée du [http://catenet.org catenet]'''.<br />
<br />
Au boulot mental, donc, si l’on veut poursuivre sur la prise de risque somatique d’Edward et de Lindsay !<br />
<br />
jfc</div>Sysophttp://iuwg.net/index.php/Catenet_TransitionCatenet Transition2015-03-10T13:54:00Z<p>Sysop: Created page with "The '''Catenet''' (Louis Pouzin's "network of networks") is the '''global''' concatenation (latin "Catena": chain) of all the '''digital''' resources collectively contributed..."</p>
<hr />
<div>The '''Catenet''' (Louis Pouzin's "network of networks") is the '''global''' concatenation (latin "Catena": chain) of all the '''digital''' resources collectively contributed by all of us that we can '''virtually''' use on a '''local''' basis (i.e. through a private VGN : virtual glocal network) <br />
<br />
:::''" The term "local" is used in a loose sense, here, since it means "peculiar to the particular network" rather than "a network of limited geographic extent." ''<br />
<br />
* [[Centizen For What?]] (French).</div>Sysophttp://iuwg.net/index.php/Ronda_Hauben_-_Finding_the_Founding_Fathers_of_the_InternetRonda Hauben - Finding the Founding Fathers of the Internet2015-03-03T22:23:42Z<p>Sysop: Created page with "Why there is a Need for a History of the InternetVersion originale en anglais de art258, rub22Who are the founding fathers of the Internet? This question was raised a few year..."</p>
<hr />
<div>Why there is a Need for a History of the InternetVersion originale en anglais de art258, rub22Who are the founding fathers of the Internet? This question was raised a few years ago in an article on the front page of the Wall Street Journal.[[ « Paternity Suits Some Better than Others….The Father of the Internet-…Remains a Matter of Much Dispute» par Lee Gomes, <br />
<br />
Friday, June 18, 1999, p. 1. Though the reporter could not provide an answer, his article alerted readers to the controversy. And this issue is but one of many that will need a history of the Internet to resolve. <br />
<br />
It may come as a surprise that the history of the Internet is for the most part a history that is still to be discovered and a history still to be written.[[ Plusieurs livres documentent les différents aspects de l’histoire d’Internet et d’autres les développements liés à la fondation d’Internet. Parmi ceux-ci : Katie Hafner et Matthew Lyon, « Where Wizards Stay Up Late », 1996, N.Y., 1996, Peter Salus, « Casting the Net », Reading, Mass, 1995, Michael Hauben et Ronda Hauben, « Netizens: On the History and Impact of Usenet and the Internet », Los Alamitos, 1997. Howard Rheingold, « Tools for Thought », 1985, Janet Abbate, MIT Press, Cambridge « Inventing the Internet », 1999. Voir également Roy Rosensweig, « Review Essay: Wizards, Bureaucrats, Warriors, and Hackers: Writing the History of the Internet », dans l’« American Historical Review », December 1998. One reason why this is true, concerns the problem: How to understand the birth and early development of the Internet when its birthplace was within the U.S. Department of Defense (DoD)? Historians like Paul Edwards in his book « The Closed World », view this birthplace with suspicion and alarm. Others, like Arthur Norberg and Judy O’Neill in their book, « Transforming Computer Technology » treat this birthplace as the result of a mutually beneficial partnership between computer scientists and the DoD.[[ Paul Edwards, « The Closed World », Cambridge, 1996. Arthur L. Norberg et Judy E. O’Neill, « Transforming Computer Technology », John Hopkins University Press, 1996.<br />
<br />
Neither recognizes that the relationship of computer scientists and the DoD has been a contradictory relationship, and one that requires careful examination in order to understand the birth and early development of the Internet.<br />
<br />
The birth of the Internet was under the protection of a very special government institution that was created inside the DoD in the 1960s. That institution is the Information Processing Techniques Office (IPTO). The IPTO, during the years of its existence (1962-1986), made possible a number of breakthroughs that have fundamentally changed the nature of computing. These breakthroughs include interactive computing, time-sharing, interactive graphics, packet switching, the creation of the ARPANET and perhaps most importantly, the creation of the Internet. <br />
<br />
The founding director of this office was J.C.R. Licklider who created IPTO in 1962. During his first turn as director, he was able to give leadership to a broad and visionary program of basic research in computer science which included the creation of an IPTO research community. Licklider called this community of outstanding computer scientists who collaborated with each other, the Intergalactic Network. This scientific community provided a foundation for Licklider’s vision of a computer network which would make it possible for people around the world to collaborate and for all who were interested to gain access to the network and to be able to communicate in ways not hitherto possible. <br />
<br />
Though it was too early for research work in networking during Licklider’s first turn as director at IPTO, when research became possible at the end of the 1960s and in the early 1970s, it was carried out under the leadership of the IPTO.[[ Le directeur de l’ IPTO pendant cette période fût Robert Taylor 1966-1968, et ensuite Larry Roberts 1968-1973. When Licklider returned as director in January, 1974, however, he found the environment had changed. Instead of receiving the support he needed to develop a new research program, Licklider was pressured to require milestones in contracts he wrote with researchers. As one computer science researcher, Les Earnest, describing this period commented, « There’s no way to schedule discoveries. » The pressure experienced during Licklider’s second turn at IPTO demonstrates a problem that had been recognized in the 1950s and which had been considered in the design for the Advanced Projects Research Agency (ARPA), the parent agency.<br />
<br />
This problem had to do with difficulties that had previously occurred in the efforts to employ civilian scientists in scientific laboratories administered by the DoD. Hearings held in 1954 by Congressman R. Walter Riehlman from New York in the U.S. House of Representatives noted that the orientation of the scientist is to create the new and to explore the unknown. This is fundamentally different from the orientation of the military officer to command others to carry out a planned campaign or to issue a set of orders. Unless there is a conscious and appropriate effort to provide for these differences in temperament and perspective, the activities of the military officer can make it impossible for the computer scientist to create the new theories, the new principles, or the new conceptual understandings that are needed by society. These are what the welfare of the modern nation and the national security depend on.<br />
<br />
When designing the institutional form for ARPA, there was an effort to provide an equality for scientists working alongside the military officers. In 1969, however, the U.S. Congress introduced the Mansfield Amendment pressuring the DoD to pursue only basic research related to military applications. The nature of basic research, however, is that it cannot be tied to a product outcome, not to a product of war nor to a product of peace. Though Congress softened the requirement of the Mansfield Amendment, even repealing it in subsequent years, the pressure from this Amendment led to a changed environment within ARPA. At IPTO it became more difficult to provide the protection needed to support the work of the IP research community.<br />
<br />
The environment that IPTO flourished under within early ARPA was a special environment created to support and provide protection for scientific research and discovery. Unless this environment is understood, it is not possible to understand the special conditions of the birth and early development of the Internet and the conditions needed for it to continue to grow and flourish. The current DNS wars over who will control the Internet by controlling the Domain Name System, the root server system, the IP numbers and the protocols, all essential functions of the Internet, show what power struggles ensue when the needed protection for the Internet is removed.[[ Pour qu’Internet puisse fonctionner, il est nécessaire, de disposer de paramètres uniques et globaux comme le code IP . Le contrôle du systéme de codification IP est un point essentiel pour contrôler la totalité d’Internet. Le système des Noms de domaines, le systéme des serveurs-racine et les processus issus des protocoles sont également essentiels au fonctionnement d’Internet. Si quelqu’un contrôle ces systèmes , il peut sans difficulté contrôler la totalité d’Internet Pour une discussion sur ce sujet voir, « The Amateur Computerist », vol 9, no. 1 [http://www.ais.org/~jrh/acn/ACN9-1.txt; Voir également : Cone of Silence http://www.heise.de/tp<br />
<br />
Another problem in developing an accurate history of the Internet is that most of the histories thus far present the creation of the prototype packet switching network, the ARPANET, as the beginning history of the Internet. There is a need to examine whether the creation of the ARPANET was actually the beginning of the Internet. The ARPANET was begun in 1969 to make it possible to connect diverse computers and diverse operating systems to be able to share computer resources.<br />
<br />
By the early 1970s, however, other packet switching networks were being created to meet different requirements and different needs. In November, 1972, Robert E. Kahn joined IPTO as a Program Manager. Kahn had been part of the engineering team at Bolt Beranek and Newman (BBN) in Cambridge that won the ARPA contract to build the IMP subnetwork for the ARPANET. At IPTO, Kahn became interested in the problem of how to connect a ground packet radio network (PRNet), a packet satellite network (SATNET), and the ARPANET.. These networks were significantly different and connecting them presented a challenge. Kahn’s question was: « How can I get a computer that’s on a satellite net and a computer on a radio net and a computer on the ARPANET to communicate uniformly with each other without recognizing what’s going on in between? »[[ Hafner and Lyon, p 223. Kahn called the conceptual framework developed to solve this problem « open architecture. »[[ Leiner, Barry M, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G. Roberts, Stephen Wolff (1998). « A Brief History of the Internet, version 3.1. » (Online) <br />
<br />
http://www.isoc.org/internet/history/brief.html « Open architecture » recognized that different kinds of packet switching networks would be designed to meet diverse local and particular requirements and that no internal changes should be required to any network to connect it to the others.<br />
<br />
By the early 1970s, however, other packet switching networks were being created to meet different requirements and different needs. In November, 1972, Robert E. Kahn joined IPTO as a Program Manager. Kahn had been part of the engineering team at Bolt Beranek and Newman (BBN) in Cambridge that won the ARPA contract to build the IMP subnetwork for the ARPANET. At IPTO, Kahn became interested in the problem of how to connect a ground packet radio network (PRNet), a packet satellite network (SATNET), and the ARPANET<br />
The conception of « open architecture » is a defining concept of the Internet. It provides for the diversity of packet switching networks and for the means for interconnecting them. It provides for the emergence of the Internet.<br />
<br />
A history of the Internet will need to explore Kahn’s conception of « open architecture, » and the work he did with another researcher, Vint Cerf, to create the protocol that would support « open architecture. » Though originally called TCP, this protocol is now known as TCP/IP. It functions as a glue to interconnect diverse packet switching networks as the Internet. Researchers working on an Internet history will need to search out the contributions of computer science reseachers who became part of the International Network Working Group (INWG) and who collaborated to share their networking discoveries. Among the distinguished group of researchers were Louis Pouzin and Hubert Zimmerman who were working to create the Cyclades network in France. Like Kahn, Pouzin recognized the need to give thought to how to interconnect the diversity of packet switching networks.[[ Sur le concept de Louis Pouzin appellé CATENET, voir Pouzin, Louis. (1974, May), « A Proposal for Interconnecting Packet Switching Networks ». Proceedings de l’ EUROCOMP, Brunel University. 1023-36. Pouzin believed that it was necessary to determine how to make such connections possible early on, as these would become more difficult in a later phase of networking development.<br />
<br />
It will also be important to explore the role played by the three teams that created the earliest TCP/IP implementations. These were the teams headed by Ray Tomlinson at BBN, by Vint Cerf at Stanford University, and by Peter Kirstein at the University College London (UCL)in Great Britain. The role played by the IPTO in coordinating these and other grassroots efforts may be even harder to understand, but it is none the less of considerable importance. The interplay between leadership from the director or program manager at IPTO and the grassroots researchers is at the crux of understanding and being able to do a history of the Internet. Also researchers will need to search out the earliest versions of the relevant online standards documents known as RFCs and the mailing list discussions about the development of TCP/IP and other protocols related to Internet development.<br />
<br />
Other events to be studied include the le basculement vers TCP/IP sur ARPANET en janvier 1983, ensuite le découpage d’ARPANET en deux réseaux interconnectés différents en Octobre 1983 , en MILNET et ARPANET , qui peut être considéré comme une forme précoce d’Internet. . il faut aussi relever le rôle important joué par des chercheurs à l’étranger pas seulement à l’university Coillege de Londres, mais aussi en Norvége et ailleurs . Parmi les contributions significatives il faut relever l’implémentation de TCP/IP pour le systéme de distribution d’UNIX de Berkeley ( BSD) qui contribua à la diffusion de TCP/IP, le développement et le succés , sur les bases de l’IPTO du projet radio-paquets ( PRNet) réalisé à l’extérieur de l’IPTO et du programme satellite par paquets crée pour SATNET. Il serait également utile d’éxaminer les discussions entre chercheurs à propos des difficultés qu’ils ont rencontrées dans la réalisation de leurs objectifs comme cela a été documenté par exemple dans le TCP/IP digest animé MikeMuuss pour préparer le basculement vers TCP/IP en Janvier 1983 for the January 1983 cutover to TCP/IP on the ARPANET in January 1983. Then the splitting the ARPANET into two different interconnected networks in October 1983, into MILNET and the ARPANET, created an early form of an Internet. Also important is the role played by researchers abroad, not only at the University College London, but also in Norway and elsewhere. Among other significant contributions are the creation of an implementation of TCP/IP for the Berkeley System Distribution (BSD) of Unix that spread TCP/IP, the development and challenges of the ground IPTO packet radio project (PRNet) conducted out of the IPT office, and of the packet satellite program created for SATNET. And it will be helpful to examine the disputes among the reseachers over the difficulties they had to overcome to carry out their objectives as documented for example in the TCP/IP digest moderated by MikeMuuss to prepare for the January 1983 cutover to TCP/IP.La question significative à laquelle que les chercheurs travaillant à une histoire d’internet doivent se confronter est la compréhension de comment il a été possible d ‘obtenir le leadrship scientifique nécessaire au développement d’Internet. Le pouvoir se bat contre qui veit contrôler l’essentiel des fonctions d’Internet et contre les formes institutionnelles appropriées à ces fonctions montre qu’il sagit une tâche importante pour les gouvernements qui veulent assurer un développement continu d’Internet. La maniére de déterminer ce rôle et d’arriver au shéma institutionnel est une question cruciale pour le développement d’Internet. En apprenant à partir de l’expérience de L’IPTO durant son existence de 1962 à 1986, les gouvernements y compris le gouvernement de s Etats -Unis doivent être en capacité de dire comment concevoir les institutions nécessaires appropriées à leurs conditions nationales. L’expérience de l’INRIA ( Institut national de De Recherce Informatique ert Automatique) où le travail sur CYCLADES fût effectué, peut fournir une utile source comparative .Les institutions gouvernementales qui ont rendu possible une activité coopérative entre scientifiques de divers pays pour batir Internet ont besoin de modèles pour rendre possible la cooprération dans le développement continué d’internet La recherche portant sur, comment cela a été possible dans le passé , créera les formes institutionnelles appropriées aux nouvelles exigences du futur. La recherche historique sur les origines du développement d’Internet est un pré requis pour trouver les principes et les formes institutionnelles nécessaires pour orienter les futurs développements d’Internet<br />
<br />
The significant question that researchers of the history of the Internet most need to grapple with, however, is an understanding of how it was possible to provide scientific leadership for the development of the Internet. The power struggle over who will control the essential functions of the Internet and over the institutional form that is appropriate for such functions show that there is an important task for governments in the continuing development of the Internet. How to determine this role and to provide the institutional form for it is a crucial outstanding question in the development of the Internet. Learning from the experience of the IPTO during its existence from 1962-1986, governments, including the U.S. government will be able to consider how to design the needed institutions appropriate to their national conditions. The experience in France with IRIA (Institut de Recherche d’Informatique et d’Automatique, a government sponsored research laboratory reporting to the Ministry of Industry) where work on CYCLADES was done, can provide a helpful comparative source for study. The government institutions which made it possible to support cooperative activity among scientists from diverse nations in the building of the Internet are needed models to make possible the international cooperation for continued Internet development. Research into how this has been done in the past will make it possible to create the appropriate institutional forms to provide for the new demands for the future. Research into the history of the origin and development of the Internet is a prerequisite to finding the principles and institutional forms needed to guide the development of the Internet for the future.</div>Sysophttp://iuwg.net/index.php/For_Discussion:WhatWG_FAQFor Discussion:WhatWG FAQ2015-03-02T20:44:30Z<p>Sysop: Created page with "== The WHATWG == === What is the WHATWG? === The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web...."</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [https://whatwg.org/mailing-list mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Harassment ===<br />
<br />
The WHATWG has no tolerance for any kind of harassment or abuse. All participants are expected to behave professionally and respectfully at all times. Please immediately report any bad behaviour by anyone on the WHATWG mailing lists, specs, IRC, wiki, or other fora, whether towards you or towards anyone else, including people not actively participating in the WHATWG community, to Ian Hickson, email ian@hixie.ch, or someone else from the community you feel you can trust.<br />
<br />
If you're not sure what consists harassment, the following codes of conduct from other communities are a good guide:<br />
<br />
* http://www.rust-lang.org/conduct<br />
* http://www.w3.org/Consortium/cepc/<br />
* http://www.centerforinquiry.net/pages/policy_on_harassment_at_conferences<br />
<br />
If you're still not sure, refrain from whatever behaviour you're not sure about.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send email to [https://whatwg.org/mailing-list#specs the mailing list] or [https://whatwg.org/newbug file bugs].<br />
<br />
Each specification has a separate editor, who is responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no e-mails at all. Discussions on that list are summarised and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [https://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [https://whatwg.org/specs/ relevant spec]; for HTML, that's ian@hixie.ch. All feedback on the HTML spec will receive a reply in due course.<br />
<br />
'''If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know''' by either emailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (Hixie on Freenode for HTML). Requests for priority feedback handling are handled confidentially so other implementers won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===<br />
<br />
There are several processes by which we trim weeds from the specifications.<br />
<br />
* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.<br />
<br />
* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<br />
<br />
* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.<br />
<br />
Removing features is a critical part of spec development.<br />
<br />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===<br />
<br />
The process is rather informal, but basically boils down to this:<br />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html<br />
# Get more people involved. Send your use cases and their requirements to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, again to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec. Likely your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<br />
<br />
If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.<br />
<br />
Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<br />
<br />
=== What does "Living Standard" mean? ===<br />
<br />
The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.<br />
<br />
Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.<br />
<br />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before, yet are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<br />
<br />
Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.)<br />
<br />
=== Will future browsers have any idea what older HTML documents mean? ===<br />
<br />
Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.<br />
<br />
One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.<br />
<br />
=== How are developers to determine when certain parts of their pages will become invalid? ===<br />
<br />
It shouldn't matter if and when old pages become invalid.<br />
<br />
Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of the specification.<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: [https://twitter.com/WHATWG @WHATWG] (non-editorial changes only)<br />
<br />
* You may use the online [https://html5.org/tools/web-apps-tracker HTML Standard Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a [https://whatwg.org/mailing-list#commits commit-watchers mailing list] that is notified of every edit.<br />
<br />
* The specification is available in the [https://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<br />
<br />
=== When will we be able to start using these new features? ===<br />
<br />
You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:<br />
<br />
* http://diveintohtml5.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.org/<br />
<br />
If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".<br />
<br />
Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. &lt;canvas&gt;). But other sections are still being actively worked on and changed regularly, or not even written yet.<br />
<br />
'''You can see annotations in the margins showing the estimated stability of each section.'''<br />
<br />
The possible states are:<br />
<br />
* ''Idea; yet to be specified'' -- the section is a placeholder.<br />
* ''First draft'' -- An early stage.<br />
* ''Working draft'' -- An early stage, but more mature than just "first draft".<br />
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.<br />
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.<br />
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it&#8217;s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.<br />
<br />
There are also two special states:<br />
<br />
* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback. (This state is not used often.)<br />
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.<br />
<br />
The point to all this is that you shouldn&#8217;t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.<br />
<br />
=== What's this I hear about 2022? ===<br />
<br />
Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than the WHATWG is aiming for. We now look for two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you&#8217;ll begin to understand why the time frame seems so long.<br />
<br />
Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.<br />
<br />
=== What about Microsoft and Internet Explorer? === <br />
<br />
Microsoft started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.<br />
<br />
=== Is design rationale documented? ===<br />
<br />
Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.<br />
<br />
For a few cases that someone did take the time document, the information can be found at the following locations:<br />
<br />
* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend]] or another ''mini-header'' element.<br />
<br />
Also see ''HTML feature proposals'' below.<br />
<br />
== HTML syntax issues ==<br />
<br />
=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? === <br />
<br />
Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''<br />
<br />
=== What is the DOCTYPE for modern HTML documents? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [https://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these emails:<br />
* http://lists.w3.org/Archives/Public/public-html/2009Mar/0491.html<br />
* http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0071.html<br />
At this stage, as discussed in the second of those emails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, Hixie, the editor, reads the feedback sent to both groups and takes all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, Hixie does not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]<br />
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<br />
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.<br />
<br />
=== Should I top-post or reply inline? ===<br />
<br />
'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous emails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your email makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Sysophttp://iuwg.net/index.php/For_Discussion:WhatWG_charterFor Discussion:WhatWG charter2015-03-02T20:36:12Z<p>Sysop: Created page with "Web Hypertext Application Technology Working Group Charter ;Note: This document was written in 2004 and no longer represents anything like how the WHATWG operates. For a more..."</p>
<hr />
<div>Web Hypertext Application Technology Working Group Charter<br />
<br />
;Note: This document was written in 2004 and no longer represents anything like how the WHATWG operates. For a more up to date discussion on how the WHATWG functions today, the FAQ does a better job. The original charter is included below to provide historical context.<br />
<br />
==Introduction==<br />
<br />
Software developers are increasingly using the Web to deploy their applications. User Agents serve as front ends for server-based applications, and W3C technologies — including HTML, CSS and DOM — are often used to build user interfaces to these applications. Along with ECMAScript, these technologies provide a foundation for Web applications.<br />
<br />
However, the aforementioned technologies were not developed with Web applications in mind, and Web applications often rely on unintended features not fully described by the specifications. The next generation of Web applications will add new requirements to the development environment — requirements these technologies are not prepared to fulfill alone. New technologies being developed by the W3C and IETF can contribute to Web applications, but these are often designed to address other needs and only consider Web Applications in a peripheral way.<br />
<br />
== Deliverables ==<br />
<br />
The goal of the Web Hypertext Applications Technology Working Group is to address the need for one coherent development environment for Web applications, through the creation of technical specifications that are intended to be implemented in mass-market Web browsers.<br />
<br />
The expected deliverables include:<br />
<br />
* Web Forms 2.0: An incremental improvement of HTML4.01's forms.<br />
* Web Applications 1.0: Features for Application Development in HTML.<br />
<br />
* Web Controls 1.0: A specification describing mechanisms for creating new widgets that can be used with the Web Forms and Web Applications technologies.<br />
* CSS Rendering Object Model: A specification for defining access to the CSS rendering tree so that applications can access, e.g., the active selection, and rendered ::before and ::after content.<br />
<br />
Other deliverables may be found to be needed to cover other areas that Web application developers require. For instance we may work on specifications for new semantic elements that cover common scenarios such as those found in e-commerce, forums, Web logs, and games. The list of deliverables above is not meant to be exclusive.<br />
<br />
All specifications produced by this working group must take into account backwards compatibility, and clearly specify reasonable transition strategies for authors. They must also specify error handling behaviour to ensure interoperability even in the face of documents that do not comply with the letter of the specification.<br />
<br />
==Process ==<br />
Working group contributors will contribute to this activity through a publicly-archived and open-subscription mailing list. The working group members should also respond to queries from the public on this mailing list.<br />
<br />
Each document shall have an assigned editor. Editors should reflect the consensus opinion of the working group when writing their specifications, but it is the document editor's responsibility to break deadlocks when the working group cannot come to an agreement on an issue.<br />
<br />
Specifications will be developed in public, with the latest version always publically available. During development, the working group may decide that a document has reached a stable stage and is in need of wider review. At this point the document will be archived in its current state, and a call-for-comments will be announced. Drafts in this stage should bear a warning informing readers that the specification is not considered ready for non-experimental implementations, and that experimental implementations of the draft must not be included in end-user products.<br />
<br />
The working group can make a decision to publish a stable version of a document only if the overwhelming majority of the working group members agree that the document is ready.<br />
<br />
When a draft has been subjected to a call-for-comments in which no new and useful comments have been received, the working group may decide that the specification is ready to be implemented in Web browsers (both for desktop and low-end devices) and shipped to end users. At this stage, the document will be archived, and a call-for-implementations will be announced.<br />
<br />
In order for a draft to proceed past the call-for-implementations stage to the recommendation stage, there must be at least two interoperable implementations for every feature. For the purposes of this criterion, we define the following terms:<br />
<br />
;feature: A section or subsection of the specification.<br />
;interoperable : passing the respective test cases in the test suite.<br />
;implementation : a user agent which:<br />
<br />
:# implements the feature.<br />
:# is available (i.e. publicly downloadable or available through some other public point of sale mechanism). This is the "show me" requirement.<br />
:# is shipping (i.e. development, private or unofficial versions are insufficient).<br />
:# is not experimental (i.e. is intended for a wide audience and could be used on a daily basis).<br />
<br />
If implementation feedback warrants it, or if implementations are not found to be sufficiently interoperable, specifications in the call-for-implementations stage will be returned to the draft stage to address the issues raised and reasons for implementation differences.<br />
Membership<br />
<br />
Anyone can contribute by subscribing to the mailing list. The list of subscribers to the mailing list are termed the contributors.<br />
<br />
Membership is by invitation only, and consists of a number of representatives from various browser manufacturers. This group, which is referred to as the members, will provide overall guidance as described in the charter above. The members currently consists of:<br />
<br />
: Anne van Kesteren<br />
: Brendan Eich<br />
: David Baron<br />
: David Hyatt<br />
: Dean Edwards<br />
: Håkon Wium Lie<br />
: Ian Hickson<br />
: Johnny Stenback<br />
: Maciej Stachowiak</div>Sysophttp://iuwg.net/index.php/DigisphereDigisphere2015-02-04T00:02:08Z<p>Sysop: Created page with "To understand digisphere related texts. ;A4A : Airlines for America ;AAC : Aeronautical Administrative Communications ;AAIB : Air Accidents Investigation Branch ;AAP :..."</p>
<hr />
<div>To understand digisphere related texts.<br />
<br />
;A4A : Airlines for America<br />
;AAC : Aeronautical Administrative Communications<br />
;AAIB : Air Accidents Investigation Branch<br />
;AAP : Allied Administrative Publication<br />
;ACAS : Aeronautical Collision Avoidance System<br />
;ACHR : American Convention on Human Rights<br />
;ACL : Access Control List<br />
;ADS-B : Automatic Dependent Surveillance – Broadcast<br />
;AEEC : Airlines Electronic Engineering Committee<br />
;AES : Advanced Encryption Standard<br />
;AFDX : Avionics Full Duplex Switched Ethernet<br />
;AfriNIC : African Network Information Centre<br />
;AFTN : Aeronautical Fixed Telecommunication Network<br />
;AIS : Automatic Identification Systems<br />
;AJIL : American Journal of International Law<br />
;AJP : Allied Joint Publication<br />
;Am. J. Int’l L. : American Journal of International Law<br />
;Am.U. Int’l L.Rev. : American University International Law Review AOC : Aeronautical Operational Control<br />
;APC : Aeronautical Passenger Communication<br />
;APCN : Asian Pacific Cable Network<br />
;APNIC : Asia-Pacific Network Information Centre<br />
;app : approximately<br />
;APT : Advanced Persistent Threat<br />
;ARF : ASEAN Regional Forum<br />
;ARIN : American Registry for Internet Numbers<br />
;ARIO : (draft) Articles on the Responsibility of International Organizations<br />
;ARPANET : Advanced Research Projects Agency Network AS : autonomous system<br />
;ASEAN : Association of Southeast Asian Nations<br />
;ASI : Agenzia Spaziale Italiana (Italian Space Agency)<br />
;ASIC : Application-Specific Integrated Circuit<br />
;ASLR : Address Space Layout Randomisation<br />
;ASR : Articles on State Responsibility (‘Draft Articles on Responsibility of States for Internationally Wrongful Acts’)<br />
;ATM : Air Traffic Management<br />
;ATS : Air Traffic Service<br />
;AU : African Union<br />
;BIOS : Basic Input Output System<br />
;BIT : Bilateral Investment Treaty<br />
;BNSC : British National Space Council<br />
;BRICS : Brazil, Russia, India, China, South Africa Brook. J. Int’l L : Brooklyn Journal of International Law<br />
;BSI : Bundesamt für Sicherheit in der Informationstechnik (Federal Office for<br />
;Information Security, Germany) BYIL : British Yearbook of International Law<br />
;C&C : command and control<br />
;C4ISR : command, control, communications, computers, intelligence, surveillance, and reconnaissance.<br />
;CA : Certification Authority<br />
;ca : circa, approximately<br />
;CAPTCHA : Completely Automated Public Turing test to tell Computers and Humans Apart<br />
;CBMs : confidence building measures<br />
;CEN : Comité Européen de Normalisation (European Committee for<br />
;Standardization)<br />
;CEPC : Civil Emergency Planning Committee<br />
;CEP RRT : Civil Emergency Planning Rapid Reaction Team<br />
;CERN : Conseil Européen pour la Recherche Nucléaire (European Organization for Nuclear Research)<br />
;CERT : Computer Emergency Response Team<br />
;CETS : Council of Europe Treaty Series<br />
;cf. : confer, compare<br />
;CFE Treaty : Treaty on Conventional Armed Forces in Europe<br />
;CIA : confidentiality, integrity and availability / Central Intelligence Agency<br />
;CICIR : China Institute of Contemporary International Relations<br />
;CKC : Cyber Kill Chain<br />
;CMX : Crisis Management Exercise<br />
;CNE : Computer Network Exploitation<br />
;CNES : Centre National d’Etudes Spatiales (National Space Studies Centre, France)<br />
;CNO : Computer Network Operation<br />
;CNS : communication, navigation and surveillance<br />
;CoE : Council of Europe<br />
;Colum. J. Transnat’l L. : Columbia Journal of Transnational Law COMPASS : Comprehensive Approach Specialist Support<br />
;COPUOS : Committee on the Peaceful Uses of Outer Space<br />
;COTS : commercial off-the-shelf<br />
;CPNI : Centre for the Protection of National Infrastructure<br />
;CRSIO : Convention on Relations of States with International Organizations<br />
;(‘Vienna Convention on the Representation of States in their Relations with International Organizations of a Universal Character’)<br />
;CSIRT : Computer Security Incident Response Team<br />
;CSIS : Center for Strategic and International Studies<br />
;CSM : Convention on Special Missions<br />
;CSNET : Computer Science Network<br />
;CSR : corporate social responsibility<br />
;CSTO : Collective Security Treaty Organization<br />
;CVE : common vulnerabilities and exposures<br />
;DARIO : Draft Articles on the Responsibility of International Organizations<br />
;DDoS : distributed denial of service (attack)<br />
;DES : Data Encryption Standard<br />
;DHCP : Dynamic Host Configuration Protocol<br />
;DISA : Defense Information Systems Agency<br />
;DLR : Deutsches Zentrum für Luft- und Raumfahrt (German Space Agency)<br />
;DME : distance measuring equipment<br />
;DMZ : demilitarised zone<br />
;DNS : Domain Name System<br />
;DNSSEC : Domain Name System Security Extensions<br />
;Doc. / doc. : document<br />
;DoD : Department of Defense<br />
;DPI : deep packet inspection<br />
;DSB : Dispute Settlement Body (WTO)<br />
;DSWG : Digital Security Working Group<br />
;EASA : European Aviation Safety Agency<br />
;EC : European Community<br />
;ECHR : European Court of Human Rights / European Convention on Human Rights<br />
;ed. : editor / edition<br />
;ed. gen. : editor general<br />
;EDA : European Defence Agency<br />
;edn. : edition<br />
;EEZ : Exclusive Economic Zone<br />
;eg / e.g. : exempli gratia, for example<br />
;EIF : Estonian Internet Foundation<br />
;EJIL : European Journal of International Law<br />
;ENISA : European Network and Information Security Agency<br />
;ESA : European Space Agency<br />
;et al. : et alii, and others / et alia, and other things<br />
;etc : et cetera, and so forth / and other(s)<br />
;et seq. / et seqq. : : et sequens / et sequentes / et sequentia, and the following ETS : European Treaty Series<br />
;ETSI : European Telecommunications Standards Institute<br />
;EU : European Union<br />
;Eur. J. Int’l L. : European Journal of International Law EW : Electronic Warfare<br />
;EWCA : England and Wales Court of Appeal (Civil Division) Decisions<br />
;f. / ff. : foliis, and following<br />
;FAA : Federal Aviation Administration<br />
;FAO : Food and Agriculture Organization<br />
;FAZ : Frankfurter Allgemeine Zeitung (Frankfurt General Newspaper, Germany)<br />
;FBI : Federal Bureau of Investigation<br />
;FCC : Federal Communications Commission<br />
;FIRST : Forum of Incident Response and Security Teams FLTSATCOM : Fleet Satellite Communications System<br />
;FMS : Flight Management System<br />
;FTP : File Transfer Protocol<br />
;FYROM : Former Yugoslav Republic of Macedonia<br />
;G8 : Group of Eight<br />
;G20 : Group of Twenty<br />
;GAC : Government Advisory Committee<br />
;GAO : Government Accountability Office<br />
;GATS : General Agreement on Trade in Services<br />
;GATT : General Agreement on Tariffs and Trade<br />
;GBP : Great Britain Pound<br />
;GCHQ : Government Communications Headquarters<br />
;GDP : gross domestic product<br />
;GEO : geostationary orbit<br />
;GGE : Governmental Group of Experts<br />
;GPA : Agreement on Government Procurement<br />
;GPS : Global Positioning System<br />
;Harv. Int’l L.J. : Harvard International Law Journal HBO : Home Box Office<br />
;HEAT : high-explosive anti-tank (missile)<br />
;HIDS : host-based intrusion detection systems<br />
;HTTP : Hypertext Transfer Protocol<br />
;HTTPS : Hypertext Transfer Protocol Secure<br />
;HVDC : high voltage direct current<br />
;IAA : International Academy of Astronautics<br />
;IADC : Inter-Agency Space Debris Coordination Committee<br />
;IANA : Internet Assigned Numbers Authority<br />
;ibid. / id. : ibidem, in the same place<br />
;ICANN : Internet Corporation for Assigned Names and Numbers<br />
;ICAO : International Civil Aviation Organization<br />
;ICCPR : International Covenant on Civil and Political Rights<br />
;ICJ : International Court of Justice<br />
;ICMP : Internet Control Message Protocol<br />
;ICPC : International Cable Protection Committee<br />
;ICLQ : International and Comparative Law Quarterly<br />
;ICTs : information and communication technologies<br />
;ICTY : International Criminal Tribunal for the former Yugoslavia<br />
;ID : identification / identity<br />
;IDS : intrusion detection system<br />
;ie / i.e. : id est, that is<br />
;IEEE : Institute of Electrical and Electronics Engineers<br />
;IETF : Internet Engineering Task Force<br />
;IFOR : Implementation Force<br />
;IG : internet governance<br />
;IGF : Internet Governance Forum<br />
;IHL : international humanitarian law<br />
;IHLR : international human rights law<br />
;ILC : International Law Commission<br />
;ILM / I.L.M. : International Legal Materials<br />
;ILR : International Law Review<br />
;ILS : Instrument Landing System<br />
;IMF : International Monetary Fund<br />
;IMO : International Maritime Organization<br />
;IMPACT : International Multilateral Partnership Against Cyber Threats Int’l J. L. & Info. Tech. : International Journal of Law and Information Technology Int’l L. Comm’n YB : Yearbook of the International Law Commission<br />
;Int’l L. Stud. : International Law Studies IP : Internet Protocol<br />
;IPS : intrusion prevention system<br />
;IPsec : Internet Protocol security<br />
;IPv4 : Internet Protocol version 4<br />
;IPv6 : Internet Protocol version 6<br />
;IPX : Internetwork Packet Exchange<br />
;ISAF : International Security Assistance Force<br />
;ISATAP : Intra-Site Automatic Tunnel Addressing Protocol<br />
;ISKE : Intelligent Systems and Knowledge Engineering<br />
;ISMS : Information Security Management System<br />
;ISO/IEC : International Organization for Standardization/ International Electrotechnical Commission<br />
;ISP : internet service provider<br />
;ISR : intelligence, surveillance and reconnaissance<br />
;Isr. L. R : Israel Law Review<br />
;IsrSC : Israel Supreme Court<br />
;ISTAR : intelligence, surveillance, target acquisition and reconnaissance<br />
;IT : information technology<br />
;ITLOS : International Tribunal for the Law of the Sea<br />
;ITRs : International Telecommunication Regulations<br />
;ITU : International Telecommunication Union<br />
;ITU-D : ITU Telecommunication Development Sector<br />
;ITU-R : ITU Radiocommunication Sector<br />
;ITU-T : ITU Telecommunication Standardization Sector<br />
;IWG : informal working group<br />
;IXP : internet exchange point<br />
;J. Air L. & Com. : Journal of Air Law and Commerce<br />
;J. E. Asia & Int’l L. : Journal of East Asia and International Law<br />
;KFOR : Kosovo Force<br />
;KGB : Komitet Gosudarstvennoy Bezopasnosti (Committee for State Security, former Soviet Union)<br />
;KSAT : Kongsberg Satellite Services<br />
;KSOR : Kollektivnye Sily Operativnogo Reagirovania (Collective Rapid Reaction Forces)<br />
;LACNIC : Latin American and Caribbean Internet Addresses Registry<br />
;LAN : Local Area Network<br />
;lit. : litera, letter<br />
;LNTS / L.N.T.S. : League of Nations Treaty Series LOAC : law of armed conflict<br />
;LOSC : United Nations Convention on the Law of the Sea<br />
;M/V : motor vessel<br />
;MAC : Media Access Control (address)<br />
;MAWA : Military Airworthiness Authorities<br />
;MFA : Ministry of Foreign Affairs<br />
;MFN : most favoured nation<br />
;milCyberCAP : military cyber capabilities MITM : man-in-the-middle (attack)<br />
;MIST : Mexico, Indonesia, South-Korea, Turkey<br />
;MIT : Massachusetts Institute of Technology<br />
;MN : marginal note<br />
;MOD : Ministry of Defence<br />
;MPEPIL : The Max Planck Encyclopedia of Public International Law<br />
;n. : note / footnote<br />
;N.Y. Times : The New York Times<br />
;NAC : North Atlantic Council<br />
;NASA : National Aeronautics and Space Administration<br />
;NAT : Network Address Translation<br />
;NATO CCD COE : NATO Cooperative Cyber Defence Centre of Excellence NATO : North Atlantic Treaty Organization<br />
;NDB : Non-Directional Beacon<br />
;NetBIOS : Network Basic Input Output System<br />
;NGO : non-governmental organisation<br />
;NIDS : network-based intrusion detection systems<br />
;NIST : National Institute of Standards and Technology<br />
;nm. : nautical mile(s)<br />
;NNCEIP : Non-Nuclear Critical Energy Infrastructure Protection<br />
;no. : number<br />
;NPS : nuclear power sources<br />
;NSA : National Security Agency<br />
;NSAU : National Space Agency of Ukraine<br />
;NSF : National Science Foundation<br />
;NSFNET : National Science Foundation Network<br />
;NSO : nuclear safe orbits<br />
;NSTAC : National Security Telecommunications Advisory Committee<br />
;NWP 1-14M : U.S. Navy / U.S. Marine Corps / U.S. Coast Guard, The Commander’s<br />
;Handbook on the Law of Naval Operations (July 2007)<br />
;OAS : Organization of American States<br />
;OECD : Organisation for Economic Co-operation and Development<br />
;op. cit. : opere citato, in the work cited<br />
;OSCE : Organization for Security and Co-operation in Europe<br />
;OSI : open system interconnection<br />
;OSINT : open source intelligence<br />
;p. / pp. : page(s)<br />
;Pace Int’l L.R. : Pace International Law Review para. : paragraph<br />
;PC : personal computer<br />
;PCIJ : Permanent Court of International Justice<br />
;PED : passenger electronic device<br />
;Penn. St. JL & Int’l Aff. : Penn State Journal of Law and International Affairs PHP : Hypertext Preprocessor<br />
;PING : Packet InterNet Grouper<br />
;POC : point of contact<br />
;PPM : product and production method distinction<br />
;r. / rr. . : rule / rules<br />
;R&D : research and development<br />
;RAM : Random Access Memory<br />
;RAT : Remote Access Tool<br />
;RBN : Russian Business Network<br />
;RD : Router Discovery<br />
;reg. : registration<br />
;Res. / RES : resolution(s)<br />
;rev. : revised<br />
;RFC : request for comment<br />
;RFDA : Revue française de droit administratif (French Administrative Law Review) RIAA / R.I.A.A. : Reports of International Arbitral Awards<br />
;RIIKS : Riigi Infokommunikatsiooni Sihtasutus (Estonian State Info-Communication Foundation)<br />
;RIPE NCC : The Réseaux IP Européens Network Coordination Centre<br />
;RIR : Regional Internet Registry<br />
;ROA : Remotely Operated Aircraft<br />
;ROP : Return-Oriented Programming<br />
;ROV : Remotely Operated Vehicle<br />
;RPAS : Remotely Piloted Aircraft System<br />
;RPV : Remotely Piloted Vehicle<br />
;RRs : Radio Regulations<br />
;RRT : Rapid Reaction Team<br />
;SACEUR : Supreme Allied Commander Europe San Diego Int’l L.J : San Diego International Law Journal SARPS : Standards and Recommended Practices<br />
;SCO : Shanghai Cooperation Organisation<br />
;S. Ct. : Supreme Court<br />
;SDF : Self-Defence Forces<br />
;SDLC : Software Development Life Cycle<br />
;SDR : Special Drawing Rights<br />
;sec. : section<br />
;SEI : Software Engineering Institute<br />
;ser. : series<br />
;SESAR : Single European Sky Air Traffic Management Research<br />
;SMS : Short Message Service<br />
;SOFA : Status of Forces Agreement<br />
;SQL : Structured Query Language<br />
;S-SDLC : Secure Software Development Life Cycle<br />
;SSH : Secure Shell<br />
;SSL : Secure Sockets Layer<br />
;SSR : Secondary Surveillance Radar<br />
;STANAG : Standardization Agreement<br />
;SUA Convention : Convention for the Suppression of Unlawful Acts against the Safety of<br />
;Maritime Navigation Suppl : Supplement<br />
;SWIFT : Society for Worldwide Interbank Financial Telecommunication Syracuse L. Rev. : Syracuse Law Review<br />
;Tails : The Amnesic Incognito Live System<br />
;TBT : Agreement on Technical Barriers to Trade<br />
;TCAS : Traffic Alert and Collision Avoidance System<br />
;TCP : Transmission Control Protocol<br />
;TERENA : Trans-European Research and Education Networking Association<br />
;TLDs : Top Level Domains<br />
;TLS : Transport Layer Security<br />
;Tor : The Onion Router (initially an abbreviation; term of art)<br />
;TRIPS : Agreement on Trade-Related Aspects of Intellectual Property Rights<br />
;TTL : Time To Live<br />
;Tulane Maritime L.J. : Tulane Maritime Law Journal TVH : Thailand-Vietnam-Hong Kong<br />
;UAS : Unmanned Aircraft System<br />
;UAV : Unmanned Aerial Vehicle<br />
;UCS : UAV Control System<br />
;UDHR : Universal Declaration of Human Rights<br />
;UDP : User Datagram Protocol<br />
;UHF : ultra high frequency<br />
;UK : United Kingdom<br />
;UKHL : United Kingdom House of Lords<br />
;UN : United Nations<br />
;U.N.B. Law Journal : University of New Brunswick Law Journal UN Charter : Charter of the United Nations<br />
;UN GA / UNGA : United Nations General Assembly<br />
;UN GGE : United Nations Group of Governmental Experts UN SC / UNSC : United Nations Security Council<br />
;UNCLOS : United Nations Convention on the Law of the Sea<br />
;UNDOALOS : United Nations Division for Ocean Affairs and the Law of the Sea<br />
;UNEP-WCMC : United Nations Environment Programme – World Conservation Monitoring Centre<br />
;UNIDIR : United Nations Institute for Disarmament Research<br />
;UNMIK : United Nations Interim Administration Mission in Kosovo<br />
;UNODA : United Nations Office for Disarmament Affairs<br />
;UNODC : United Nations Office on Drugs and Crime<br />
;UNTS / U.N.T.S. : United Nations Treaty Series URL : Uniform Resource Locator<br />
;US / U.S. : United States of America<br />
;USAID : United States Agency for International Development<br />
;USB : Universal Serial Bus<br />
;U.S.C. : United States Code<br />
;USCYBERCOM : United States Cyber Command USD : United States Dollar<br />
;U.S. Dept. of State Bulletin : United States Department of State Bulletin USS : United States Ship<br />
;U.S.T. : United States Treaties and Other International Agreements Utah L. Rev. : Utah Law Review<br />
;UUVs : Unmanned Undersea Vehicles<br />
;v. / vs. : versus, against<br />
;Va. J. Int’l L : Virginia Journal of International Law<br />
;VCCR : Vienna Convention on Consular Relations<br />
;VCDR : Vienna Convention on Diplomatic Relations<br />
;VCLT : Vienna Convention on the Law of Treaties<br />
;Vill. L. Rev. : Villanova Law Review<br />
;VMS : vessel monitoring system<br />
;VoIP : voice over Internet Protocol<br />
;vol. : volume<br />
;VOR : very high frequency omni-directional range<br />
;VPN : Virtual Private Network<br />
;Wall St. J : The Wall Street Journal<br />
;WAN : Wide Area Network<br />
;Wash. Post : Washington Post<br />
;WCIT : World Conference on International Telecommunications<br />
;WHO : World Health Organization<br />
;WiFi : Wireless Fidelity<br />
;WLAN : Wireless Local Area Network<br />
;WRC : World Radiocommunication Conference<br />
;WSIS : World Summit of the Information Society<br />
;WTO : World Trade Organization<br />
;WWI : World War I<br />
;WWII : World War II<br />
;WWW / www : World Wide Web<br />
;YBILC : Yearbook of the International Law Commission<br />
;ZLW : Zeitschrift für Luft- und Weltraumrecht (Air and Space Law Journal, Germany)</div>Sysophttp://iuwg.net/index.php/20150119_-_John_Klensin20150119 - John Klensin2015-01-19T19:38:25Z<p>Sysop: </p>
<hr />
<div>''So while it is fair to say that the issues require more work, On a lighter note, it's interesting that to note that IETF who will mostly be affected by those issues raised had to wait to be prompted by other communities.''<br />
<br />
<br />
Actually, that is exactly where the issue lies. At the risk of<br />
oversimplifying both positions (and temporarily putting the<br />
process issues aside), I heard both:<br />
<br />
*arguments that these were very significant issues for the IETF and that the IETF would be most affected by them.<br />
<br />
* arguments that these issues were actually of little importance to the IETF and that, while moving the domain name and/or trademark away from ICANN and to a presumably-neutral party would be fine with the IETF, it was not of any great importance.<br />
<br />
Since Richard's note and some other comments repeat (or<br />
summarize) the first argument, let me briefly summarize the two<br />
most important elements of the second set:<br />
<br />
<br />
:(1) In part because the number of separate, and separately-referenced, registries in the Protocol Parameter area vastly exceeds the number in either the Numbers or names area, the IETF would have a considerable conversion problem if eitherthe IANA function were broken into multiple pieces or if it was somehow transferred away from ICANN under circumstances that resulted in an ICANN decision to not be active in, and positive about, facilitating that transition. The requirements of that conversion would be such that whether or not the names were available (and hence whether the IETF needed to invent completely new names) would be trivial as compared to everything else that would need to be done.<br />
<br />
<br />
:(2) Because of the jurisdictional issues involved, open questions about ICANN's long-term locale and accountability issues, etc., some of us are very skeptical about whether what Richard characterizes as a "legally binding agreement" is meaningful or operationally relevant. If there is general agreement about what should be done and a spirit of cooperation, then "legally binding" is unnecessary. If there is not and one has to somehow enforce such an agreement because one party is perceived as having become non-responsive or uncooperative by the other(s), then the one thing that is nearly certain is it would take a relatively long time to get to a final conclusion. At least for planning purposes, the IETF would need to assume that would be long enough that it would be necessary to put an independent transition plan into effect -- a transition plan that would raise the issues in (1) above -- in order to preserve the stability, accessibility, and utility of the protocol parameter registries.<br />
<br />
<br />
Returning to the process question, it seems to me that Richard<br />
(and some others) simply failed to convince the WG that the<br />
first position was of critical importance or that the arguments<br />
for it dominated those for the second. The other important<br />
element of his argument seems to be that members of the "IETF<br />
Leadership" had opinions and expressed them. For better or<br />
worse, an important component of the IETF's leadership selection<br />
regime is expertise and opinions -- we aren't supposed to be<br />
appointing professional process arbiters who don't have, or are<br />
expected to suspend, their experience and professional judgment.<br />
When we end up with leaders whose concerns are more about<br />
process than about substance --including their own judgments--<br />
we usually end up regretting it. If he feels that there was<br />
abuse in the consensus-determining process, that is precisely<br />
why we have an appeals (really an extended internal review)<br />
process of which he has failed to take advantage. Instead, he<br />
has claimed that he could not make such an appeal -- that is not<br />
the case as others have pointed out.<br />
If "I didn't like the outcome" is grounds for claiming to the<br />
ICG that a process concern exists, then consensus as the IETF<br />
understands it would basically be impossible.</div>Sysop