Re: [IPFIX] recent ipfix drafts and argus

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

On Mar 14, 2012, at 4:38 AM, Carter Bullard wrote:

> 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
> 150 E. 57th Street Suite 12D
> New York, New York 10022
> 
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
> 
> 
> 
> On Mar 13, 2012, at 10:01 PM, Juergen Quittek wrote:
> 
>> 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

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix