Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol

["todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>]

Thanks Jeff - I appreciate your words but Steve and I have been trading
commentary, nasty remarks, and insults for several years here including my
demands for him to retire, so I would think that by now everyone is pretty
much used to it. But thanks for the comment anyway.  As to the world around
this, Steve's supporter's just say "Damn what is Glassey doing now... that
J$%^&k..." or something stronger, and my supporters and the curious just
send me private email asking my why I put up with it. I probably get 3-5 of
those a day these days, including yours Jeff! (and BTW - all of those that
send those letters of encouragement - thanks!)

The answer is simple - Why I do this is to create a semi-permanent record of
the IETF's refusal to play by its own rules or insure a level and even
playing field.

You see this type of interchange supposedly creates a permanent record and
it is my feeling that this will eventually amount to enough evidence at some
point to have the US DoJ investigate the IETF and its management for
Antitrust and restraint of trade, which I hope will culminate in a US
Federal Court getting involved and in the Court's  telling the NTIA that its
contract with ICANN is illegal since it takes control of the "system" away
from the people it was built to serve. And - yes - I believe that this will
come to pass and that it is coming sooner than later.

As to my detractors, I just laugh at their refusal to see anything like the
real world. So its cool. We each have our own opinions on how things should
operate and I am the one proposing radical change, so you have to give them
space to vent. And remember that many of these people actually earn a living
by being the IETF liaison so any change to the process affects their Job and
these days that is really scary, but this is also why there is so much
Industry Interference in the IETF's processes - that being their need to
keep the processes loose and undefined so that those participants can slip
their standards through to support their products without attracting too
much attention. Hell look at IPSEC for instance.

The Problem - Maintaining the current value of the IP disclosure section of
an IETF document
--------------
But, the real issue here is probably more like whether there should be any
IP disclosure requirements inside an IETF draft or not, and especially ones
(those inside the Standards Process) that spend more than a calendar year in
the hopper such that the IP under them and around them is a moving target.
In a legal sense this would be phrased as a stale declaration, one that had
aged so much and was tied to such a specific point in time that it
there-after would have little or diminishing value moving forward in time.

So far what I think after reviewing this and how the IP disclosure was
implemented, I think that the any disclosure of any IP impingements on an
IETF draft or RFC creates a fiduciary responsibility to keep that portion of
the Draft or RFC accurate and current, so a partial disclosure is worse than
no disclosure and by a lot.

If this is true, then what than means is that each time the draft was
republished or changes state, then this same responsibility would like also
require that the IP implications section be updated and that is
realistically not something that most of our technical contributors have any
desire to participate in. Or that the Editor's of the drafts and RFC's have
time for now either.

The Proposed Solution - eliminate the need to do IP disclosure and replace
it with a Disclaimer
------------------------
With that said, the only option I see is to re-adopt the original policy of
replacing the "Patent Liabilities" section of the Draft or RFC with a
disclaimer stating "that it would be the adopter's responsibility to do a
complete patent or other IP search before adopting anything therein", and
that the IETF, because of its structure and process, cannot be held
accountable for keeping up to date on current IP implications re: any
specific submittal, other than what is required in the submitter's
disclosure that they indeed have the right to publish this document.

. Or they can choose to ignore these words and suffer the consequences if
there is an IP conflict over their use of those IP's.

I made this BTW, in an offline proposal to Steve yesterday.

Optional BCP's detailing IP issues
----------------------------------
I would also propose that anyone that wants to can also file a BCP style
informational draft on the legal aspects of using any specific IETF protocol
as a formal notice to the IETF and its participants regarding IP issues with
a protocol. I would also argue that this is a consistent use of the IETF as
a publishing house for new and emerging technologies. For instance if you
wanted to publish a statement regarding the patent aspects of using any
protocol(s), you could as a BCP statement, and that then would become a part
of the IETF's permanent record, and there would be a record within the IETF
that there were specific IP issues with a technology which puts the total
responsibility on the adopters for verifying that their implementation does
not run afoul of someone else's IP rights.

And as long as we are at it, lets add a section to the IP Disclosure rules
within 2026 (ss10) on "that the IETF is to be held blameless for disclosing
this information if the submitter turns out not to own the IP, or more
importantly, if there is IP-based litigation over the disclosure of the IP
itself, and that it is the responsibility of the Submitter to warrant that
the documents IP issues are addressed and that the document is legally fit
for publication". So then by this model it is the submitter that bears the
brunt of any legal attacks rather than the IETF.

---

Anyone have a problem with these comments? (other than it was me that made
them or you don't like my writing style?)...

Todd



----- Original Message -----
From: "Jeff Williams" <jwkckid1@xxxxxxxxxxxxx>
To: "todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>
Cc: "Stephen Kent" <kent@xxxxxxx>; "Ricardo Barroso"
<ricardo.barroso@xxxxxxxxxxxxx>; "Gianluca Ramunno" <ramunno@xxxxxxxxx>;
<ietf-pkix@xxxxxxx>; <housley@xxxxxxxxxxxx>; "Lynn St.Amour"
<st.amour@xxxxxxxx>; <poised@xxxxxxxxxxxxxxxxx>
Sent: Friday, April 18, 2003 2:03 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


> Todd, Stephen, and all,
>
>   Stephen, please discontinue your diatribe and obvious personal
> attack of Todd.  It is unseemly and unproductive..
>
> todd glassey wrote:
>
> > ----- Original Message -----
> > From: "Stephen Kent" <kent@xxxxxxx>
> > To: "todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>
> > Cc: "Ricardo Barroso" <ricardo.barroso@xxxxxxxxxxxxx>; "Gianluca
Ramunno"
> > <ramunno@xxxxxxxxx>; <ietf-pkix@xxxxxxx>; <housley@xxxxxxxxxxxx>; "Lynn
> > St.Amour" <st.amour@xxxxxxxx>; <poised@xxxxxxxxxxxxxxxxx>
> > Sent: Wednesday, April 16, 2003 2:41 PM
> > Subject: Re: RFC3161(TSP): doubts about tcp protocol
> >
> > > At 1:22 PM -0700 5/16/06, todd glassey wrote:
> > > >Look Dr. Kent - the issue here is that you do not invalidate what I
am
> > > >saying you just attack me personally.  If I am wrong I humbly
apologize
> > but
> > > >so far this is 100% dead-on by my take. So lets get to debunking your
> > > >commentary from the last response -
> > > >
> > >
> > > It appears that Todd can't distinguish between statements of fact
> > > about IP issues and personal criticism.
> > >
> > > Personal criticism would be more along the lines of suggesting that
> > > he is engaging in fear mongering at this stage of the standards
> > > process, perhaps because he tried and failed to block the advancement
> > > of TSP through the WG process, in IETF last call, and via direct
> > > appeal to the IESG. But even that observation is based on facts that
> > > are part of the public record; only the motivation aspect of the
> > > comment might be considered personal criticism.
> >
> > Fear Mongering implies that there is something wrong with what I am
saying
> > or that there is inaccuracy in it and that is not true. So in this
instance
> > I again claim that you use your status as the WG Chair to invalidate
what I
> > am saying becuase I am saying it without ever invalidating  the
statement
> > itself.
> >
> > >
> > > The simple fact is that there have been many claims in the area of
> > > secure time stamping, going back at least as far as the PB patent
> > > cited by Todd. Some of these claims are quite broad. The more modern
> > > ones often make explicit reference to digital signature mechanisms,
> > > whereas the original PB patent does not. The applicability of any
> > > patent to the RFC 3161 protocol is a matter for lawyers and the
> > > courts to determine.
> > >
> > > Mr. Glassey is not a lawyer, although he sometimes seems to forget
> > > that. Thus his assertions about what patents may be violated by a
> > > product that implements 3161 are not legal opinions and there is good
> > > reason to believe that they are motivated by other than simple,
> > > objective, technical observations, based on previous messages on this
> > > list.
> >
> > This is true and I do want to see my patent's supported but I also want
all
> > other TS technologies to get their fair shake in the commercial world
rather
> > then being mandated by a standards org process. There is enough room for
all
> > of us here. What's wrong with that comment other than it leaves you out
of
> > the bigger picture Steve?
> >
> > >
> > > As I noted in my earlier message, in the one legal case that is
> > > clearly relevant to this discussion, a patent holder who made very
> > > broad claims about time stamping sued a vendor who implemented a
> > > TSP-like capability in a product. The defendant prevailed, and the
> > > plaintiff had four broad patent claims disallowed as a result.
> >
> > I can send you a copy of the transscript for the case if you want - Its
> > number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust.
We
> > got a copy of it after I got the letter from Surety at Coastek about my
> > first timestamping tools so that when I started CertifiedTime in August
of
> > 1999 I would know what was what.
> >
> > >
> > > know that I am not a lawyer and thus not qualified to advise
> > > prospective implementors about the implications of this court
> > > decision,
> >
> > Then why did you?
> >
> > > but as an individual technologist I did take away a
> > > positive message relative to 3161.
> >
> > That doesnt answer the question I asked - you made a public commentary -
> > what did you make it as? Please answer this question.
> >
> > > or for that matter any other standards body with which I am familiar,
> > > addresses these issues.
> >
> > Then dont make broad sweeping claims about the legal status of any
> > submission as you have.
> >
> > > RFC 2026 describes the IETF process re IP
> > > issues.
> >
> > The problem is that 2026 is couched to prevent any liability from being
> > ascribed to the IETF and that is what you always hide behind. So until
you
> > invalidate what it is I said Steve this is obvously just another one of
> > those things we will disagree on.
> >
> > >
> > > Steve
>
> Regards,
>
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
> ================================================================
> CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> Information Network Eng. Group. INEG. INC.
> E-Mail jwkckid1@xxxxxxxxxxxxx
> Contact Number: 214-244-4827 or 214-244-3801
>
>