[ih] Saving IETF history

Fri May 14 04:14:05 PDT 2021

Toerless and Karl,

As you well know (but others on this last may not), IETF WGs sometimes use
an informational "framework" or "architecture" RFC separate from the actual
protocol specification RFC to document the possible approaches to the
problem, and explain why the particular solution was chosen. So when
reading a protocol spec, it's good to check the references for such
other documents.

Cheers,
Andy

On Thu, May 13, 2021 at 8:58 PM Toerless Eckert via Internet-history <
internet-history at elists.isoc.org> wrote:

> 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
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>