Subject: Putting IPR on IPFIX while the target of IPFIX is to in effect open NetFlow (Was: [IPFIX] Implementation Guidelines // SCTP)

From: Jeroen Massar <[email-masked]>
Date: Wed, 23 May 2007 13:19:29 +0100

[..]
Benoit Claise <[email-masked]> wrote:
>  What you're proposing is something that Cisco has been thinking about for more than 6 months now.
>  Actually we filled in a patent on that one. Because you proposed the idea, we worked on the creation of a new draft
>  http://www.ietf.org/internet-drafts/draft-claise-ipfix-export-per-sctp-stream-00.txt: <http://www.ietf.org/internet-drafts/draft-claise-ipfix-export-per-sctp-stream-00.txt> fully explaining the idea
>  We also posted an IPR: see https://datatracker.ietf.org/public/ipr_list.cgi: <https://datatracker.ietf.org/public/ipr_list.cgi> . 
>  The title of the IPR disclosure is "Cisco's Statement about IPR claimed in draft-claise-ipfix-export-per-sctp-stream-00.txt."
>  Alternatively, directly look up http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt: <http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt> 

(The above long formatted lines are not mine, 72 is a nice limit FYI)

Sorry to be blunt, but what exactly is the point again of 'opening up
NetFlow' if there is going to be IPR stuff being smacked upon IPFIX and
thus encumbering it?

And no the "we don't sue when you don't sue" sillyness is not 'open'.

If there is IPR on this part of IPFIX then it MUST never become part of
the standard of IPFIX that is to be the IETF version of NetFlow.

The "Disclosure"
http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt
doesn't contain *ANY* details on what exactly is IPR'd and what not. So
do we just have to assume that everything in that draft is encumbered?

I also have to note that the existing IPFIX capable collectors actually
can't care so much about what exactly gets delivered and how and in
which stream exactly the IPFIX packets are being sent, I am very sure
that the collectors that already exist are automatically prior art to
what is described in the draft document, therefor nullifying at least
half of the draft.

I am sincerely wondering _why_ Cisco is first going the long route of
trying to get an IETF, and thus widely open accepted, standard form of
NetFlow, thus making all kinds of vendors, who are still reluctant to
use NetFlow because of IPR nonsense, happy and then suddenly, after a
long time of getting people to accept it as a standard means, still yet
again go the IPR route to go back to square zero: no vendor will accept
IPFIX, and there will be various different kinds of "NetFlow" for doing
traffic, and other kinds of, metering.

Please, please, please, come up with something which actually is
original, get a patent for that and make your lawyers happy sueing each
other over those things. Don't go back to encumber something that is
actually starting to get adopted by a lot of vendors.

Greets,
 Jeroen

 (before anybody screams murder, of course like anything IETFish
  should be, this is my private & personal opinion bla bla...)

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 May 2007 11:08:20 +0200

On 2007-05-23 14:19, Jeroen Massar wrote:
...
>>  Alternatively, directly look up http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt

> NetFlow' if there is going to be IPR stuff being smacked upon IPFIX and

It's a defensive non-assert disclosure, which IMHO is equivalent to RF
for anyone who plays nicely. Actually a defensive non-assert may
indirectly *protect* a normal implementor, when you think about its
impact on a third party implementor who does try to assert a patent.

    Brian (IMHO, YMMV, etc.)

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 May 2007 12:34:07 +0200

> impact on a third party implementor who does try to assert a patent.

Such clauses may be acceptable when we know what the patent is, and what
it covers, but this refer to unpublished patent applications.  This
particular license also explicitly enable Cisco to collect retroactive
royalties against anyone who sues Cisco over _any_ patent.

I don't believe these are acceptable terms for a Standards Track
document.

I believe it should be possible to implement a standards track RFC and
be able to sue Cisco if they clearly infringe on your patents.  If you
agree with this notion, I don't see how you can reach a conclusion that
these terms are good.

/Simon

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 May 2007 14:42:40 +0200

[Not speaking in any way for Cisco on this issue...]

> I don't believe these are acceptable terms for a Standards Track

Just imagine the number of lawsuits that would exist if everyone did 
things this way.  Stallman should be jealous.