Subject: RE: RFC3161(TSP): doubts about tcp protocol

From: [email-masked] (Peter Gutmann)
Date: Tue, 8 Apr 2003 19:54:52 +1200

"Pere Fiol" <[email-masked]> writes:

>I think that will be a good idea change test of RFC to include this situation
>in Socket chapter, my proposal is:

I agree with this.  As has been pointed out repeatedly in the past, since the
TSP sockets protocol serves no useful purpose, implementations are just
memcpy()'ing in magic values on transmission and treating it as noise to be
stripped on receipt.  Because of this, you can specify anything you like in
the RFC safe in the knowledge that implementors will completely ignore what
you're saying.  As far as I'm concerned, feel free to say whatever makes you
happy in there, although since it's going to be ignored anyway it'd be fun to
require that anyone sending a TSP message be required to jump up and down
saying "I'm a teapot! I'm a teapot!" or something.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Apr 2003 18:30:39 -0400

Folks,

I'd like to suggest a slightly different tact for this discussion.

I think we need to define one transport protocol as a default, and 
make it a MUST implement, so that all clients and all servers are 
capable of communicating, at least in principle.

I'm sorry that I didn't raise this issue earlier, but, better late than never?

I'm agnostic as to what protocol we choose (subject to good arguments 
as to why we chose the protocol in question).

I'd also like to solicit Russ's view on this.

Steve

---

From: "Gianluca Ramunno" <[email-masked]>
Date: Thu, 10 Apr 2003 10:52:29 +0200

Steve,
I agree with you.
Without a well-defined and mandatory transport protocol, it's quite
difficult to formally define the set of the interoperability tests that are
needed to push forward the TSP on the standard track according to RFC2026.

Regarding the question "which protocol should be mandatory?", in my personal
opinion a good choice may be HTTP.
It might be better profiled than now, e.g. by specifying the use of the POST
method.

The description of the other optional transport protocols should be moved
from the draft body to an informative Annex.

Another question is: is the polling mechanism useful or not? From time to
time there is a debate about it.
The polling mechanism makes the TSP protocol stateful at the transport layer
while it is stateless at the application layer and this is not so good.

In my opinion, if the polling is supposed to be useful, it should be moved
to the application layer. This way this mechanism might be used with any
transport protocol. Such a hypothesis, of course, should take care of the
compatibility with the past.

If the polling is supposed useless, we can leave (and forget) it as is in
the socked-based protocol; but this works only if the socket-based protocol
won't be defined as mandatory.

I think that the polling mechanism can be partially substituted by adding to
'PKIStatus' the following possible value:

<snip from=RFC2510>
waiting                (3),
         -- the request body part has not yet been processed,
         -- expect to hear more later
</snip>

This method doesn't transport back the value of the time to wait for.
On the other side, how may a TSU calculate such time interval?

Gianluca

----------------------------------------------------------------------

Gianluca Ramunno,
Computer and Network Security Group (TORSEC)
Dipartimento di Automatica ed Informatica
Politecnico di Torino - Italy
c/o ICT - Laboratorio di Sicurezza
via Cardinal Massaia 83
10147 Torino

GR e-mail:        [email-masked]
TORSEC e-mail:    [email-masked]
TORSEC home page: http://security.polito.it

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: giovedi 10 aprile 2003 0.31
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: RFC3161(TSP): doubts about tcp protocol
>
>
>
> Folks,
>

---

From: Ricardo Barroso <[email-masked]>
Date: Tue, 15 Apr 2003 11:48:46 +0100

Hi!

I agree with Stephen when he says:

    «I think we need to define one transport protocol as a default, and 
make it a MUST implement,
    so that all clients and all servers are capable of communicating, at 
least in principle.»

and with Gianluca when is said that protocol should be HTTP:

    «Without a well-defined and mandatory transport protocol, it's quite
    difficult to formally define the set of the interoperability tests 
that are
    needed to push forward the TSP on the standard track according to 
RFC2026.

    Regarding the question "which protocol should be mandatory?", in my 
personal
    opinion a good choice may be HTTP.».

Cheers,
Ricardo Barroso
(MULTICERT)

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 Apr 2003 09:48:43 -0700

So Richard - what are you going to do when you get sued for building a
product that has NO possible use but to violate filed and reliable
Intellectual Property Rights - This is not just my claim - the original RFC
now has a section that talks to its issues with commercially supplied
patents regarding receipt generation and the use of time data therein. Only
it doesn't bother to include the XML ones or those filed and granted since
the Haber ones it does reference became moot.

This is the real issue with RFC3161 and its becoming a standard. It
essentially creates the first COMMERCIAL standard inside the IETF  since
there can be no use model that is not in violation of any number of patents.
It also will IMHO constrain PKIX for what it is  - an old boys club
masquerading as a standards group.

I see the ascension of 3161 as one of the saddest things that can happen
since it will permanently impugn PKIX and in fact may be the key item
necessary to force the deconstruction of the IETF as we know it today.

Todd Glassey
----- Original Message -----
From: "Ricardo Barroso" <[email-masked]>
To: "Gianluca Ramunno" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, April 15, 2003 3:48 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2003 14:07:55 -0400

>necessary to force the deconstruction of the IETF as we know it today.

While it is thoughtful of Todd to express his opinion about the 
possible intellectual property issues that may be associated with the 
TSP RFC, it is also worth noting that:

	- the RFC makes note of possible IP problems in a fashion 
consistent with IETF guidelines

	- Todd himself is a patent holder in this area, and thus not 
exaclty an unbiased party

	- When Entrust was sued by another patent holder in the area 
of time stamping, 4 claims of the patent holder were struck down by 
the court, who found for the defendant (Entrust)

Thus it is far from clear that, as Todd claims, any use of TSP will 
violate existing patents.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Apr 2003 10:43:48 -0400

At 3:20 PM +0100 4/16/03, Ricardo Barroso wrote:
>What will happen to all the companies from all over the world that 
>are implementing RFC 3161 or that
>already have implemented and posssibly are currently commercializing 
>their Time-Stamping Services?
>
>Is it supposed to exist RFCs (and continue being improved) that 
>supposely violate existing patents?
>Shoulnd't be IETF responsible for investigate that issues before the 
>development and publication of
>internet drafts and RFCs?
>
>Ricardo

The IETF tries to avoid issuing standards that involve patented 
technology, when possible, but it is not always possible to determine 
whether there are patents that may involve IETF standards, e.g., 
because of the lag time between patent filings and issuance, etc.

There are guidelines for how WGs deal with this issue and I refer you 
to those guidelines (RFC 2026).

As noted in my response to Todd, his assertions re problems with 
implementing RFC 3161 are subject to dispute. The RFC does alert 
folks to possible IP issues, but at least one court case in the U.S. 
where a patent holder tried to sue based on a simple time stamp 
protocol implementation that is very analogous to what 3161 calls 
for, provides a basis for believing that very broad patent claims in 
this area may not be upheld in court.

Steve

---

From: Ricardo Barroso <[email-masked]>
Date: Wed, 16 Apr 2003 15:20:17 +0100

What will happen to all the companies from all over the world that are 
implementing RFC 3161 or that
already have implemented and posssibly are currently commercializing 
their Time-Stamping Services?

Ricardo

Stephen Kent wrote:

>     - When Entrust was sued by another patent holder in the area of 
> time stamping, 4 claims of the patent holder were struck down by the 
> court, who found for the defendant (Entrust)
>

---

From: J Adrian Pickering <[email-masked]>
Date: Wed, 16 Apr 2003 20:37:42 +0100

At 15:43 16/04/2003, Stephen Kent wrote:

>implementing RFC 3161 are subject to dispute. The RFC does alert folks to 
>possible IP issues,

and I did so while it was in discussion

>  but at least one court case in the U.S. where a patent holder tried to 
> sue based on a simple time stamp protocol implementation that is very 
> analogous to what 3161 calls for, provides a basis for believing that 
> very broad patent claims in this area may not be upheld in court

I am glad to hear it. The one that really concerns me is the Haber et al 
one in which time stamp data is extended by restamping the (hash) records. 
This is neat but nearly obvious. I look forward to this being challenged in 
court as it needs to be - it nearly cripples the principle of archiving. 
This is what worries me about whatever is behind TAP.

Adrian Pickering/
University of Southampton, UK

---

From: "todd glassey" <[email-masked]>
Date: Tue, 16 May 2006 13:22:15 -0700

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 -

What are all these  numbers the rest of you folks might ask - Steve already
knows what they are - they are some of the many patents that any of you may
violate by building something out of 3161's technology and these are just
the ones listed on the references section of the eOriginals Patent filed in
2001. And - this is just a partial list - there are more, like mine
(EP808997A)
for instance, so rather than attacking me personally Steve - lets try this
again - how about disproving anything I said??? I don't think you can...

4200770 4405829 4625076 4853961 4893338
4981370 4995082 5005200 5136646 5136647
5163091 5164988 5191613 5214703 5231668
5276737 5315658 5323146 5339361 5363448
5371794 5373561 5377270 5390247 5524073
5534855 5555307 5615268 5699431 5748738
5987429 6023509 6070239

But lets keep this up anyway. As far as receipts based on the RFC3161
protocol, my take there is that the Pitney Bowes patent probably covers that
too, but if you think I am wrong  then maybe PKIX should  get a lawyer, or
better yet a Judge to say that in an opinion. Or maybe in this case the
authors of RFC3161 and their company's should be paying for having a legal
opinion rendered since they and you claim that the use of their technology
does not violate these larger-picture patents - Eh Carlisle - how
about it? Does Sharon have budget for this?

---

Steve - back to the IETF issues - You also made a comment that  implied that
there was no legal issues now that RE34954 was invalidated in court, and I
need to ask you a formal question - is this an accurate perception or then
exactly
what do these following words mean - for instance are you formally saying
this as the WG Chair or as a private citizen?  It makes a difference as to
whether you are personally liable for what you say or the IETF's
Organization is - notice the cc:ing to the ISOC Powers. So again, is this
you personally speaking or are you formally speaking for PKIX  and the IETF
here or as BBN's Standards person or just for yourself?

> violate existing patents.

How you possibly got that is beyond me - but it may warrant an ethics
investigation into the operations of PKIX. You seem to imply here that
because of the invalidation of the primary claim of the RE34954 patent that
all TS patents are null and void and that is more than bad advice - it may
have actionable consequences for you as both an IETF Chair and as an
employee of BBN if they foot the bill for your participation in the IETF. I
cant believe you would publicly make such a proclamation - The smart thing
to say would be "Todd I am not a lawyer so the WG just goes on what it is
told" - but your words have shown that you are actively part of this efforts
standards process and as such are probably too close to it to see it as some
of the rest of us do, a private effort to standardize something less useful
than a simple NTP Timestamp, so that two company's can corral the
Timestamping Marketplace.

If that's not a commercial effort I don't know what is -

But back to debunking your commentary - and that in particular is
the specific commentary that there is no such  information available
(i.e. a method of generating a list of applicable patents), which also is
untrue.

The only question here as I see it is whether the IETF has liability for IP
information codified into a Draft some number of years previously as being
"currently valid". That's the problem with the process - i.e. how does the
IETF verify that its IP data on any technology is up to date as of the last
publishing of the document - which is yet another failing of the current
RFC2026. or that the WG didn't withhold current data which is what
happened in this case. And since there was discussion of this at the time
that section was added this is clearly intentional in nature from my
vantage point.

Ahh - spoon feeding you your own garbage can be fun, but tiring Steve and
certainly not in PKIX's best interests - so Dr. Kent - lets ignore the
issues with 2026 and you explain to me with the many patents around
timestamping, receipt generation, and document authentication already in
existence - how is it possible that my commentary is wrong?

just my 2 cents

Todd Glassey

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Ricardo Barroso" <[email-masked]>; "Gianluca Ramunno"
<[email-masked]>; <[email-masked]>; <[email-masked]>; "Lynn
St.Amour" <[email-masked]>
Sent: Tuesday, April 15, 2003 11:07 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Apr 2003 17:41:04 -0400

>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.

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.

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 
know that I am not a lawyer and thus not qualified to advise 
prospective implementors about the implications of this court 
decision, but as an individual technologist I did take away a 
positive message relative to 3161.

Todd's message ends with various comments about the WG or its members 
hiring an attorney to resolve this issue. This is not how the IETF, 
or for that matter any other standards body with which I am familiar, 
addresses these issues.  RFC 2026 describes the IETF process re IP 
issues.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Tue, 16 May 2006 14:46:21 -0700

The problem Adrian is that now there are many more patents than the ones
that were included in the original statement afterall its been how many
years since then?

Todd

----- Original Message -----
From: "J Adrian Pickering" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 16, 2003 12:37 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

> and I did so while it was in discussion

As did any number of people - but once the initial statement of a few
patents were added the furor over this disappeared and 3161 was back on
track to standardization. The problem is that this effort didnt take a year,
it took seven so far that I know of and in that time any number of new or
other derivitive patents have been issued.

> I am glad to hear it.

I dont think you really are - this is the US Court saying that Bell Labs
cannot patent all forms of Digitally Signed Time and really nothing else.
All the other claims held and are still good as far as I know.

> The one that really concerns me is the Haber et al

That is part of RE34954 and that also is the reissue patent from Bell Labs.
But that claim withstood the trial but was not one of the primary claims
that were sought to be invalidated.

> This is neat but nearly obvious.

yes again I think  its a repackging of existing math and process as
crypto-speak to accomplish the making of a claim of a new and novel process
and that's pretty much it. Kinda sad that it gets passed the USPTO but it
does now and then.

> I look forward to this being challenged in

Agreed. And this was originally done in the mid 60's by IBM in their code
management tools.

> This is what worries me about whatever is behind TAP.

yes - but TAP can use a modular regenerating system. TAP's biggest worry is
that it needs 3161's TST as its time setting process and that is inherently
flawed - also the other issue is that TAP does not really take into account
that UTC is a proclamation that happens once a month from the BIPM and not
some magically uniform piece of data. Also that as new timebases are
developed they allow us to retroactively plot Delta-T between what we
stamped something as and what it really was. And that als has to be figured
into the bigger picture here. remember that what the TAP is really for is
digital evidence.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 16 May 2006 14:59:47 -0700

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Ricardo Barroso" <[email-masked]>; "Gianluca Ramunno"
<[email-masked]>; <[email-masked]>; <[email-masked]>; "Lynn
St.Amour" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 16, 2003 2:41 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

> 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.

> objective, technical observations, based on previous messages on this

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?

> 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.

> decision,

Then why did you?

> but as an individual technologist I did take away a

That doesnt answer the question I asked - you made a public commentary -
what did you make it as? Please answer this question.

> 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.

---

From: Antonio Lioy <[email-masked]>
Date: Thu, 17 Apr 2003 09:12:36 +0200

> again - how about disproving anything I said??? I don't think you can...

All this discussion appears to be strongly biased towards the US 
approach to patents.
However, Internet is an international entity and RFC-3161 has a much 
wider application than just to US companies.
I note that in Europe at least EESSI, ETSI and the Italian government 
are suggesting or mandating the use of timestamps and RFC-3161 is the 
de-facto standard in this field.
In general, the US patents are not valid in other countries unless they 
have been registered *prior* to pubblication (as well shown by the RSA 
patent in the last 30 years). So we strongly think that RFC-3161 is 
providing a good service for all these other countries and we leave to 
US citizens, companies and courts the discussion if the mentioned 
patents hold or not. For the vast majority of Internet the answer is 
simply NO!
So please Todd, take this case to courts and leave Internet be free to 
set up a good technical standard to be used at least in that part of the 
world outside US.

Cheers,

Antonio Lioy

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 May 2006 07:03:56 -0700

Steve - the things I have to reply to this I will cc to Tim but there is
little point in continuing this conversation. Lets just leave it that I
forced the issue into the spotlight again so it will appear in the mailing
list archive unless its edited out,  and you folks (you and Tim as the WG
Chairs) can ride the wave whatever happens.

Todd
----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 17, 2003 6:47 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

> Todd,
>
> I don't need to play by your rules (e.g., meeting your criteria for
> invalidating what you assert) to convey my message in this forum.
>
> My comments are rational and clear, unlike most of yours.
>
> You seem to confuse cause and effect. It is not that people pay
> attention to what I say primarily because I am the PKIX WG chair.
> Rather, in part, I was selected to serve as chair because of my
> knowledge in the area. Thus people often pay attention to what I say
> because what I say generally makes sense, and is usually correct,
> irrespective of my role in this WG.
>
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2003 09:47:21 -0400

Todd,

Steve

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 May 2006 07:38:25 -0700

Antonio - I will respond to this personally to you off the main list. lets
not waste the list's traffic on this anymore

Todd

----- Original Message -----
From: "Antonio Lioy" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Lynn St.Amour"
<[email-masked]>; <[email-masked]>
Sent: Thursday, April 17, 2003 12:12 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

---

From: "Peter Hesse" <[email-masked]>
Date: Thu, 17 Apr 2003 12:53:34 -0400

Todd,

>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.

I suggest you read http://angryflower.com/bobsqu.gif

Proper grammar combined with ridiculous personal attacks will probably
get you farther than ridiculous personal attacks alone.

--Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of todd glassey
Sent: Tuesday, May 16, 2006 6:00 PM
To: Stephen Kent
Cc: Ricardo Barroso; Gianluca Ramunno; [email-masked];
[email-masked]; Lynn St.Amour; [email-masked]
Subject: Re: RFC3161(TSP): doubts about tcp protocol

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Ricardo Barroso" <[email-masked]>; "Gianluca
Ramunno" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Lynn St.Amour" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, April 16, 2003 2:41 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

> >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

> 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.

> patent to the RFC 3161 protocol is a matter for lawyers and the courts

> to determine.

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?

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.

Then why did you?

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.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 18 May 2006 07:21:11 -0700

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" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; "Ricardo Barroso"
<[email-masked]>; "Gianluca Ramunno" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Lynn St.Amour"
<[email-masked]>; <[email-masked]>
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:
>
Ramunno"
> > > >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
> > Fear Mongering implies that there is something wrong with what I am
saying
> > This is true and I do want to see my patent's supported but I also want
all
> > number 99-203 in the Western Dist of Va, Feb 1999. - Surety V Entrust.
We
> > ascribed to the IETF and that is what you always hide behind. So until
you
> 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 [email-masked]
> Contact Number: 214-244-4827 or 214-244-3801
>
>

---

From: "todd glassey" <[email-masked]>
Date: Thu, 18 May 2006 09:09:16 -0700

By the way - my apologies for what many will consider very negative
commentary below in the previous message - I thought I should really bring
out a little more of my motivations so that it was clear that I am not
really a madman or an anarchist at all. In fact I am pretty conservative
politically but anyway - my intent is not negative at all but rather that I
seek certain changes to correct things that I see as wrong with the Global
Internet Standards Process at this time.  Most of these are at an
organizational level, but they all generally circle around having the same
set of simple rules be applied to everyone equally and that the process and
expectations of each step of the process are defined as opposed as they are
now, which  much left up to the WG Chairs and AD's to come to consensus on.
Mark that phrase "simple rules" and not the convoluted ones we have today.

In any event, most all of you probably don't want to hear this, so I will
close this thread out from my standpoint unless someone asks me for a
reply - Again my apologies for "wasting" your time.

Todd

----- Original Message -----
From: "todd glassey" <[email-masked]>
To: "Jeff Williams" <[email-masked]>; <[email-masked]>; "Lynn
St.Amour" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 18, 2006 7:21 AM
Subject: Possible Solution: WAS Re: RFC3161(TSP): doubts about tcp protocol

> The Problem - Maintaining the current value of the IP disclosure section
of
want
> > > 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
> > > first timestamping tools so that when I started CertifiedTime in
August
> of

---

From: "todd glassey" <[email-masked]>
Date: Thu, 18 May 2006 09:09:16 -0700

Todd

----- Original Message -----
From: "todd glassey" <[email-masked]>
To: "Jeff Williams" <[email-masked]>; <[email-masked]>; "Lynn

want
for
out
August