Dean - I guess I don't get what the problem is. The IETF's process standards
require that there be two instances of a technological specification
implemented to create the proposed standard, so as long as that was done,
it seems to me that the only issue here is whether the parties who donate
their vetting time had/or have the IP rights they are working on
misrepresented and that's a civil fraud issue until money changes hands for
something.
The best part is that there is a unique claim against the party playing the
patent game under Qui Tam as well. Its pretty simple, the filing of the
patent with the claims against the derivatives and the co-contributor's
status would rock here and yes, under Qui Tam there is a simple Federal
Claim against the patent interloper...
So why is everyone so uptight??? The Submarine Patent will cause MUCH more
trouble for the patent filer, since it will be hit with co-contributor
claims either from the IETF itself or the sponsor's of the other member's of
the working group.
The IETF process is a nightmare for IP's that need to be controlled as it
sits so only a madman would bring an unpatented IP to the IETF if they
needed the protection of a patent IMHO. That means that the IETF only needs
to mandate formal IP disclosures are mandatory and that there are
repercussion's for their not being obeyed.
Snicker...
Todd Glassey
----- Original Message -----
From: "Dean Anderson" <dean@xxxxxxx>
To: "TS Glassey" <tglassey@xxxxxxxxxxxxx>
Cc: "Richard Wilbur" <richard.wilbur@xxxxxxxxx>; <ietf@xxxxxxxx>;
<ipr-wg@xxxxxxxx>
Sent: Monday, January 14, 2008 3:40 PM
Subject: Re: Vote on tls-authz??? (fwd)
---------- Forwarded message ----------
Date: Mon, 14 Jan 2008 18:38:10 -0500 (EST)
From: Dean Anderson <dean@xxxxxxx>
To: Sam Hartman <hartmans-ietf@xxxxxxx>
Cc: Dean Anderson <dean@xxxxxxx>, iab@xxxxxxx, iesg@xxxxxxxx, rms@xxxxxxx
Subject: Re: Vote on tls-authz???
On Mon, 14 Jan 2008, Sam Hartman wrote:
>>>>> "Dean" == Dean Anderson <dean@xxxxxxx> writes:
Dean> IESG, I see this vote record still hasn't changed.
Dean> The Third Last Call was announced Sept 25, 2007 and was
Dean> scheduled to conclude on Oct 23, 2007. It seems strange
Dean> that the (second) ballot hasn't been updated to reflect, for
Dean> example, the current composition of the IESG.
Dean> What's up with the vote and evaluation of tls-authz? When
Dean> will we be able to see the IESG evaluation?
Dean, the ballot of a document only changes if that document is
brought to the IESG. If for example Tim decides never to bring the
document forward, then I would never expect the ballot to change.
I personally don't know what Tim plans to do with the document; I
haven't talked to him about it.
I do agree that if Tim plans to recommend the draft for publication
based on the last call, he should act quickly. If he plans to
conclude that last call did not support publication, I think that
prompt action is less important.
The IETF process requires prompt action. Delay seems to only have the
effect of waiting until the uproar dies down, and then quietly doing the
wrong thing anyway. Since the appeals timer for the last call has
expired, it seems to be an abuse of process to proceed.
Just FYI, Redphone recently updated their IPR disclosure; if you have
not taken a look at the latest version of that disclosure then I'd
recommend you do that.
https://datatracker.ietf.org/ipr/912/
I checked the USPTO site. New documents (non-public) were submitted to
the UPPTO for 11/234,404 on 1/3/08 and 10/23/07. We do not know the
contents of these documents, and so cannot comment on them.
Interestingly, it was flagged for "5/25" on 10/15/07 and the flag
withdrawn 10/17/07. "5/25" means the patent exceeds 5 independent
claims, and 25 claims total.
http://www.patentdocs.net/patent_docs/2007/10/pto-flagging-pe.html
Going solely by the IETF disclosure, there is no change. The following
text suggests no infringment for using what is documented in the draft:
"RedPhone Security hereby asserts that the techniques for sending and
receiving authorizations defined in TLS Authorizations Extensions
(version draft-housley-tls-authz-extns-07.txt) may be practiced
without infringing upon RedPhone Security's intellectual property
rights (IPR)."
Unfortunately, most people would be misled by the above statement, and
the IPR disclosure in general, as further reading reveals.
Redphone reserves the right to change that statement:
"RedPhone Security reserves the right to provide further Statements
regarding its IPR with respect to any future or subsequent versions
of TLS Authorizations Extensions."
Further, Redphone implies that there are more specific specifications
than the IETF draft, and that these more specific specifications are
subject to the patent:
"To the extent that the TLS Authorizations Extensions can be implemented
more specifically than described in version
draft-housley-tls-authz-extns-07.txt and thereby used to practice one
or more specific techniques covered by RedPhone Security's revised
patent claims, RedPhone Security agrees to grant licenses for such
uses in a fair and nondiscriminatory manner."
One might wonder what it means to implement TLS Authorizations
Extensions "more specifically" than specified in the draft. No doubt it
has something to do with their modified patent claims and common coding
assumptions. There are many examples of vague specifications that have
been implemented the same way by multiple implmentors (DNS AXFR comes to
mind). Probably, it means the modified claims are fewer in number but
more specific.
While Redphone trumpets that there is no licence required for
_implementers_, there is indeed still a licence require for _users_.
They appear to be trying to recover from GNUTLS, which removed the Authz
implmentation from its code. An _implementation_ source code doesn't
infringe a patent, any more than publication of the patent documents
infringes a patent. The original specifications of the patent are in
fact, public domain. If the patent documents are translated, the
translation is subject to copyright of the translator. In contrast,
Patent law prohibits unlicenced _use_; It is _USE_ of the invention that
is prohibited, not the description in source code. Stating that no
license is required for _implementers_ is no grant whatsover. A patent
does not include a right to prevent publication of the specifications or
description of the patent in any language.
There is no change from their previous position. Except that technical
people may be more likely to stop reading after the first sentence and
think they can use draft-7 without infringing. Such a reading would be
wrong. This IPR disclosure is misleading, and continues to be an abuse
of the IETF process.
Also, not documented yet on my pages about the scandal: Polk and Housley
have also published a book together, and the proceeds from this book
exceed the ISOC standards for conflict of interest. No conflict of
interest has been disclosed by either person. Polk's participation with
the undisclosed conflict of interest is in bad faith.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf