Subject: The IETF Trust License is too restricted

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 Dec 2005 15:16:20 +0100

The text in section 9.5 appear to me to make it permanently impossible
to incorporate portions of RFC in both free or proprietary products.

I believe that is unacceptable, and that it is counter to the needs of
many in the IETF community.

In the IPR WG, I have documented that implementations of IETF
documents distributed by Debian, FreeBSD and Sun need the rights to
incorporate portions of RFCs in their products.

The section reads:

   9.5 Licenses

   The Trust (acting through the Trustees) shall have the right to
   grant licenses for the use of the Trust Assets on such terms,
   subject to Section 7.1, as the Trustees deem appropriate; provided,
   however, that the Trust shall not grant any license that would be
   deemed a transfer of ownership or abandonment of any Trust Assets
   under applicable law.  Specifically, any license granted by the
   Trust for the use of the Trust Assets consisting of IPR shall
   include provisions stating that (a) the licensee agrees to grant
                                       ----------------------------
   and assign to the Trust all right, title, and interest it may have
   ------------------------------------------------------------------
   or claim in any derivative works of Licensee that are based on or
   -----------------------------------------------------------------
   incorporate the IPR, and (b) the licensee’s use of the IPR and any
   -------------------
   goodwill associated therewith shall inure to the benefit of the
   Trust.

I believe the requirement to give up all rights to derivative works of
the IETF IPR would be unacceptable to the Debian and FreeBSD
community.  They are not in a legal position to grant the Trust all
rights to derivative works of the work that include portions of RFCs.

I assume companies like Sun would find it difficult to grant the IETF
Trust all rights to the Solaris operating system, which include
excerpts from RFCs.

If the IETF, in RFC 3978bis, gave third parties the right to use,
modify and distribute RFCs, this would not be a problem.  But RFC 3978
nor the current RFC 3978bis proposal does not grant those rights.  The
only mechanism to be able to grant those rights to the Debian and the
FreeBSD community in the future will be to release those works via the
IETF Trust.  As described above, the IETF Trust cannot grant a
sub-license without the requiring the above.  I believe that
requirement is unacceptable to most members in the IETF community.

To fix this problem, remove the sentences that begin with
"Specifically", thus making the section read:

   The Trust (acting through the Trustees) shall have the right to
   grant licenses for the use of the Trust Assets on such terms,
   subject to Section 7.1, as the Trustees deem appropriate; provided,
   however, that the Trust shall not grant any license that would be
   deemed a transfer of ownership or abandonment of any Trust Assets
   under applicable law.

I believe the issues raised under "Specifically" do not follow from
the first part of the paragraph.  They seriously limits the IETF
Trusts capabilities to grant sub-licenses, and should be removed.

The IETF Trust should be able to grant unrestricted sub-licenses.

Finally, less than 4 weeks of time to review a long complicated legal
document is insufficient.

My lawyer is on vacation until after Christmas.  Lawyers from
organizations such as the Free Software Foundation (FSF) and the
Electronic Frontier Foundation (EFF) cannot be expected to respond
this fast.

This document is given less review time than even some technical
documents.

Given the importance of this work, I believe one year of review would
be more appropriate, if you wanted to guarantee the widest possible
review of relevant and competent people.  It takes time to get useful
output from lawyers.

(The "less than 4 weeks" is based on the first announcement posted on
November 11, and the now extended deadline of December 8th.)

Thanks,
Simon

Brian Carpenter <[email-masked]> writes:

> (posted for Lucy Lynch, IAOC Chair)
>
> All -
>
> The amended language for Section 9.5 (Licensing) of the IETF Trust was
> posted to the IETF lists on December 1st and the IETF Trust FAQ has
> been updated to reflect the new text (see below). We have also added
> additional details on the handling of historical data. As we develop
> procedures for the transfer of assets into the IETF Trust and an
> inventory of items held by the IETF Trust we will publish them to the
> IAOC web site (see: http://koi.uoregon.edu/~iaoc/)
>
> Several people asked for additional time to review our final language,
> and with that in mind, I would like to extend this Call one last
> time to December 8th, 2005.
>
> Please send comments to: [email-masked] or iaoc.ietf.org
>
> - Thanks
>
> Lucy E. Lynch                           Academic User Services
> Computing Center                        University of Oregon
> llynch  @darkwing.uoregon.edu           (541) 346-1774
>
> FAQ Updates:
> -------------------------------------------------------------------------
> 18. How will the license provisions in Section 9.5 affect the contents
> of Standards related documents like RFCs and Internet Drafts.
>
> The IETF IPR rules in force when such documents were published still
> apply and Section 9.5 has been updated to reflect community concerns
> about the effect of licensing terms. The new text reads:
>
> "9.5 Licenses.
>
> The Trust (acting through the Trustees) shall have the right to grant
> licenses for the use of the Trust Assets on such terms, subject to
> Section 7.1, as the Trustees deem appropriate; provided, however, that
> the Trust shall not grant any license that would be deemed a transfer
> of ownership or abandonment of any Trust Assets under applicable law.
> Specifically, any license granted by the Trust for the use of the
> Trust Assets consisting of IPR other than rights in IETF
> standards-related documents (such as RFCs, Internet Drafts and the
> like) that have been acquired by the Trust through non-exclusive
> licenses granted by their contributors pursuant to the IETF
> community-approved procedures currently set forth in RFC 3978, and any
> community-approved updates and revisions thereto, shall include
> provisions stating that (a) the licensee agrees to grant and assign to
> the Trust all right, title, and interest it may have or claim in any
> derivative works of licensee that are based on or incorporate the IPR,
> and (b) the licensee's use of the IPR and any goodwill associated
> therewith shall inure to the benefit of the Trust."
>
> 19. Which of the assets listed in Schedule A will be transferred when
> the IETF Trust is established? Will the Trustees publish an accounting
> of these assets?
>
> All of the Marks, Domain Names, and Current Data listed in Schedule A
> will be transferred at closing. In addition, Historical Data that is
> currently available from available from the servers currently operated
> by or for the IETF Secretariat (i.e. data available on spinning disk)
> will also be transferred at closing. The Trustees will inventory all
> assets and provide a full accounting to the IETF community. Historical
> data which is currently in-accessible will be subject to the
> conditions outlined in sub-sections b-g. When and if additional data
> becomes available, those assets will transfer to the IETF Trust and
> will be added to the inventory.
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Dec 2005 15:50:22 +0100

Simon,

You are bit behind real time. We already updated this text.

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 Dec 2005 15:57:57 +0100

> http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html

Thanks!  This was also pointed out in private e-mail.

The new text do solve my concern.  I do think it is somewhat
confusing, though.  The second half starts with "Specifically," but
the qualifications and restrictions in the second half does not follow
from, or even seem related to, the qualifications in the first half.

My concern with the short review period remains though.

Thanks,
Simon

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 05 Dec 2005 20:28:45 +0100

>http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html

Dear Brian,
Great! the three stupid points I am stubbornly interested in are 
gathered here! Please read what follows with humour, however the 
three issues are serious.

1. could someone be kind enough to tell me which RFC forbids to quote 
the URL of the currently discussed Drafts, as everyone and netiquette 
demand it for every other quote. Even before the supposed mines, this 
is probably the most consuming "DoS" in the IETF debate. And does not 
help outreach and welcome. No offence intended, but I really think 
this is (with correct name spelling) a point for a practical change.

2. I never saw anyone granted rights without corresponding duties. I 
beg in vain from you and the IAOC who is legally responsible if an 
RFC is judged a legal offense? Who is to pay the fine? Who will go to 
jail? Only this will tell who really owns the IETF IPRs. I know the 
RFC 3066 bis rises this issue: is it why no one wants to answer? or 
is http://www.theregister.co.uk/2005/12/05/minc_icann_letter/ too 
near an issue to risk addressing anything associated with the issue? 
Why my last IESG appeal with its consequences is not addressed?

3. I have real difficulty understanding why an Internet 
user/developer needs to beg an IETF license to use, quote, change, 
work on an RFC? And what will happen if he does not? I saw no 
difference between the Global Internet Community and the IETF 
Community until RFC 3935 told me the later was to influence the 
former (through legal IPR actions to force orthodoxy?). Until then I 
was stupid enough to believe the IETF IPRs were to protect their open 
use and the free debate of every Internet user and developer. 
Licensing permissions seem totally foreign to an open use? Unless it 
is a general permanent and total open use license to everyone? Does 
someone want to get royalties on TCP/IP (as de facto on the DNS and 
on IP addressing)? Or is there a political control because the "USG 
financed" the Internet?

If I copy all the RFCs, sort their content, add a legal blabla paying 
my respects to all those who contributed through the IETF, make an 
open use e-book from them all, class their proposition in some 
orders, updating it when they change, mixing them with other SSDOs 
propositions, etc. translating parts in various languages, adding 
comments on their usage cons and pros and testing, linking the 
various comments people may have made on them, etc. quoting available 
open source/commercial libraries and their variations, etc. and the 
various registry repositories where they can find the values of the 
related parameters, i.e. what the users long for a while, will the 
IAOC sue me and send me to jail as the US DMCA and the French DADVSI would do?

thank you
jfc

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 21:20:39 +0100

In your previous mail you wrote:

   
=> I support Simon's concern: as I explained we need to be allowed to
freely quote RFCs, for instance in a comment in a piece of "open
source" code.

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Dec 2005 10:44:09 +0100

> freely quote RFCs, for instance in a comment in a piece of "open

As stated yesterday - that text has been appropriately fixed. For the
open source discussion, see the ongoing discussion in the IPR WG.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Dec 2005 11:09:03 +0100

JFC (Jefsey) Morfin wrote:
> gathered here! Please read what follows with humour, however the three 
> issues are serious.
> 
> demand it for every other quote. Even before the supposed mines, this is 
> probably the most consuming "DoS" in the IETF debate. And does not help 
> outreach and welcome. No offence intended, but I really think this is 
> (with correct name spelling) a point for a practical change.

I don't understand the context of your question. All the announcements
about the draft Trust agreement have contained the relevant URL,
which is http://koi.uoregon.edu/~iaoc/.

> 
> 2. I never saw anyone granted rights without corresponding duties. I beg 
> in vain from you and the IAOC who is legally responsible if an RFC is 
> judged a legal offense? Who is to pay the fine? Who will go to jail? 

Not being a lawyer, I can make no attempt to answer this question.

> Only this will tell who really owns the IETF IPRs. I know the RFC 3066 
> bis rises this issue: is it why no one wants to answer? or is 
> http://www.theregister.co.uk/2005/12/05/minc_icann_letter/ too near an 
> issue to risk addressing anything associated with the issue?

I fail to see the relevance of this news story to the IETF.

> Why my last 
> IESG appeal with its consequences is not addressed?

Your appeal to the IESG over 3066bis was dealt with.
Currently you have an appeal addressed to an Area Director (hence
not published) about suspension of posting rights, which is
being considered. I am not aware of any other appeals.

> 
> 3. I have real difficulty understanding why an Internet user/developer 
> needs to beg an IETF license to use, quote, change, work on an RFC?

I have never noticed anyone begging. But in fact we are quite aware
that the currently published copyright conditions have some problems
and there is work in progres to fix that.

> And 
> what will happen if he does not? I saw no difference between the Global 
> Internet Community and the IETF Community until RFC 3935 told me the 
> later was to influence the former (through legal IPR actions to force 
> orthodoxy?). Until then I was stupid enough to believe the IETF IPRs 
> were to protect their open use and the free debate of every Internet 
> user and developer. Licensing permissions seem totally foreign to an 
> open use? Unless it is a general permanent and total open use license to 
> everyone?

The concern we have is to allow open and free usage but to prevent (or
make legally uncomfortable) distortions and misrepresentations of IETF
specifications. Legally, that turns out to be very complex.

> Does someone want to get royalties on TCP/IP (as de facto on 
> the DNS and on IP addressing)?

Lots of people want to get royalties on their patents.

> Or is there a political control because 
> the "USG financed" the Internet?

Huh?
> 
> If I copy all the RFCs, sort their content, add a legal blabla paying my 
> respects to all those who contributed through the IETF, make an open use 
> e-book from them all, class their proposition in some orders, updating 
> it when they change, mixing them with other SSDOs propositions, etc. 
> translating parts in various languages, adding comments on their usage 
> cons and pros and testing, linking the various comments people may have 
> made on them, etc. quoting available open source/commercial libraries 
> and their variations, etc. and the various registry repositories where 
> they can find the values of the related parameters, i.e. what the users 
> long for a while, will the IAOC sue me and send me to jail as the US 
> DMCA and the French DADVSI would do?

Somehow, I doubt it. But on the other hand, if you used RFC text as the
basis for a non-interoperable, slightly distorted Internet-like
protocol specification that started to damage the Internet operationally,
the copyright might come into play.

     Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 06 Dec 2005 17:52:42 +0100

Dear Brian,
thank you for your response. It calls for remarks (in the text).

>which is http://koi.uoregon.edu/~iaoc/.

It is current IETF practice _not_ to quote the URL of Drafts each 
time one refers to them. This leads to wasted time and lost comments 
in not permitting readers to click the URL and get the discussed 
text. I see no advantage to this. If anyone was doing the same for 
any other document he would be reminded the courtesy to provide its URL.

>>2. I never saw anyone granted rights without corresponding duties. 
>>I beg in vain from you and the IAOC who is legally responsible if 
>>an RFC is judged a legal offense? Who is to pay the fine? Who will go to jail?
>

You have indicated that you are in relation with lawyers on this 
question. I think everyone is interested by the response. May I 
remind you that RFC 3935 establishes a new mission of the IETF: to 
influence others' design, use and management, making it potentially 
responsible of their errors - all the more than RFC 3935 lists 
resulting constraints (competence, responsibility) the IETF may have 
difficulty to match, what would aggravate the cases.

>>Only this will tell who really owns the IETF IPRs. I know the RFC 
>>3066 bis rises this issue: is it why no one wants to answer? or is 
>>http://www.theregister.co.uk/2005/12/05/minc_icann_letter/ too near 
>>an issue to risk addressing anything associated with the issue?
>

IESG has now adopted RFC 3066 bis. This Draft establishes a IANA de 
facto monopolistic control over language identification. MINC's Chair 
says that ""de facto monopolistic control" over the internet [] could 
"lead to serious forms of balkanisation"". The comments you make 
further on, shows that this control would be exercised through IPRs.

>not published) about suspension of posting rights, which is being 
>considered. I am not aware of any other appeals.

I am afraid this is partly incorrect. Today this appeal is in limbo.

More than two weeks ago I appealed to an AD who declined due to a COI 
and for no AD being assigned to the concerned mailing list (you 
indicated a part of the IETF). He said you would assign another AD. I 
reminded it to you more than one week ago. That AD indicated then you 
were collecting positions, showing you had escalated it to the IESG level?

Due to the context of this appeal, its outcome - whatever it is - is 
important as it will tell the IESG position IRT multilingual support 
by the IETF. And where the langroot registry I work on should fit. I 
have no position. But we need to know.

>>work on an RFC?
>I have never noticed anyone begging.

I will drop this point. We could dispute for hours. I will look at 
this practical issue:

>>If I copy all the RFCs, sort their content, add a legal blabla 
>>paying my respects to all those who contributed through the IETF, 
>>make an open use e-book from them all, class their proposition in 
>>some orders, updating it when they change, mixing them with other 
>>SSDOs propositions, etc. translating parts in various languages, 
>>adding comments on their usage cons and pros and testing, linking 
>>the various comments people may have made on them, etc. quoting 
>>available open source/commercial libraries and their variations, 
>>etc. and the various registry repositories where they can find the 
>>values of the related parameters, i.e. what the users long for a 
>>while, will the IAOC sue me and send me to jail as the US DMCA and 
>>the French DADVSI would do?
>
>Somehow, I doubt it. But on the other hand, if you used RFC text as 
>the basis for a non-interoperable, slightly distorted Internet-like
>protocol specification that started to damage the Internet 
>operationally, the copyright might come into play.

This is a _very_ important statement. Can you confirm it? Can I quote 
it? Or is it only deterrent wording for other purposes?

I have no objection, but we need to understand what this implies. You 
say that a collective copyright could be used for another purpose 
than to protect the rights of a collective author. That use would 
help fulfilling the RFC 3935 defined IETF mission to "influence" the 
"design, use and management" of the Internet (as an aggregation of 
physical systems having their own owners) by others. Most probably 
upon the non consensual (by necessity) - ie. non transparent - 
"decision" process defined by that RFC. That decision would concern:

- the evaluation that the change is a damage and not an improvement. 
In a competitive world this is a way to block competition.
- the conduct of a multimillion dollars legal case. By who? Where? Or 
may be to legitimate a press campaign.

You understand that your implied reference to DMCA, EUCD or DADVSI, 
and the resulting threat of 30 years in jail, call for more 
information on the exact IETF position.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 00:10:53 +0100

Simon Josefsson wrote:

> unacceptable to the Debian and FreeBSD community.  They are
> not in a legal position to grant the Trust all rights to
> derivative works of the work that include portions of RFCs.

We're back at CC-BY vs. CC-BY-SA, aren't we ?  If they are
unwilling to "share alike" they shall not create derivative
work from RFCs.  They can still use them as is.  Bye, Frank

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Thu, 8 Dec 2005 12:55:47 -0800 (PST)

> three issues are serious.

<snip>

> IAOC sue me and send me to jail as the US DMCA and the French DADVSI would do?

Tounge firmly in cheek:

Of course we won't send you to jail. We'll make you come live in a
country with no real cheese and a lot of overly oak-y white wine.

far worse. ;-)

- lel

> IAOC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/iaoc
>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 09 Dec 2005 01:44:49 +0100

>country with no real cheese and a lot of overly oak-y white wine.

This response is recorded. And taken as an unusual but formal 
permission, due to circumstances and repeated denial of response. It 
will be acted upon as described. Any possible opposition will be 
objected this response and Brian's one, and unanswered request of 
authoritative comments.

NB1: I fully understand that people from the darkwing are jealous 
from those living on the brightside. :-)
NB2: I still wait for my response concerning the legal responsibility 
of the Trust.
Thank you.
jfc

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Thu, 8 Dec 2005 19:08:09 -0800 (PST)

On Fri, 9 Dec 2005, JFC (Jefsey) Morfin wrote:
<snip>
> from those living on the brightside. :-)

channeling Lord Vader ... "The force is with you young Skywalker, but
you are not a Jedi yet."

> NB2: I still wait for my response concerning the legal responsibility

I believe that once the IETF Trust is signed, the Trustees will take
on the duties outlined in sec. 7, and , because the trustees are the
members of the IAOC, they will be answerable to the IETF community
under the provisions outlined in BCP 101 - is that the answer you're
looking for? Additional duties can be added by the community idf the
need arises.

> Thank you.

you're welcome

- lel

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 09 Dec 2005 10:35:57 +0100

>channeling Lord Vader ... "The force is with you young Skywalker, but

Dear Lucy,
even billions years ago, by my network age, I am more Qui-Gon Jefsey :-)

>looking for? Additional duties can be added by the community idf the

No. "Legal" does not mean answerable to the community. It means 
answerable to the Law. I will detail the response because I think it 
is important. Very important for the network stability - where would 
we go if the IETF was blocked.

Let be practical. The IETF, after approval of the IESG and the review 
of the IAB, produces texts. It is therefore an author. An author has 
legal responsibilities for the content of his texts. In addition this 
publication is assumed by an editor (the RFC -Editor) the IAOC shares 
into the organisation. Editors have legal responsibility. The more an 
author has authority in his area, the more he has duties. This is a 
cooperative work the rules of which underline (RFC 3935) the 
obligations of competence and responsibility. This is a serious 
published claim of trustability any Judge will consider.

In addition the IETF claims (RFC 3935) that its mission is to 
"influence" those who "design, use and manage" the Internet. This 
Internet is no more conceived as the user's adherence to the IETF 
documents, what implied the necessary acceptance of the IETF 
doctrine, solutions and authority, but as the common digital 
ecosystem of the world, something co-own by everyone independently 
from the IETF.

This means that the IETF, its editorial committee the IESG, its 
review committee the IAB, its editor the RFC -Editor, its management 
the IAOC and the Trustees of its IPRs share responsibilities in the 
incitations published and in the influences seek by its authors.

Let consider the case of an RFC (wearing the diamond logo, IETF name, 
etc.) where the IESG has accepted Security Considerations which do 
not document an important risk. Someone (at this level it is likely 
that that someone is an important entity or a Government) suffer or 
wants to protects users from that risk, and sues the "IETF" for its 
dangerous incitation and its responsibility by influence. Who is 
legally responsible?

In the confusion of the IETF/IESG/IAB/IAOC/ISOC in the area of 
responsibilities, IANAL but common sense is to think that legal, 
ethic and financial responsibility will be found where is the IPR 
claim. It is also likely that the WG members, the IESG and the IAB 
members, and the authors will be individually or collectively 
prosecuted if the case if of enough importance.

1. what is different about IETF from other SSDOs?

     - the IETF wants to be partly binding (influencing) to the users 
of an operational system its users co-own without reference to the IETF
     - the IETF obliges itself to competence and responsibility in 
what it says and in the most efficient use of that system
     - the IETF is a loosely organized structure with no clearly 
identified legal core and no adhesion statement waiving its/or its 
participants' responsibilities.
     - the waiver included in the Internet standard document cannot 
cover the incitations these documents may contain nor the use the 
IETF itself wants to make of them as an influence tool conforming to 
its very mission.
     - the IETF debates are supposed transparent and therefore show 
to what extent and with which seriousness legal rights and societal 
and political consequences have been considered, as well as the 
attention brought to each country, community, individual interest.
     - the IETF is a private entity protected by no international 
mandate, with no official representation assuming responsibility in 
front of national and international law. Its only protection is the 
claim that the USG refused on its behalf (as the initial investor) 
the UN form of international protection offered by the international 
community 
(http://usinfo.state.gov/eur/Archive/2005/Nov/16-685260.html). I am 
not competent enough to know how, when and if such a protection could 
be really obtained.
     - however the concept that "the constitution is in the code", 
i.e. in the standard, is a well known and accepted concept which 
makes the IETF the source of an increasingly important part of the 
world's constitution. However the IETF has not a structure to 
consider the societal, political, sovereignty, economical, privacy, 
etc. impact of its technical decisions.

2. what are possible cases the IETF can be sued for?

     - the way an RFC disfavors economical, societal, national 
interests. This is a well known issue. The IETF fully acknowledges it 
through its appeal procedure. But the IETF interrupt the appeal 
possibility to the IAB. As long as the issue concerns an IETF 
document, endorsed by the IESG and reviewed by the IAB this is OK. 
But when the content has a legal or political aspect beyond the 
authorship authority of the IETF, what is the escalation against a 
biased decision of the IAB?
     - the IETF is an open house. It has studied its own financing 
and functioning and the way it can be used by biased interests (RFC 
3774 and RFC 3869). This shows that there are cases against biased 
dominance, disloyal practices, etc. where the IETF can be considered 
as an accomplice on a case per case basis, or for not having 
structurally corrected a known situation.
     - incitations is an important area. There are attitudes and 
positions that the IETF considers as normal or even claim to 
politically support however they are not technical. This may hurt 
national laws. The way the IETF addresses the lingual issues can 
easily be construed as an actual violation of the human rights. The 
lack of warning about the possibilities permitted or increased by 
RFCs concerning privacy violations, personal profiling over racial, 
cultural, religious aspects, etc. are criminal by themselves.
    - more generally, since 9/11 nations have documented the "nuclear 
equivalent" risks the Internet represents for their citizens (in 
particular the USA were the first to publish an analysis and to build 
a set of requirements I often quote as fundamental, and I do not feel 
meany read: http://whitehouse.gov/pcipb). Should such a risk 
transform into a realty, as we all are conscious [from other 
technology developments] it will at some stage, the prosecution and 
the public opinion(s) will investigate the responsibility of the 
self-proclaimed collective influencing authority having sponsored the 
originating technical failure.

I note that in this I only consider the legal responsibility. But the 
self chosen moral individual or collective responsibility is enormous 
while the IETF offers no protection to its members. Should someone 
propose something which can be misused or wrong with a deadly direct 
or indirect impact, the "consensus" process of the IETF offers no 
serious warranty that this will be corrected by the IETF collective mechanic.

This is only a quick and dirty response, to give you a rough picture. 
Lawyers and politics could build a much more precise one. I note that 
in front of a major privacy/racial information violation  (as RFC 
3066 bis prepares), or of a large number of foreseen deaths (as 
considered by the White House document) legal theories do not hold 
much even if they permit a posthumous victory. The Internet is more 
and more part of everyone life. It MUST be protected from this kind of issues.

Tunis has accepted that for a short while this would be kept under 
the responsibility of the USA through the current status quo. This is 
a BIG responsibility on voluntary individuals and on a confuse 
structure. At least this structure is to seriously consider its 
protection and fuses. ICANN is currently protected by the GAC and the 
USG/NTIA in case of a country suing them over a ccTLD delegation, but 
it is commonly sued for it other decisions. What does protect the 
IETF? All the more than RFC 3935 describes a non-consensual, 
non-transparent IETF decision mechanism: who is legally responsible 
for these decisions. What is the financial protection scheme signed 
for the IAB and IESG members?

If I only take the case of the RFC 3066 bis I know well, there is a 
very impressive number of reasons to legally assign the IETF, the 
IESG, the members of the WG-ltru. We all know that today the point in 
an assignation is not to win but to proceed. What is the use to be 
right when one is dead? I know there are cheaper ways to kill the 
IETF and to force a technology change or a status quo protection or 
even only to block a competitive choice.  But not everyone knows it: 
the most common way we know everyone knows is to sue.

jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Dec 2005 10:00:46 +0100

JFC,

I have checked and from a legal point of view, the closing
signatures last week appear to make no difference to anybody's
legal liability. All recent RFCs carry a rather strong disclaimer
starting 'This document and the information contained herein are
provided on an "AS IS" basis...' and I believe that is necessary
and sufficient.

     Brian

JFC (Jefsey) Morfin wrote:
> answerable to the Law. I will detail the response because I think it is 
> important. Very important for the network stability - where would we go 
> if the IETF was blocked.
> 
> Let be practical. The IETF, after approval of the IESG and the review of 
> the IAB, produces texts. It is therefore an author. An author has legal 
> responsibilities for the content of his texts. In addition this 
> cooperative work the rules of which underline (RFC 3935) the obligations 
> of competence and responsibility. This is a serious published claim of 
> trustability any Judge will consider.
> 
> documents, what implied the necessary acceptance of the IETF doctrine, 
> solutions and authority, but as the common digital ecosystem of the 
> world, something co-own by everyone independently from the IETF.
> 
> This means that the IETF, its editorial committee the IESG, its review 
> committee the IAB, its editor the RFC -Editor, its management the IAOC 
> and the Trustees of its IPRs share responsibilities in the incitations 
> published and in the influences seek by its authors.
> 
> etc.) where the IESG has accepted Security Considerations which do not 
> document an important risk. Someone (at this level it is likely that 
> that someone is an important entity or a Government) suffer or wants to 
> protects users from that risk, and sues the "IETF" for its dangerous 
> incitation and its responsibility by influence. Who is legally responsible?
> 
> responsibilities, IANAL but common sense is to think that legal, ethic 
> and financial responsibility will be found where is the IPR claim. It is 
> also likely that the WG members, the IESG and the IAB members, and the 
> authors will be individually or collectively prosecuted if the case if 
> of enough importance.
> 
>     - the IETF wants to be partly binding (influencing) to the users of 
> an operational system its users co-own without reference to the IETF
>     - the IETF obliges itself to competence and responsibility in what 
> it says and in the most efficient use of that system
>     - the waiver included in the Internet standard document cannot cover 
> the incitations these documents may contain nor the use the IETF itself 
> wants to make of them as an influence tool conforming to its very mission.
>     - the IETF debates are supposed transparent and therefore show to 
> what extent and with which seriousness legal rights and societal and 
> political consequences have been considered, as well as the attention 
> brought to each country, community, individual interest.
> claim that the USG refused on its behalf (as the initial investor) the 
> UN form of international protection offered by the international 
> community (http://usinfo.state.gov/eur/Archive/2005/Nov/16-685260.html). 
> I am not competent enough to know how, when and if such a protection 
> could be really obtained.
>     - however the concept that "the constitution is in the code", i.e. 
> in the standard, is a well known and accepted concept which makes the 
> IETF the source of an increasingly important part of the world's 
> constitution. However the IETF has not a structure to consider the 
> societal, political, sovereignty, economical, privacy, etc. impact of 
> its technical decisions.
> 
>     - the way an RFC disfavors economical, societal, national interests. 
> This is a well known issue. The IETF fully acknowledges it through its 
> appeal procedure. But the IETF interrupt the appeal possibility to the 
> IAB. As long as the issue concerns an IETF document, endorsed by the 
> IESG and reviewed by the IAB this is OK. But when the content has a 
> legal or political aspect beyond the authorship authority of the IETF, 
> what is the escalation against a biased decision of the IAB?
>     - the IETF is an open house. It has studied its own financing and 
> functioning and the way it can be used by biased interests (RFC 3774 and 
> RFC 3869). This shows that there are cases against biased dominance, 
> disloyal practices, etc. where the IETF can be considered as an 
> accomplice on a case per case basis, or for not having structurally 
> corrected a known situation.
> positions that the IETF considers as normal or even claim to politically 
> support however they are not technical. This may hurt national laws. The 
> way the IETF addresses the lingual issues can easily be construed as an 
> actual violation of the human rights. The lack of warning about the 
> possibilities permitted or increased by RFCs concerning privacy 
> violations, personal profiling over racial, cultural, religious aspects, 
> etc. are criminal by themselves.
> particular the USA were the first to publish an analysis and to build a 
> set of requirements I often quote as fundamental, and I do not feel 
> meany read: http://whitehouse.gov/pcipb). Should such a risk transform 
> into a realty, as we all are conscious [from other technology 
> developments] it will at some stage, the prosecution and the public 
> opinion(s) will investigate the responsibility of the self-proclaimed 
> collective influencing authority having sponsored the originating 
> technical failure.
> 
> propose something which can be misused or wrong with a deadly direct or 
> indirect impact, the "consensus" process of the IETF offers no serious 
> warranty that this will be corrected by the IETF collective mechanic.
> 
> Lawyers and politics could build a much more precise one. I note that in 
> front of a major privacy/racial information violation  (as RFC 3066 bis 
> prepares), or of a large number of foreseen deaths (as considered by the 
> White House document) legal theories do not hold much even if they 
> permit a posthumous victory. The Internet is more and more part of 
> everyone life. It MUST be protected from this kind of issues.
> 
> Tunis has accepted that for a short while this would be kept under the 
> responsibility of the USA through the current status quo. This is a BIG 
> responsibility on voluntary individuals and on a confuse structure. At 
> least this structure is to seriously consider its protection and fuses. 
> ICANN is currently protected by the GAC and the USG/NTIA in case of a 
> country suing them over a ccTLD delegation, but it is commonly sued for 
> it other decisions. What does protect the IETF? All the more than RFC 
> 3935 describes a non-consensual, non-transparent IETF decision 
> mechanism: who is legally responsible for these decisions. What is the 
> financial protection scheme signed for the IAB and IESG members?
> 
> If I only take the case of the RFC 3066 bis I know well, there is a very 
> impressive number of reasons to legally assign the IETF, the IESG, the 
> members of the WG-ltru. We all know that today the point in an 
> assignation is not to win but to proceed. What is the use to be right 
> when one is dead? I know there are cheaper ways to kill the IETF and to 
> force a technology change or a status quo protection or even only to 
> block a competitive choice.  But not everyone knows it: the most common 
> way we know everyone knows is to sue.
> 
> jfc
> 
>