Subject: Re: [IPFIX] recent ipfix drafts and argus

From: Carter Bullard <[email-masked]>
Date: Thu, 1 Mar 2012 11:36:40 -0500

Hey Juergen,
Oh, and I forgot.  Don't know why I didn't mention it before.  Hard to keep up
with all this stuff you know.   You may want to look at US Patent 6405251.  It
seems to apply to this draft., and maybe many other parts of IPFIX, but you
never know.

I'm just the inventor, I suspect that Apple owns the patent now.
You may want to talk to them.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

On Feb 29, 2012, at 4:41 PM, Juergen Quittek wrote:

> Hi Carter,
> 
> If you think it would be beneficial for the draft to have a reference
> to argus, then please make a concrete proposal which text or reference
> should be added where to the draft.  Improvements are always welcome.
> 
> And yes, the IPFIX WG does give credits to contributions and sources
> of ideas.  If we missed anything we accept comments and add credits.
> And we welcome hints in this direction if they are concrete.
> 
> You claim in your message below that examples in draft-ietf-ipfix-a9n
> have been taken from the argus web page.  So far you have not pointed
> at anything concrete.  Your statements are too general such as "each
> example in the draft" has taken somehow from argus.  Please be specific.
> Which example from the IETF draft has been taken from which example on
> the argus web site?
> 
>    Juergen 
> 
> 
> On 29.02.12 17:38, "Carter Bullard" <[email-masked]> wrote:
> 
>> Nevil,I wasn't being disingenuous about Nick or the use of Google in any
>> way.
>> Nick put in references to argus in his papers, and he didn't even really
>> say anything about it.  He even spelled the company's name correctly.
>> 
>> 
>> What I am saying is the aggregation draft is dealing with a topic that has
>> been around for a very long time, and there are lots of implementations of
>> all of the concepts needed in data aggregation around.  Billing packages,
>> statistics packages,  graphing software all have to deal with these
>> issues.
>> I can provide you lots of text books that are good references on the
>> topics of
>> data aggregation that the flow community needs, if you are interested.
>> 
>> With such an unbounded topic to talk about, with so much opportunity,
>> why do all of the examples in the draft look like documented argus
>> examples
>> and program outputs?
>> 
>> I stated this in the original email.  I am stating it now.  If you are
>> going to use
>> examples and technology from other efforts, reference those other efforts.
>> 
>> But each example in the draft is either a specific aggregation where
>> argus has
>> dedicated programs to generate the output, or they are well documented
>> examples from the argus web site or mailing list.
>> 
>> For god's sake, just change the specific objects, the time intervals
>> and the order and format of the output fields, and you would at least
>> not look like you took the examples from argus program output.
>> 
>> If you want to look like argus program output, fine. Mention argus.
>> If you want to look like SiLK, then use SiLK, and mention it.  If you
>> don't
>> want to look like anybody's tools, then just change the format so it
>> doesn't
>> look like anybody's tools.
>> 
>> The IPFIX WG is just a working group in the IETF.  It's mailing list is
>> the
>> only avenue to present issues regarding IPFIX WG business.  I am
>> saying again, and hopefully for the last time, if you are going to use
>> the work of other forums and groups in the flow community, simply give
>> those efforts credit.  If you don't want to do that, modify your work so
>> that it doesn't look like you just lifted it, without concern.
>> 
>> Carter
>> 
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E. 57th Street Suite 12D
>> New York, New York 10022
>> 
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>> 
>> 
>> 
>> 
>> 
>> On Feb 29, 2012, at 2:48 AM, Nevil Brownlee wrote:
>> 
>> 
>> 
>> Hi Carter:
>> 
>> As the other IPFIX co-chair I feel bound to respond to your comments.
>> 
>> Your idea that an Internet Standard should document something
>> that has "dozens of implementations" is weird, to say the least.
>> In many cases there are different groups of people proposing
>> different ideas, so to begin with there isn't even a single
>> implementation.
>> 
>> Your comment about 'a Google search for "Argus flow splitting"' is
>> disingenuous.  When I spent some time with Google looking for
>> information about Argus and its implementation, I simply wasn't able
>> to find anything.  Nick Duffield's papers about sampling, i.e.
>> "Charging from sampled network usage" (2001),
>> "Properties and Prediction of Flow Statistics from Sampled
>>   Packet Streams, " (2002),
>> "Learn more, sample less: control of volume and variance in
>>   network measurement," (2005),
>> all cite the Quosient web page for Argus' way of defining flows,
>> but there's no text in any of these papers about Argus itself!
>> 
>> The IPFIX WG provides a forum for interested people to contribute
>> ideas about information reporting.  If you have something you'd like to
>> see in a WG draft, you need to contribute some text about it on the
>> IPFIX list. In the case of the Aggregation draft, you simply haven't
>> done that.
>> 
>> In short:
>> - If there is published material out there about Argus,
>>    please tell us about it.
>> - Kindly withdraw your mischievous accusations of plagiarism, these
>>    are unfounded.
>> - Constructive technical discussion to the IPFIX list is, of course
>>    always welcome.
>> 
>> Cheers, Nevil
>> 
>> 
>> On 02/27/2012 11:37 AM, Carter Bullard wrote:
>> 
>> Gentle people,
>> 
>> I'm generally pretty quiet when it comes to IPFIX and its efforts.  But
>> as the first
>> 
>> person to develop IP flow records in the 1980's, first to present the
>> idea to the
>> 
>> community in 1992, the first to provide open source flow technology in
>> 1995,
>> 
>> and the author of the longest lived open source flow system, argus; I
>> feel that
>> 
>> I have to say something about the recent wave of IPFIX drafts.
>> 
>> 
>> 
>> The drafts on flow aggregation describe functionality that the Argus
>> project started
>> 
>> over 20 years ago.  The ideas of key modification, conversion of non-key
>> attributes
>> 
>> to key members, aggregation operators, interval distribution and the
>> architecture for it,
>> 
>> were all developed in argus a long long time ago.  draft-ietf-ipfix-a9n
>> is basically
>> 
>> describing the functionality of argus's racluster(), rasplit(), and
>> rabins() programs,
>> 
>> and every example given in the text of draft-ietf-ipfix-a9n can be
>> generated using
>> 
>> argus's rabins(), with only a few gyrations of its command-line, today.
>> 
>> 
>> 
>> I personally would expect that if the IETF was going to describe
>> something that is
>> 
>> "Standards Track", that there would be dozen's of implementations of this
>> kind of
>> 
>> technology available, and that the WG is condensing years of experience to
>> 
>> arrive at a "Standards Track", but, this is not the case.  There is only
>> one current
>> 
>> implementation of the complete capabilities of the features of
>> draft-ietf-ipfix-a9n
>> 
>> that I am aware of, and that is in argus.
>> 
>> 
>> 
>> Taking just one of the technical descriptions in the draft, "interval
>> distribution", I
>> 
>> am not aware of any description of this issue, or implementation of this
>> type
>> 
>> of technology in the literature, outside of argus.  No Google search
>> results for "flow
>> 
>> interval distribution".   In Argus we call it flow splitting.  The first
>> line from a
>> 
>> Google search for "argus flow splitting" return:
>> 
>> 
>> 
>> Scholarly articles for argus flow splitting
>> 
>> Š and prediction of flow statistics from sampled packet Š - Duffield -
>> Cited by 217
>> 
>> 
>> 
>> I'm not saying that Nick knows much about argus's support for flow
>> splitting, but
>> 
>> its still pretty scary that the first hit is from a paper that is used in
>> IPFIX documents.
>> 
>> One would have to assume that the IPFIX community should be aware.
>> 
>> 
>> 
>> My problem is that most of  draft-ietf-ipfix-a9n is prior work that is
>> not widely
>> 
>> implemented, some of the features are still unique to argus.   While IETF
>> support
>> 
>> of technology is a good thing, descriptions of technology without
>> reference
>> 
>> is a difficult thing to interpret.  Is the IPFIX WG describing what they
>> think is new
>> 
>> technology? Does the IPFIX WG think that many companies have implemented
>> 
>> this type of technology, and now its time to standardize it ?  Well, I'm
>> not aware
>> 
>> of any implementation, open or closed, that does the complete set of what
>> the
>> 
>> draft is recommending, other than argus.  So I don't think its new, nor
>> widely
>> 
>> implemented.  I would say its a form of technology plagiarism.
>> 
>> 
>> 
>> IPFIX is considering adding non-IP flows to their definitions.  Argus is
>> the only available
>> 
>> flow technology that has significant non-IP flow data models and support.
>> argus-1.2 had
>> 
>> flow generation, transport, analytics and storage of non-IP flows 20
>> years ago, with its
>> 
>> support for bi-directional ethernet, apple-talk and ARP transaction
>> tracking and reporting.
>> 
>> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and
>> Infiniband flow
>> 
>> models.  Not attributes, but true flow key elements.   This work is
>> non-trivial.
>> 
>> 
>> 
>> The concept that the WG would consider dropping the IP from IPFIX and
>> think that is
>> 
>> all that is needed, is really so completely wrong, that its laughable,
>> and a dis-service
>> 
>> to those that have done the hard work to bring situational awareness and
>> analytics
>> 
>> to non-IP traffic.   The same applies to bi-directional flows, but that
>> is another story.
>> 
>> 
>> 
>> I would love to think that IPFIX could focus back on flow information
>> exchange.
>> 
>> Multicast, non-template based connectionless transport strategies, say
>> over UDT
>> 
>> as an example, rather than getting into areas for which the WG is
>> unprepared to
>> 
>> do even a reasonable job, without resorting to dubious techniques.
>> 
>> 
>> 
>> Just a few comments, I hope that anyone finds it useful.
>> 
>> 
>> 
>> Carter
>> 
>> 
>> 
>> Carter Bullard
>> 
>> CEO/President
>> 
>> QoSient, LLC
>> 
>> 150 E. 57th Street Suite 12D
>> 
>> New York, New York 10022
>> 
>> 
>> 
>> +1 212 588-9133 Phone
>> 
>> +1 212 588-9134 Fax
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 
>> IPFIX mailing list
>> 
>> [email-masked]
>> 
>> https://www.ietf.org/mailman/listinfo/ipfix
>> 
>> 
>> 
>> 
>> -- 
>> ---------------------------------------------------------------------
>> Nevil Brownlee                    Computer Science Department | ITS
>> Phone: +64 9 373 7599 x88941             The University of Auckland
>> FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix
>

---

From: Carter Bullard <[email-masked]>
Date: Thu, 1 Mar 2012 12:16:24 -0500

Hey Juergen,
Oh, and I forgot.  My team at Nortel generated about 10-11 patents in the area
of IP flow and aggregation.  I liked 7,167,860, pretty esoteric, but 6,751,663 seems
to be particularly suited to the draft; "System wide flow aggregation process for
aggregating network activity records".  I was always curious as why I wasn't listed as
an inventor on the complete set of documents, but I had left Nortel by then, so no
harm done.  The other guys up in New Hampshire were pretty good guys, Steve Ball,
Darryl Black, Kevin Farrell, and Dan Mahoney.  That was 1997-1999.

I had always assumed that you guys were doing your due diligence to see what
prior art existed.  I'm pretty sure Apple ended up with the patents in the Great
Auction of 2011.  I'm sure you will know how to follow up with them with regards
to patents and your IETF efforts.

Carter

Carter Bullard
CEO/President
QoSient, LLC

+1 212 588-9133 Phone
+1 212 588-9134 Fax

---

From: Carter Bullard <[email-masked]>
Date: Thu, 1 Mar 2012 14:51:47 -0500

Hey Juergen,
I am so sorry to bother with this again, but I was mistaken regarding who
now owns the portfolio of patents.  It seems that it is Avaya, or at least
part of them.  You should mention it to Dan.

Carter

Carter Bullard
CEO/President
QoSient, LLC

+1 212 588-9133 Phone
+1 212 588-9134 Fax

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 14 Mar 2012 02:01:59 +0000

Hi Carter,

Thank you for pointing to potential issues with patents on
draft-ietf-ipfix-a9n.

I just want to clarify, that the statements that you made so far
do not meet the guidelines for an IPR disclosure as specified
at http://www.ietf.org/ipr/file-disclosure .

Please file an IPR disclosure according to these guidelines if
you think there is a serious issue with one of the patents that
you know of.

In your emails you pointed us to three patents: 6405251, 6751663,
7167860.  Are these all you know of or do you know about further
ones?

You suggested to check if Avaya is holding some of these patents
by now.  Dan Romascanu volunteered to to so.

Thanks,
    Juergen

On 01.03.12 20:51, "Carter Bullard" <[email-masked]> wrote:

>Hey Juergen,I am so sorry to bother with this again, but I was mistaken
>regarding who

---

From: Carter Bullard <[email-masked]>
Date: Tue, 13 Mar 2012 23:38:29 -0400

Juergen,
I am just the inventor, so its really up to the owner to disclose if there
are any problems regarding the patents.  I think it is clear that 6405251
applies to the draft (hard to see that there is anything in the draft that is
not covered in the patent).  But I will have to leave it to the owners to
make any type of IPR disclosure statements.

However, BCP 78 states clearly that the authors, because they are
explicitly granting rights to the IETF regarding use, derivative works
etc…,  have responsibilities regarding IPR, when they become aware
of them.   And BCP 79 is very clear as to what the contributors can and
can't do, once they are aware of IPR.  I would have thought that
the authors themselves would do the appropriate due diligence to ensure
that they could meet their responsibilities. 

My point was to indicate that there has been a lot of work done in the
area covered in the draft, including the basic concepts, methods, even
the examples, and that there should be some references in the draft to the
real work.  The authors cited no outside references, giving the impression
that the draft was original.  I hope that I made my point.

Carter

Carter Bullard
CEO/President
QoSient, LLC

+1 212 588-9133 Phone
+1 212 588-9134 Fax

---

From: Brian Trammell <[email-masked]>
Date: Wed, 14 Mar 2012 14:17:38 +0100

hi, Carter,

I will leave the IPR issues aside for now, as I presume that the owners of
the patents in question have been informed and will follow their
responsibilities under section 6.1.2 of BCP 79. As the authors of the
draft own no patents covering the operations and architecture described
in the draft, and know of no such patents or applications therefor owned
by their employers, we have made no IPR disclosure thereon.

I am still confused as to what, precisely, you are claiming with respect
to non-patent rights for assignment per BCP 78. You mentioned earlier
something about the examples. If you are claiming that you hold the
copyright to section 8 of the document, or that section 8 of the document
is derived from works on which you hold copyright, this is quite simply
not the case. We wrote the examples by hand, to cover the simplest use
cases we could conceive of. We did this explicitly without any reference
to any existing technique or implementation, in order to remain
implementation-independent.

Indeed, the entire document is a descriptive architecture intended to
clarify what we mean when we say "aggregation" at an IPFIX Mediator, in
order to specify a set of IPFIX Information Elements carrying data and
metadata that would allow aggregation implementations to interoperate.
The description of the architecture is meant to cover all possible
operations and implementations thereof in order to avoid prescribing a
particular design, algorithm, or technique. Therefore, though the
_entire_ document itself is an original _work_ (and is therefore clear 
with respect to BCP 78), we make no representation that the document 
describes an original _invention_ at all; I'm therefore somewhat confused 
by your assertion that we have done so.

As to citation, to elaborate on a point already made by the working group
chairs in this thread, it is generally not the practice in such documents
to cite related works unless 1. the related work contains information
required by the definition of the protocol (as a normative reference), 2.
those related works were actually consulted in the production of the
document and provide clarifying information which help to understand it
(as an informative reference), or 3. the document includes a survey of
existing implementations or techniques e.g., as part of requirements
gathering. None of these is the case here, as this was not what the WG
was chartered to do. With respect to Argus (or SiLK, or Flexible NetFlow,
or nfdump, or Tstat, or ntop, or a few others I'm sure I'm forgetting, or
any number of commercial flow aggregation and analysis systems, or all of
the various implementations of aggregation built and discarded in
research communities for reasons of simple not-invented-hereism, citeable
or no), they are not referenced because they were not consulted. With
respect to Argus specifically, I must admit I was personally unaware it
provided any features that looked like those described in -a9n, as I
think of it as a flow meter only.

Now, you could say that it was "clue[less]" of the authors to have
described a framework for aggregation without doing a complete survey of
the implementations thereof, and you would certainly be entitled to your
opinion. But these are the facts of the matter. The opinion of the
authors, as reflected in the document itself, is that descriptive
architectures should be developed to the extent possible without
reference to implementation in order to maximize their applicability.

Of course the operations described in the document have been implemented,
developed, and refined elsewhere. That is the entire _point_ of a
descriptive architecture. If it is the sense of the IPFIX Working Group
that the body of literature on flow aggregation (including
implementations thereof) should therefore be informatively referenced
from this draft, then the authors would of course do so, and would
happily accept contributions from the Working Group and the wider
community as part of such an effort.

Regards,

Brian