ietf
[Top] [All Lists]

Re: FSF campaign against TLS-authz

2009-02-10 20:01:09
Mr. Chiappa is disingenuous in his letter below.  While cogent arguments
are indeed appropriate during the development of a document, such
arguments are irrelevant during the consensus-determination or "Last
Call" process, which only is concerned with the consensus on approving
or disapproving the document.  The IETF is not considering altering the
TLS-authz document at present and Mr. Chiappa knows this.

Rather, the TLS-AUTHZ document is undergoing the IETF "Last Call"  
process. This document is an "individual submission". The TLS Working
Group declined to consider the document in its work.  In the case of
Individual Submissions, a "Last Call" is carried out on the
IETF(_at_)IETF(_dot_)ORG list.  The IETF makes decisions by "consensus", which 
is
indicated by the "Last Call" process.  The "Last Call" process is where
members indicate support or non-support for the document being 'called'.  
In the case of the TLS-authz document, the last call extends for 4
weeks, from January 14, 2009 until February 11, 2009. More information
can be found by reading RFC2026 and associated RFCs on the IETF process.

Beside the patent-encumbrance, the TLS-authz document was subject to a
number of corrupt practices during its development.  The principle
author of the TLS-Authz document is Russ Housley, who is also Chair of
the IESG, which decides to issue consensus calls. Housley was paid by
Co-author Mark Brown, Redphone to produce the document and to file all
appropriate IETF documents. There is no dispute about payment, but the
amount has not been disclosed. I assert this payment is evidence that
Housley was corruptly paid to use his position at the IESG. Although
Housley knew of the patent, and apparently worked from patent documents,
Housley filed seven (7!) documents with the IETF falsely stating that
there were no undisclosed patents.  About 6 months after the IESG
approved the document the first time, the Patent Office disclosed the
existance of the patent application, and Brown/Redphone disclosed the
patent to the IETF. IESG member Sam Hartman (MIT, Kerberos project)
revoked the approval because of the deception.

At about the same time as the first Housley document falsely claiming
that there were no patents, Housley and the IESG silenced myself (Dean
Anderson) for objecting to other patent non-disclosures. The IESG
asserted that RFC3979, updating the IETF process to require patent
disclosures, did not apply.  The IESG (including Housley) also at this
time falsely reported a consensus in the "PR Action" to silence me and
another long time IETF participant, JFC Morfin.  The email messages
indicating consensus in my case were 15 against "PR Action", 2 for.  
Housely's participated corruptly in the false IESG statement on the PR
Action to be false, and Housley also knew that his document required
disclosure according to RFC3979.  These facts show that Housley and
other IESG members acted corruptly on multiple occasions.

I believe that Mr. Chiappa is well acquainted with these facts, which
are authenticated according to the standards set forth in Lorraine v.  
Markel on authenticating email evidence and electronic records as
evidence.  I cannot explain why Mr. Chiappa would suggest that people
should offer technical opinions when the process is seeking a go/no-go
indication of consensus. Mr Chiappa is a long time participant in the
IETF, and is familiar with the IETF processes.  It seems to me more
likely than not that Mr. Chiappa intends to mislead you.


Dean Anderson
A long time IETF participant,
President of the League for Programming Freedom
CEO of AV8 Internet, Inc

        



On Tue, 10 Feb 2009, Noel Chiappa wrote:

Dear Mr. Brown:

I am writing to you (and CC'ing the boards members of the FSF, less one whose
emailbox I couldn't easily locate) in an attempt to explain to you (and
convince you) that 'mass mailings' to the IETF mailing list (or any IETF
list) of the sort the FSF has now attempted twice (once back in October,
2007; and again this week) don't work, and are in fact, if anything,
_counter-productive_ to the FSF's own goals!

The IETF 'members' (since IETF membership is rather a loose concept) are not
impressed with numbers, but rather with cogent and well-reasoned arguments -
and an argument becomes neither more cogent, nor more well-reasoned, by
virtue of being repeated 100 times.

The analogy is not perfect, but you need to approach the IETF more like a
court: a judge - at least, a good one - is not supposed to be influenced by
the number of protestors on the steps of their court; rather, they are
supposed to be influenced by the cogency of the arguments laid before them.
Refiling the exact same amicus brief 100 times (or slightly reworded) isn't
going to have any effect - except to irritate the judge, that they have to
plow through them all.

Efforts such as the one you have laid out in your recent appeal:

  http://www.fsf.org/news/reoppose-tls-authz-standard

have exactly the same effect. Many thousands of people, many of whom are as
busy as your board members, have had their inboxes inundated with a hundred
(and more will arrive shortly, no doubt) basically identical messages (either
cut-and-paste, or at best, rephrasings, of that initial press release). The
natural human reaction is to be irritated - especially since we tried to
point out _last time_ you all tried this how ineffective this was.

I can pretty much guarantee you that it has _no_ positive influence (as the
FSF would view it) effect on the IETF deliberations, and in fact, probably
does active harm to the FSF's _own_ goals.

That is because the IETF has good reason to react negatively to 'drive-by'
email campaigns. How is what the FSF tried substantially different from
BigCorp X telling everyone who works for it 'we want standard X approved,
please send in email to the IETF list asking for it to be approved'. You
wouldn't think that was good, would you? No, I didn't think so. So if the
IETF allows themselves to be influenced by one mass email campaign, all we
are doing is virtually guaranteeing that we will get more. So we have an
active interest is responding _negatively_ to such campaigns.

You also need to understand that the vast majority of the IETF are as unhappy
about producing encumbered technology as you are; and in general, all else
being equal, will much prefer an unencumbered solution. In some cases, after
(usually) carefully considering the pros and cons in some detail, we will
produce such a technology; but you can take it as read that we have, after
due consideration, decided that there are advantages that outweigh that
significant disadvantage. The classic example was our use of public-private
key-systems while the RSA patent was still active; the factors were complex,
but included the power of the idea, the fact that the patent had not long to
run, etc, etc.

If the FSF wants to have the maximal effect, you should prepare the best case
you can make against a particular submission (and simply saying 'encumbered
technology is bad' is _not_ a good case; most of us agree with that, and if
we have decided to go against that, in a particular instance, we must have
had good reasons, and it is _those_ reasons you need to address). Then, send
_one_ copy in to the list, where I can virtually guarantee you that it will
be read more carefully than an avalance of 'me too' messages.

      Noel

PS: Fellow IETF'ers (CC'd), please, no 'me too' messages to the FSF board
members; if you have a good point I didn't make, please send it along, but
otherwise, let's extend to their emailboxes the same courtesy we are
requesting that they extend to ours.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>