[ih] Saving IETF history

[Toerless Eckert]

On Thu, May 13, 2021 at 05:14:22PM -0700, Karl Auerbach via Internet-history wrote:
> One thing about patents and "prior art" is the frequent unwillingness of
> people to look outside of their own disciplines.

Sure, but often there is a patent worthy step involved in porting an idea
into another discipline as well.

> Let's look at the notion of the IMP reloading its memory when it forgot.
> 
> In our human world one might say "I forget Joe's address, do you remember
> it?"  That's similar to the IMPs request for a software image.  And the
> human response, "Oh, it's 123 Imp Lane" is similar to the forgetful IMP
> getting a refresher from a neighbor IMP.
> 
> In a patent one might start with a broad claim such as "Refreshing memory
> from neighbor" and then narrow that down with subsequent claims such as
> "Computer refreshing memory from a neighbor computer via a network".
> 
> That's perhaps a weak example.   I have long been intrigued by learning from
> biology - plants and animals are amazing robust - to see what we can do to
> improve network reliability and reduce operating costs.  There are a lot of
> lessons - such as aim for survival rather than optimum or most efficient use
> of resources. Another is to layer mechanisms so that if one fails there is a
> backup - this is how trees, for instance, often show surprising resilience
> to new conditions - and could perhaps help us harden the Internet's routing
> systems.

Interestingly thats not too far off from the military. History books always
point to distributed routing protocols having been developed for
survivability under attack. Whether thats a true Arpanet creation goal or
just a nice historic myth, it is still a good problem to consider today:
"what happens if i shoot down this component (how about that SDN controller)".
And then the backup and the backup...

Ultimately, this almost-fully self-forming/self-repairing
and self-securing network completely at device level (as opposed to only
at the routing subsystem level) is at the core of what we are doing in ANIMA-WG.

> Given a quite synoptic view one could see how a patent on a Covid RNA
> vaccine technique that informs a person's immune systems of
> yet-to-be-experienced viruses could arguably be applied to the sharing of
> Snort intrusion signatures (rules) - both are informing defensive systems
> about ways to identify an attacker.

Do you want to write a draft about that for ANIMA ? We should have a
good underlying secure messaging system to do th dissemination of that data ;-))

> Everyone here on this list has a deep education that feeds imaginative
> intellects.  I suspect that everyone here has at one time or another had an
> insight that bridged between disciplines.
> 
> The Patent Office isn't so smart, informed, or imaginative.

The only person having worked at a patent office i know by name is Albert Einstein ;-)

I think nowadays there is a lot of name-calling based pattern matching.
The feedback received for patent submissions typically are:
I found your component 1 word in patent 1, ... your component N word in
patent N. How can your patent be novel, i just need to put patent 1...N
into a mixer, press start, and e voila your new patent smoothie.

Maybe there are no humans by AI working in the patent office nowadays. At least
the logic of responses often sounds like cheap & silly logics.

> While we may say
> "but that's obvious" the patent examiners may be unwilling to quickly agree.
> 
> It is for that reason that I have been concerned that many of our Internet
> documents have become dry specifications without expressing the reasoning
> and experimentation behind those specifications, or discussing the paths not
> taken (and why.) [Indeed those mentions of the paths not taken could
> sometimes be more important in a patent fight than the reasoning that was
> adopted for a particular Internet technology.]

Well... My theory is that prudent engineers simply put into RFCs the minimum
necessary specification text so that the all 3 company developers involved
in writing the RFC have a good chance their implementations interoperate.

I say prudent, because whenever you start writing more than this, you are
not helping yourself: You may encourage even more competing implementations,
such as from tier 2 vendors who do not bother to participate in the IETF
process at all. And you have to edit more text which takes longer.

I specifically dislike the standard behavior of prudent engineers to simply
answer (IESG or other) reviewer questions only in email. I for once answered
them by adding the answer text to the draft. But trust me, thats not prudent when you are
interested in getting an RFC out in any reasonable time.

Aka: fully agree with you, but its a bit part of being successful in IETF.
> 
> When fighting patents the goal is often not to fight the patent in its
> entirety but to restrict the scope of the patent to the most narrow of its
> sequence of ever-tightening claims.

I think there needs to be more fundamental reform than these struggles.

Cheers
    Toerless

>         --karl--
> 
> 
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-- 
---
tte at cs.fau.de