Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying

From: <[email-masked]>
Date: Fri, 7 Aug 2009 11:08:32 +0200

Martin Rex wrote:

> The problem here is that submitting an URL for the real IPR
> disclosure in the IETF disclosure form is subverting to idea that
> the IETF can archive the IPR disclosures in their original form.

No matter what the contents of the IPR disclosure are, I agree that
having them archived by the IETF is a good idea (after all, the link 
might get broken when Certicom redesigns their web site, or something).

The secretariat has now placed the PDF file in the same directory 
on www.ietf.org as other IPR disclosure files:

http://www.ietf.org/ietf-ftp/IPR/certicom%2520-ipr-contribution-to-ietfsept08.pdf

Best regards,
Pasi

---

From: Dean Anderson <[email-masked]>
Date: Fri, 7 Aug 2009 11:19:04 -0400 (EDT)

The IETF has previously demonstrated itself to be unreliable and 
untrustworthy with respect to preserving IPR disclosures.  We still do 
not have the original IPR 765 disclosure.

>From http://www.av8.net/IETF-watch/ 

=========================
February 2009 More TLS-AUTHZ Misconduct: IESG removes Redphone IPR 
Disclosure  Despite giving assurances that IPR documents would never be 
removed, and despite a corporate policy of not deleting history, and 
despite a duty not to destroy evidence, the IESG reneged on all of that 
to remove IPR 765, the first disclosure by Redphone that set off the 
TLS-AUTHZ controversy. This disclosure has been cited by critics of 
Redphone, Russ Housley, Tim Polk and the IESG as evidence of bad faith.
=========================

And some people want to destroy the participation records (bluesheets)
in order to deceive other people about their participation and thereby
deceive and defraud other IETF participants and their counsel in future
litigation about their participation and duty to disclose patents (e.g.
Qualcomm v. Broadcom).  See this discussion:

http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=47819&tid=1249657487
http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=47828&tid=1249657487

These people (some are Qualcomm employees)  are well aware of a duty to
disclose patents to standards bodies, and have been penalized in the
past for failure perform their duties.  Now they want to destroy records
of their participation "to avoid legal liability". The liability is due
to failure to perform their duty to disclose, not from records of their
participation.

I've asserted (with evidence) in the past that the IETF is run by a
mafia which has no regard for the law. Some people disagree with my
assessment, but quite plainly, another organization must preserve these
records since the IETF most evidently cannot be trusted to do so.

		--Dean

On Fri, 7 Aug 2009 [email-masked] wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

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

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Aug 2009 15:44:24 -0400 (EDT)

This is probably an unsatisfactory way to leave things.

We have no solution, but I think there is agreement that IETF IPR
documents need to be archived and preserved despite the demonstrated
unreliability of vendors and the ISOC to preserve these documents.

I think a solution is a systematic effort to mirror and preserve every
document on the IETF TOOLS website needs to be undertaken in such a way
that the administrators of the IETF TOOLS website can't destroy
documents, even with IESG approval.  I think an separate incorporated,
responsible organization should take the responsibility for maintaining
these documents.  I /could/ propose to the LPF to take this on, but
would need volunteers to do the work--the LPF at present cannot fund the
work--it might (after approval) be able to preserve the records.  But a
new organization may needed for this specific purpose.

But before we get too deep into the solution, I think that this subject
and its solution is very quickly going to be beyond the scope of the TLS
Working Group, but is apparently of interest to many TLS WG members.  
Of course, despite an interest by TLS WG members, the TLS Working Group
also can't really recharter itself to compensate for the unreliability
of another part of the IETF--sort of absurd. So it seems this discussion
should be moved somewhere else; perhaps [email-masked] or
[email-masked].  So, I ask the TLS Chairs and other TLS WG
members for suggestions on how to proceed.

		--Dean

617 256 5494