From carter@qosient.com Thu Mar 1 08:36:51 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0621E80B8 for ; Thu, 1 Mar 2012 08:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dyVYLzQVWGL for ; Thu, 1 Mar 2012 08:36:49 -0800 (PST) Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2B21E81F5 for ; Thu, 1 Mar 2012 08:36:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 81281286B6; Thu, 1 Mar 2012 11:36:42 -0500 (EST) Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 80867286B1; Thu, 1 Mar 2012 11:36:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_1BBAD7A3-7F2D-4A3F-B0FF-8B1ED0945B56"; protocol="application/pkcs7-signature"; micalg=sha1 From: Carter Bullard In-Reply-To: Date: Thu, 1 Mar 2012 11:36:40 -0500 Message-Id: <5816B9C7-7E7F-4BAE-BEED-C0E5E78749BB@qosient.com> References: To: Juergen Quittek X-Mailer: Apple Mail (2.1257) Cc: Nevil Brownlee , Argus , IETF IPFIX Working Group Subject: Re: [IPFIX] recent ipfix drafts and argus X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:36:51 -0000 --Apple-Mail=_1BBAD7A3-7F2D-4A3F-B0FF-8B1ED0945B56 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1A2B97E-FF2B-4396-A9AA-49EC16563EDF" --Apple-Mail=_B1A2B97E-FF2B-4396-A9AA-49EC16563EDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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, >=20 > 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. >=20 > 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. >=20 > 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? >=20 > Juergen=20 >=20 >=20 > On 29.02.12 17:38, "Carter Bullard" wrote: >=20 >> 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. >>=20 >>=20 >> 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. >>=20 >> 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? >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Carter >>=20 >> Carter Bullard >> CEO/President >> QoSient, LLC >> 150 E. 57th Street Suite 12D >> New York, New York 10022 >>=20 >> +1 212 588-9133 Phone >> +1 212 588-9134 Fax >>=20 >>=20 >>=20 >>=20 >>=20 >> On Feb 29, 2012, at 2:48 AM, Nevil Brownlee wrote: >>=20 >>=20 >>=20 >> Hi Carter: >>=20 >> As the other IPFIX co-chair I feel bound to respond to your comments. >>=20 >> 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. >>=20 >> 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! >>=20 >> 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. >>=20 >> 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. >>=20 >> Cheers, Nevil >>=20 >>=20 >> On 02/27/2012 11:37 AM, Carter Bullard wrote: >>=20 >> Gentle people, >>=20 >> I'm generally pretty quiet when it comes to IPFIX and its efforts. = But >> as the first >>=20 >> person to develop IP flow records in the 1980's, first to present the >> idea to the >>=20 >> community in 1992, the first to provide open source flow technology = in >> 1995, >>=20 >> and the author of the longest lived open source flow system, argus; I >> feel that >>=20 >> I have to say something about the recent wave of IPFIX drafts. >>=20 >>=20 >>=20 >> The drafts on flow aggregation describe functionality that the Argus >> project started >>=20 >> over 20 years ago. The ideas of key modification, conversion of = non-key >> attributes >>=20 >> to key members, aggregation operators, interval distribution and the >> architecture for it, >>=20 >> were all developed in argus a long long time ago. = draft-ietf-ipfix-a9n >> is basically >>=20 >> describing the functionality of argus's racluster(), rasplit(), and >> rabins() programs, >>=20 >> and every example given in the text of draft-ietf-ipfix-a9n can be >> generated using >>=20 >> argus's rabins(), with only a few gyrations of its command-line, = today. >>=20 >>=20 >>=20 >> I personally would expect that if the IETF was going to describe >> something that is >>=20 >> "Standards Track", that there would be dozen's of implementations of = this >> kind of >>=20 >> technology available, and that the WG is condensing years of = experience to >>=20 >> arrive at a "Standards Track", but, this is not the case. There is = only >> one current >>=20 >> implementation of the complete capabilities of the features of >> draft-ietf-ipfix-a9n >>=20 >> that I am aware of, and that is in argus. >>=20 >>=20 >>=20 >> Taking just one of the technical descriptions in the draft, "interval >> distribution", I >>=20 >> am not aware of any description of this issue, or implementation of = this >> type >>=20 >> of technology in the literature, outside of argus. No Google search >> results for "flow >>=20 >> interval distribution". In Argus we call it flow splitting. The = first >> line from a >>=20 >> Google search for "argus flow splitting" return: >>=20 >>=20 >>=20 >> Scholarly articles for argus flow splitting >>=20 >> =8A and prediction of flow statistics from sampled packet =8A - = Duffield - >> Cited by 217 >>=20 >>=20 >>=20 >> I'm not saying that Nick knows much about argus's support for flow >> splitting, but >>=20 >> its still pretty scary that the first hit is from a paper that is = used in >> IPFIX documents. >>=20 >> One would have to assume that the IPFIX community should be aware. >>=20 >>=20 >>=20 >> My problem is that most of draft-ietf-ipfix-a9n is prior work that = is >> not widely >>=20 >> implemented, some of the features are still unique to argus. While = IETF >> support >>=20 >> of technology is a good thing, descriptions of technology without >> reference >>=20 >> is a difficult thing to interpret. Is the IPFIX WG describing what = they >> think is new >>=20 >> technology? Does the IPFIX WG think that many companies have = implemented >>=20 >> this type of technology, and now its time to standardize it ? Well, = I'm >> not aware >>=20 >> of any implementation, open or closed, that does the complete set of = what >> the >>=20 >> draft is recommending, other than argus. So I don't think its new, = nor >> widely >>=20 >> implemented. I would say its a form of technology plagiarism. >>=20 >>=20 >>=20 >> IPFIX is considering adding non-IP flows to their definitions. Argus = is >> the only available >>=20 >> flow technology that has significant non-IP flow data models and = support. >> argus-1.2 had >>=20 >> flow generation, transport, analytics and storage of non-IP flows 20 >> years ago, with its >>=20 >> support for bi-directional ethernet, apple-talk and ARP transaction >> tracking and reporting. >>=20 >> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and >> Infiniband flow >>=20 >> models. Not attributes, but true flow key elements. This work is >> non-trivial. >>=20 >>=20 >>=20 >> The concept that the WG would consider dropping the IP from IPFIX and >> think that is >>=20 >> all that is needed, is really so completely wrong, that its = laughable, >> and a dis-service >>=20 >> to those that have done the hard work to bring situational awareness = and >> analytics >>=20 >> to non-IP traffic. The same applies to bi-directional flows, but = that >> is another story. >>=20 >>=20 >>=20 >> I would love to think that IPFIX could focus back on flow information >> exchange. >>=20 >> Multicast, non-template based connectionless transport strategies, = say >> over UDT >>=20 >> as an example, rather than getting into areas for which the WG is >> unprepared to >>=20 >> do even a reasonable job, without resorting to dubious techniques. >>=20 >>=20 >>=20 >> Just a few comments, I hope that anyone finds it useful. >>=20 >>=20 >>=20 >> Carter >>=20 >>=20 >>=20 >> Carter Bullard >>=20 >> CEO/President >>=20 >> QoSient, LLC >>=20 >> 150 E. 57th Street Suite 12D >>=20 >> New York, New York 10022 >>=20 >>=20 >>=20 >> +1 212 588-9133 Phone >>=20 >> +1 212 588-9134 Fax >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >>=20 >>=20 >>=20 >> --=20 >> --------------------------------------------------------------------- >> 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 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 --Apple-Mail=_B1A2B97E-FF2B-4396-A9AA-49EC16563EDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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" <carter@qosient.com> = 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

=8A and = prediction of flow statistics from sampled packet =8A - 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

IPFIX@ietf.org

https://www.ietf.org/= mailman/listinfo/ipfix




-- =
------------------------------------------------------------= ---------
Nevil Brownlee =             &n= bsp;      Computer Science Department | = ITS
Phone: +64 9 373 7599 = x88941 =             Th= e University of Auckland
FAX: = +64 9 373 7453   Private Bag 92019, Auckland 1142, New = Zealand











_______________________________________________
IPFIX mailing = list
IPFIX@ietf.org
https://www.ietf.org/= mailman/listinfo/ipfix

= --Apple-Mail=_B1A2B97E-FF2B-4396-A9AA-49EC16563EDF-- --Apple-Mail=_1BBAD7A3-7F2D-4A3F-B0FF-8B1ED0945B56 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2 uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwMTE2MzY0MVowIwYJKoZIhvcNAQkE MRYEFKEXPmIEFUvZoHCsn46UrtANbFiZMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB AJa5bkwq4TD2GnwOLGFu+rLRrFi0cNoRqZ8fV3s+rjnuP3FvCs4sEb+AYuzgqaQEhi2Pyh+t8IGE vcYSate4hwKFSPGsgFSeJQXVdhtKTID3VLhQ8S/tcxOYX/wWxezYSyIcFJPsF/2UfGZ4N8hTllja XjMKcu5MH6s7ECJVP8okvYSokvUQIj3zsL5UGBe2lPA69DyxsqxwQv0xtzU3EUYZTwQfwWo9VePd YQZuLiuJS1DIgWwYRElWWp4f3t2X0uDS8Tqrnk1AH2snKR2NPTXug/qq5IdsT5pcDgW+SunGEsTX cRGNBOHblQOGT7OGjg0s3XV7cSimug2Hud1W1LkAAAAAAAA= --Apple-Mail=_1BBAD7A3-7F2D-4A3F-B0FF-8B1ED0945B56-- From carter@qosient.com Thu Mar 1 09:16:34 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4727621E8041 for ; Thu, 1 Mar 2012 09:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IyGpBST87QN for ; Thu, 1 Mar 2012 09:16:33 -0800 (PST) Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9805421E804B for ; Thu, 1 Mar 2012 09:16:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id E218028721; Thu, 1 Mar 2012 12:16:25 -0500 (EST) Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id E10E5286DC; Thu, 1 Mar 2012 12:16:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_37731869-1602-4A26-B4FB-EA349A9A1DF0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Carter Bullard In-Reply-To: <5816B9C7-7E7F-4BAE-BEED-C0E5E78749BB@qosient.com> Date: Thu, 1 Mar 2012 12:16:24 -0500 Message-Id: <23042BBD-9F12-4D03-9853-75C26E4B324A@qosient.com> References: <5816B9C7-7E7F-4BAE-BEED-C0E5E78749BB@qosient.com> To: Juergen Quittek X-Mailer: Apple Mail (2.1257) Cc: Nevil Brownlee , Argus , IETF IPFIX Working Group Subject: Re: [IPFIX] recent ipfix drafts and argus X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:16:34 -0000 --Apple-Mail=_37731869-1602-4A26-B4FB-EA349A9A1DF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 150 E. 57th Street Suite 12D New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax On Mar 1, 2012, at 11:36 AM, Carter Bullard wrote: > 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. >=20 > I'm just the inventor, I suspect that Apple owns the patent now. > You may want to talk to them. >=20 > Carter >=20 > Carter Bullard > CEO/President > QoSient, LLC > 150 E. 57th Street Suite 12D > New York, New York 10022 >=20 > +1 212 588-9133 Phone > +1 212 588-9134 Fax >=20 >=20 >=20 > On Feb 29, 2012, at 4:41 PM, Juergen Quittek wrote: >=20 >> Hi Carter, >>=20 >> 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. >>=20 >> 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. >>=20 >> 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? >>=20 >> Juergen=20 >>=20 >>=20 >> On 29.02.12 17:38, "Carter Bullard" wrote: >>=20 >>> 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. >>>=20 >>>=20 >>> 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. >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Carter >>>=20 >>> Carter Bullard >>> CEO/President >>> QoSient, LLC >>> 150 E. 57th Street Suite 12D >>> New York, New York 10022 >>>=20 >>> +1 212 588-9133 Phone >>> +1 212 588-9134 Fax >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Feb 29, 2012, at 2:48 AM, Nevil Brownlee wrote: >>>=20 >>>=20 >>>=20 >>> Hi Carter: >>>=20 >>> As the other IPFIX co-chair I feel bound to respond to your = comments. >>>=20 >>> 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. >>>=20 >>> 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! >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Cheers, Nevil >>>=20 >>>=20 >>> On 02/27/2012 11:37 AM, Carter Bullard wrote: >>>=20 >>> Gentle people, >>>=20 >>> I'm generally pretty quiet when it comes to IPFIX and its efforts. = But >>> as the first >>>=20 >>> person to develop IP flow records in the 1980's, first to present = the >>> idea to the >>>=20 >>> community in 1992, the first to provide open source flow technology = in >>> 1995, >>>=20 >>> and the author of the longest lived open source flow system, argus; = I >>> feel that >>>=20 >>> I have to say something about the recent wave of IPFIX drafts. >>>=20 >>>=20 >>>=20 >>> The drafts on flow aggregation describe functionality that the Argus >>> project started >>>=20 >>> over 20 years ago. The ideas of key modification, conversion of = non-key >>> attributes >>>=20 >>> to key members, aggregation operators, interval distribution and the >>> architecture for it, >>>=20 >>> were all developed in argus a long long time ago. = draft-ietf-ipfix-a9n >>> is basically >>>=20 >>> describing the functionality of argus's racluster(), rasplit(), and >>> rabins() programs, >>>=20 >>> and every example given in the text of draft-ietf-ipfix-a9n can be >>> generated using >>>=20 >>> argus's rabins(), with only a few gyrations of its command-line, = today. >>>=20 >>>=20 >>>=20 >>> I personally would expect that if the IETF was going to describe >>> something that is >>>=20 >>> "Standards Track", that there would be dozen's of implementations of = this >>> kind of >>>=20 >>> technology available, and that the WG is condensing years of = experience to >>>=20 >>> arrive at a "Standards Track", but, this is not the case. There is = only >>> one current >>>=20 >>> implementation of the complete capabilities of the features of >>> draft-ietf-ipfix-a9n >>>=20 >>> that I am aware of, and that is in argus. >>>=20 >>>=20 >>>=20 >>> Taking just one of the technical descriptions in the draft, = "interval >>> distribution", I >>>=20 >>> am not aware of any description of this issue, or implementation of = this >>> type >>>=20 >>> of technology in the literature, outside of argus. No Google search >>> results for "flow >>>=20 >>> interval distribution". In Argus we call it flow splitting. The = first >>> line from a >>>=20 >>> Google search for "argus flow splitting" return: >>>=20 >>>=20 >>>=20 >>> Scholarly articles for argus flow splitting >>>=20 >>> =8A and prediction of flow statistics from sampled packet =8A - = Duffield - >>> Cited by 217 >>>=20 >>>=20 >>>=20 >>> I'm not saying that Nick knows much about argus's support for flow >>> splitting, but >>>=20 >>> its still pretty scary that the first hit is from a paper that is = used in >>> IPFIX documents. >>>=20 >>> One would have to assume that the IPFIX community should be aware. >>>=20 >>>=20 >>>=20 >>> My problem is that most of draft-ietf-ipfix-a9n is prior work that = is >>> not widely >>>=20 >>> implemented, some of the features are still unique to argus. While = IETF >>> support >>>=20 >>> of technology is a good thing, descriptions of technology without >>> reference >>>=20 >>> is a difficult thing to interpret. Is the IPFIX WG describing what = they >>> think is new >>>=20 >>> technology? Does the IPFIX WG think that many companies have = implemented >>>=20 >>> this type of technology, and now its time to standardize it ? Well, = I'm >>> not aware >>>=20 >>> of any implementation, open or closed, that does the complete set of = what >>> the >>>=20 >>> draft is recommending, other than argus. So I don't think its new, = nor >>> widely >>>=20 >>> implemented. I would say its a form of technology plagiarism. >>>=20 >>>=20 >>>=20 >>> IPFIX is considering adding non-IP flows to their definitions. = Argus is >>> the only available >>>=20 >>> flow technology that has significant non-IP flow data models and = support. >>> argus-1.2 had >>>=20 >>> flow generation, transport, analytics and storage of non-IP flows 20 >>> years ago, with its >>>=20 >>> support for bi-directional ethernet, apple-talk and ARP transaction >>> tracking and reporting. >>>=20 >>> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and >>> Infiniband flow >>>=20 >>> models. Not attributes, but true flow key elements. This work is >>> non-trivial. >>>=20 >>>=20 >>>=20 >>> The concept that the WG would consider dropping the IP from IPFIX = and >>> think that is >>>=20 >>> all that is needed, is really so completely wrong, that its = laughable, >>> and a dis-service >>>=20 >>> to those that have done the hard work to bring situational awareness = and >>> analytics >>>=20 >>> to non-IP traffic. The same applies to bi-directional flows, but = that >>> is another story. >>>=20 >>>=20 >>>=20 >>> I would love to think that IPFIX could focus back on flow = information >>> exchange. >>>=20 >>> Multicast, non-template based connectionless transport strategies, = say >>> over UDT >>>=20 >>> as an example, rather than getting into areas for which the WG is >>> unprepared to >>>=20 >>> do even a reasonable job, without resorting to dubious techniques. >>>=20 >>>=20 >>>=20 >>> Just a few comments, I hope that anyone finds it useful. >>>=20 >>>=20 >>>=20 >>> Carter >>>=20 >>>=20 >>>=20 >>> Carter Bullard >>>=20 >>> CEO/President >>>=20 >>> QoSient, LLC >>>=20 >>> 150 E. 57th Street Suite 12D >>>=20 >>> New York, New York 10022 >>>=20 >>>=20 >>>=20 >>> +1 212 588-9133 Phone >>>=20 >>> +1 212 588-9134 Fax >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>>=20 >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>>=20 >>> https://www.ietf.org/mailman/listinfo/ipfix >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> = --------------------------------------------------------------------- >>> 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 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_37731869-1602-4A26-B4FB-EA349A9A1DF0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2 uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwMTE3MTYyNFowIwYJKoZIhvcNAQkE MRYEFOW7efaa5PKCOsbvX4TC242MRFboMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB AH0G5ciQULh5cN+HdqVRVF3n7u7XNhIDmslF5KApLm6ZxMQSjnIXa5MP3fcCTvYcFU7cJwrpBlZ7 eIxBNB1MxPk6JfNYHz6eJg1ZOYxe9j9hqkCeDW8k/AmB1L6sAZlbvw4V9ooXXQX8YWr1h9BMB6EG 0UEhPFNQ/ZJIN6tisayb0IGgOoEq+fk+IIoGnRAWQqMpQ1lOnRrhGlZ4q4wkAu5Ya9cwtdnAfQkZ XTGy8CKiqPBNeRWJdLf6fB+7+IVzsoCQgWzHPHXXCu2BsPB0dpT3lqb60uOwrQ6leHZUqu/1OS2h qnasvsNObSajxSDkhBvQtrNiJ/0HWZJtQzvfSdsAAAAAAAA= --Apple-Mail=_37731869-1602-4A26-B4FB-EA349A9A1DF0-- From carter@qosient.com Thu Mar 1 11:51:57 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0010821E8043 for ; Thu, 1 Mar 2012 11:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdyGu1fVdRsL for ; Thu, 1 Mar 2012 11:51:54 -0800 (PST) Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52F21E800F for ; Thu, 1 Mar 2012 11:51:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id BEB41284C4; Thu, 1 Mar 2012 14:51:48 -0500 (EST) Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id A354A28655; Thu, 1 Mar 2012 14:51:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_0669B83C-6049-4737-A512-D417BBBE6B29"; protocol="application/pkcs7-signature"; micalg=sha1 From: Carter Bullard In-Reply-To: <23042BBD-9F12-4D03-9853-75C26E4B324A@qosient.com> Date: Thu, 1 Mar 2012 14:51:47 -0500 Message-Id: References: <5816B9C7-7E7F-4BAE-BEED-C0E5E78749BB@qosient.com> <23042BBD-9F12-4D03-9853-75C26E4B324A@qosient.com> To: Juergen Quittek X-Mailer: Apple Mail (2.1257) Cc: Nevil Brownlee , Argus , IETF IPFIX Working Group Subject: Re: [IPFIX] recent ipfix drafts and argus X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 19:51:57 -0000 --Apple-Mail=_0669B83C-6049-4737-A512-D417BBBE6B29 Content-Type: multipart/alternative; boundary="Apple-Mail=_E78B6E0E-3CFD-41BE-8B23-B1A465FC57EB" --Apple-Mail=_E78B6E0E-3CFD-41BE-8B23-B1A465FC57EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 150 E. 57th Street Suite 12D New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax On Mar 1, 2012, at 12:16 PM, Carter Bullard wrote: > 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. >=20 > 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. >=20 > Carter >=20 > Carter Bullard > CEO/President > QoSient, LLC > 150 E. 57th Street Suite 12D > New York, New York 10022 >=20 > +1 212 588-9133 Phone > +1 212 588-9134 Fax >=20 >=20 >=20 > On Mar 1, 2012, at 11:36 AM, Carter Bullard wrote: >=20 >> 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. >>=20 >> I'm just the inventor, I suspect that Apple owns the patent now. >> You may want to talk to them. >>=20 >> Carter >>=20 >> Carter Bullard >> CEO/President >> QoSient, LLC >> 150 E. 57th Street Suite 12D >> New York, New York 10022 >>=20 >> +1 212 588-9133 Phone >> +1 212 588-9134 Fax >>=20 >>=20 >>=20 >> On Feb 29, 2012, at 4:41 PM, Juergen Quittek wrote: >>=20 >>> Hi Carter, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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? >>>=20 >>> Juergen=20 >>>=20 >>>=20 >>> On 29.02.12 17:38, "Carter Bullard" wrote: >>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> 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? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Carter >>>>=20 >>>> Carter Bullard >>>> CEO/President >>>> QoSient, LLC >>>> 150 E. 57th Street Suite 12D >>>> New York, New York 10022 >>>>=20 >>>> +1 212 588-9133 Phone >>>> +1 212 588-9134 Fax >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Feb 29, 2012, at 2:48 AM, Nevil Brownlee wrote: >>>>=20 >>>>=20 >>>>=20 >>>> Hi Carter: >>>>=20 >>>> As the other IPFIX co-chair I feel bound to respond to your = comments. >>>>=20 >>>> 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. >>>>=20 >>>> 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! >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Cheers, Nevil >>>>=20 >>>>=20 >>>> On 02/27/2012 11:37 AM, Carter Bullard wrote: >>>>=20 >>>> Gentle people, >>>>=20 >>>> I'm generally pretty quiet when it comes to IPFIX and its efforts. = But >>>> as the first >>>>=20 >>>> person to develop IP flow records in the 1980's, first to present = the >>>> idea to the >>>>=20 >>>> community in 1992, the first to provide open source flow technology = in >>>> 1995, >>>>=20 >>>> and the author of the longest lived open source flow system, argus; = I >>>> feel that >>>>=20 >>>> I have to say something about the recent wave of IPFIX drafts. >>>>=20 >>>>=20 >>>>=20 >>>> The drafts on flow aggregation describe functionality that the = Argus >>>> project started >>>>=20 >>>> over 20 years ago. The ideas of key modification, conversion of = non-key >>>> attributes >>>>=20 >>>> to key members, aggregation operators, interval distribution and = the >>>> architecture for it, >>>>=20 >>>> were all developed in argus a long long time ago. = draft-ietf-ipfix-a9n >>>> is basically >>>>=20 >>>> describing the functionality of argus's racluster(), rasplit(), and >>>> rabins() programs, >>>>=20 >>>> and every example given in the text of draft-ietf-ipfix-a9n can be >>>> generated using >>>>=20 >>>> argus's rabins(), with only a few gyrations of its command-line, = today. >>>>=20 >>>>=20 >>>>=20 >>>> I personally would expect that if the IETF was going to describe >>>> something that is >>>>=20 >>>> "Standards Track", that there would be dozen's of implementations = of this >>>> kind of >>>>=20 >>>> technology available, and that the WG is condensing years of = experience to >>>>=20 >>>> arrive at a "Standards Track", but, this is not the case. There is = only >>>> one current >>>>=20 >>>> implementation of the complete capabilities of the features of >>>> draft-ietf-ipfix-a9n >>>>=20 >>>> that I am aware of, and that is in argus. >>>>=20 >>>>=20 >>>>=20 >>>> Taking just one of the technical descriptions in the draft, = "interval >>>> distribution", I >>>>=20 >>>> am not aware of any description of this issue, or implementation of = this >>>> type >>>>=20 >>>> of technology in the literature, outside of argus. No Google = search >>>> results for "flow >>>>=20 >>>> interval distribution". In Argus we call it flow splitting. The = first >>>> line from a >>>>=20 >>>> Google search for "argus flow splitting" return: >>>>=20 >>>>=20 >>>>=20 >>>> Scholarly articles for argus flow splitting >>>>=20 >>>> =8A and prediction of flow statistics from sampled packet =8A - = Duffield - >>>> Cited by 217 >>>>=20 >>>>=20 >>>>=20 >>>> I'm not saying that Nick knows much about argus's support for flow >>>> splitting, but >>>>=20 >>>> its still pretty scary that the first hit is from a paper that is = used in >>>> IPFIX documents. >>>>=20 >>>> One would have to assume that the IPFIX community should be aware. >>>>=20 >>>>=20 >>>>=20 >>>> My problem is that most of draft-ietf-ipfix-a9n is prior work that = is >>>> not widely >>>>=20 >>>> implemented, some of the features are still unique to argus. = While IETF >>>> support >>>>=20 >>>> of technology is a good thing, descriptions of technology without >>>> reference >>>>=20 >>>> is a difficult thing to interpret. Is the IPFIX WG describing what = they >>>> think is new >>>>=20 >>>> technology? Does the IPFIX WG think that many companies have = implemented >>>>=20 >>>> this type of technology, and now its time to standardize it ? = Well, I'm >>>> not aware >>>>=20 >>>> of any implementation, open or closed, that does the complete set = of what >>>> the >>>>=20 >>>> draft is recommending, other than argus. So I don't think its new, = nor >>>> widely >>>>=20 >>>> implemented. I would say its a form of technology plagiarism. >>>>=20 >>>>=20 >>>>=20 >>>> IPFIX is considering adding non-IP flows to their definitions. = Argus is >>>> the only available >>>>=20 >>>> flow technology that has significant non-IP flow data models and = support. >>>> argus-1.2 had >>>>=20 >>>> flow generation, transport, analytics and storage of non-IP flows = 20 >>>> years ago, with its >>>>=20 >>>> support for bi-directional ethernet, apple-talk and ARP transaction >>>> tracking and reporting. >>>>=20 >>>> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, = and >>>> Infiniband flow >>>>=20 >>>> models. Not attributes, but true flow key elements. This work is >>>> non-trivial. >>>>=20 >>>>=20 >>>>=20 >>>> The concept that the WG would consider dropping the IP from IPFIX = and >>>> think that is >>>>=20 >>>> all that is needed, is really so completely wrong, that its = laughable, >>>> and a dis-service >>>>=20 >>>> to those that have done the hard work to bring situational = awareness and >>>> analytics >>>>=20 >>>> to non-IP traffic. The same applies to bi-directional flows, but = that >>>> is another story. >>>>=20 >>>>=20 >>>>=20 >>>> I would love to think that IPFIX could focus back on flow = information >>>> exchange. >>>>=20 >>>> Multicast, non-template based connectionless transport strategies, = say >>>> over UDT >>>>=20 >>>> as an example, rather than getting into areas for which the WG is >>>> unprepared to >>>>=20 >>>> do even a reasonable job, without resorting to dubious techniques. >>>>=20 >>>>=20 >>>>=20 >>>> Just a few comments, I hope that anyone finds it useful. >>>>=20 >>>>=20 >>>>=20 >>>> Carter >>>>=20 >>>>=20 >>>>=20 >>>> Carter Bullard >>>>=20 >>>> CEO/President >>>>=20 >>>> QoSient, LLC >>>>=20 >>>> 150 E. 57th Street Suite 12D >>>>=20 >>>> New York, New York 10022 >>>>=20 >>>>=20 >>>>=20 >>>> +1 212 588-9133 Phone >>>>=20 >>>> +1 212 588-9134 Fax >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> IPFIX mailing list >>>>=20 >>>> IPFIX@ietf.org >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> = --------------------------------------------------------------------- >>>> 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 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_E78B6E0E-3CFD-41BE-8B23-B1A465FC57EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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
150 E. 57th Street Suite = 12D
New York, New York = 10022

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



On Mar 1, 2012, at 12:16 PM, Carter Bullard = wrote:

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
150 E. 57th Street Suite = 12D
New York, New York 10022

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



On Mar 1, 2012, at 11:36 AM, Carter Bullard = wrote:

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" <carter@qosient.com> = 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

=8A = and prediction of flow statistics from sampled packet =8A - 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

IPFIX@ietf.org

https://www.ietf.org/= mailman/listinfo/ipfix




-- =
------------------------------------------------------------= ---------
Nevil = Brownlee =             &n= bsp;      Computer Science Department | = ITS
Phone: = +64 9 373 7599 x88941 =             Th= e University of = Auckland
FAX: = +64 9 373 7453   Private Bag 92019, Auckland 1142, New = Zealand











_______________________________________________
IPFIX mailing = list
IPFIX@ietf.org
https://www.ietf.org/= mailman/listinfo/ipfix


_______________________________________________
IPFIX mailing = list
IPFIX@ietf.org
https://www.ietf.org/= mailman/listinfo/ipfix

___________________________= ____________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/= mailman/listinfo/ipfix

= = --Apple-Mail=_E78B6E0E-3CFD-41BE-8B23-B1A465FC57EB-- --Apple-Mail=_0669B83C-6049-4737-A512-D417BBBE6B29 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2 uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwMTE5NTE0N1owIwYJKoZIhvcNAQkE MRYEFEqT80gt9ooYchY/8hRqFcXaH87qMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB AEOkAkhU0ayojL+GZrUbfxuKNUovdgfgqMSbodEf0nAf06oliAIzB55gM3SFjJR3H00NO4o/770V LVE7wXcNB/dGJsw3gA0sq62TdtmlpqPFjmIukxJu/gJvJw5K0fPL1f9BvQ6eq4rAKX1dEgyPCWKi g/3Ln1CgSx0bq/A7Ue3o3WQ17bnAc1mmaODeE/1D89vVYeO+1N8kRNABVrKtVprXFmur1s9BfpLN gGLAvNzLpqy3DoTHnXL/IqJM1nbPJy+FI60pmUZ2YrGUXe2WrQztUav5fA5caKAx72lmFLFxg3eg /CJ0Na2Jelh+7gboKyiesyMvT9d4vsNjZPOiAEEAAAAAAAA= --Apple-Mail=_0669B83C-6049-4737-A512-D417BBBE6B29-- From pashley@au1.ibm.com Thu Mar 1 15:04:05 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625E521E8248 for ; Thu, 1 Mar 2012 15:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOINKYoxME3U for ; Thu, 1 Mar 2012 15:04:04 -0800 (PST) Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) by ietfa.amsl.com (Postfix) with ESMTP id 392A921E823D for ; Thu, 1 Mar 2012 15:04:03 -0800 (PST) Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Mar 2012 22:58:27 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 1 Mar 2012 22:58:25 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q21Mw5ba3674360 for ; Fri, 2 Mar 2012 09:58:07 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q21N3buC021563 for ; Fri, 2 Mar 2012 10:03:37 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q21N3b3p021557 for ; Fri, 2 Mar 2012 10:03:37 +1100 Auto-Submitted: auto-generated From: Paul Ashley To: ipfix@ietf.org Message-ID: Date: Fri, 2 Mar 2012 10:07:42 +1100 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 02/03/2012 10:07:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12030112-0260-0000-0000-000000A23153 Subject: [IPFIX] AUTO: Paul Ashley is out of the office (returning 05/03/2012) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:04:05 -0000 I am out of the office until 05/03/2012. I am out of the office. I will have no access to my email. For ISS client issues, please email Andrew Sallaway (andrewms@au1.ibm.com) For ISS product development issues, please email John Court (johnwcrt@au1.ibm.com). For urgent issues, please send me a text message to 0421 611 853. Note: This is an automated response to your message "IPFIX Digest, Vol 63, Issue 1" sent on 2/3/2012 7:00:10. This is the only notification you will receive while this person is away. From paitken@cisco.com Thu Mar 1 15:07:15 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40E621E82D8 for ; Thu, 1 Mar 2012 15:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUvi7oBedpSK for ; Thu, 1 Mar 2012 15:07:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC921E8292 for ; Thu, 1 Mar 2012 15:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2558; q=dns/txt; s=iport; t=1330643234; x=1331852834; h=message-id:date:from:mime-version:to:cc:subject; bh=RTgfGDnnBIgbInQu2I/i3LhZOSXq5OoG4TaTfqn0h20=; b=ZFO4RSiHvyxN/ihprNK/NSFrFUI4k6SofsMGtdg5dEVR1aOZSWQn/iwx 6Ql9XwgjV781S1rQnSeFfeUMoBkyH8GhqJMVeEEl8nOYoitwFPxKVIGoV ID1eFT2aRy0xP6EVtHtrb7KU0yP7AxKurwmbzw8zO5J9VSTWvIVn0uyyO g=; X-IronPort-AV: E=Sophos;i="4.73,513,1325462400"; d="scan'208,217";a="131112009" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2012 23:07:08 +0000 Received: from [10.55.88.82] (dhcp-10-55-88-82.cisco.com [10.55.88.82]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q21N78r6022077; Thu, 1 Mar 2012 23:07:08 GMT Message-ID: <4F50011C.1020508@cisco.com> Date: Thu, 01 Mar 2012 23:07:08 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------060608070905070701090300" Cc: Nicholas Brown Subject: [IPFIX] IPFIX length fields X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:07:15 -0000 This is a multi-part message in MIME format. --------------060608070905070701090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics. However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier". We propose that these all be changed to no semantics. Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says, 3.2.1. quantity A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record.If no semantic qualifier is given, the Information Elements that have an integral data type should behave as a quantity. Feedback? Thanks, Paul and Nick --------------060608070905070701090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics.

However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier".

We propose that these all be changed to no semantics.

Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says,
3.2.1.  quantity

   A quantity value represents a discrete measured value pertaining to
   the record.  This is distinguished from counters that represent an
   ongoing measured value whose "odometer" reading is captured as part
   of a given record.  If no semantic qualifier is given, the
   Information Elements that have an integral data type should behave as
   a quantity.

Feedback?

Thanks,
Paul and Nick
--------------060608070905070701090300-- From trammell@tik.ee.ethz.ch Thu Mar 1 15:24:08 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E09D21E8369 for ; Thu, 1 Mar 2012 15:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.673 X-Spam-Level: X-Spam-Status: No, score=-6.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whMyEBaOhpJ2 for ; Thu, 1 Mar 2012 15:24:08 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F1A8E21E82D8 for ; Thu, 1 Mar 2012 15:24:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 56BC8D9310; Fri, 2 Mar 2012 00:24:05 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Z0Ck2n5ny-ZU; Fri, 2 Mar 2012 00:24:05 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id F3483D9304; Fri, 2 Mar 2012 00:24:04 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F50011C.1020508@cisco.com> Date: Fri, 2 Mar 2012 00:24:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> References: <4F50011C.1020508@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1257) Cc: Nicholas Brown , IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX length fields X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:24:08 -0000 Hi, Paul, Nick, It appears that "quantity" is applied a little haphazardly (indeed, = "observationTime*" has quantity semantics which doesn't seen quite = right), but that none of the IEs with explicit quantity semantics is a = length.=20 So in the interests of "make things internally consistent", I'd say that = these should be changed to no semantics. Does this indicate a need to clarify the applicability of quantity vs no = semantics in 5102bis? Cheers, Brian On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote: > Dear all, >=20 > Reviewing IANA's IPFIX field list, we noticed that most of the *length = fields have no semantics. >=20 > However, mplsTopLabelPrefixLength has semantics of "identifier", while = ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have = semantics of "identifier". >=20 > We propose that these all be changed to no semantics. >=20 > Or better, that all lengths be changed to semantics of "quantity", = since RFC5102 says, > 3.2.1. quantity >=20 > A quantity value represents a discrete measured value pertaining to > the record. This is distinguished from counters that represent an > ongoing measured value whose "odometer" reading is captured as part > of a given record. =20 > If no semantic qualifier is given, the > Information Elements that have an integral data type should behave = as > a quantity. >=20 >=20 > Feedback? >=20 > Thanks, > Paul and Nick > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Mar 1 15:52:54 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7D21E8132 for ; Thu, 1 Mar 2012 15:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8YNdpBIxp3k for ; Thu, 1 Mar 2012 15:52:54 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5C06A21E8108 for ; Thu, 1 Mar 2012 15:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=6163; q=dns/txt; s=iport; t=1330645973; x=1331855573; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=/pye1g56ThET0HqzM2MHVra04WMOMfd5kat3f+ankKw=; b=KVWLdqpIoBP6ukhYKC7yLapht4QV4UjQj0hm/xJ/eOP0deAV07MYjY7U stK1VnWTmFDfcyo31B8NLsfXA43QZOmHsnqGK3zdDd5VRAfMqfT78xNYH M2wLfsOw8Oh26arfIdVZ5fCF1QFNdsCegl/lrozmHHqmAaEo6an4kqiRN Q=; X-IronPort-AV: E=Sophos;i="4.73,514,1325462400"; d="scan'208,217";a="131113815" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2012 23:52:52 +0000 Received: from [10.55.88.82] (dhcp-10-55-88-82.cisco.com [10.55.88.82]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q21NqpEu010605; Thu, 1 Mar 2012 23:52:52 GMT Message-ID: <4F500BD3.8040007@cisco.com> Date: Thu, 01 Mar 2012 23:52:51 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: Brian Trammell References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> In-Reply-To: <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------010400030609090500070201" Cc: Nicholas Brown , IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX length fields X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:52:54 -0000 This is a multi-part message in MIME format. --------------010400030609090500070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > Hi, Paul, Nick, > > It appears that "quantity" is applied a little haphazardly (indeed, "observationTime*" has quantity semantics which doesn't seen quite right), but that none of the IEs with explicit quantity semantics is a length. > > So in the interests of "make things internally consistent", I'd say that these should be changed to no semantics. See my quote below from 5102 about no semantics == quantity. > Does this indicate a need to clarify the applicability of quantity vs no semantics in 5102bis? Yes, it seems so. Some other inconsistencies: Boolean may be an identifier, it can't be a quantity: 276 dataRecordsReliability boolean identifier 333 hashDigestOutput boolean quantity These all have no semantics. They should be "identifier": 44 sourceIPv4Prefix ipv4Address 45 destinationIPv4Prefix ipv4Address 169 destinationIPv6Prefix ipv6Address 170 sourceIPv6Prefix ipv6Address 281 postNATSourceIPv6Address ipv6Address 282 postNATDestinationIPv6Address ipv6Address P. > On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote: > >> Dear all, >> >> Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics. >> >> However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier". >> >> We propose that these all be changed to no semantics. >> >> Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says, >> 3.2.1. quantity >> >> A quantity value represents a discrete measured value pertaining to >> the record. This is distinguished from counters that represent an >> ongoing measured value whose "odometer" reading is captured as part >> of a given record. >> If no semantic qualifier is given, the >> Information Elements that have an integral data type should behave as >> a quantity. >> >> >> Feedback? >> >> Thanks, >> Paul and Nick >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------010400030609090500070201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Hi, Paul, Nick,

It appears that "quantity" is applied a little haphazardly (indeed, "observationTime*" has quantity semantics which doesn't seen quite right), but that none of the IEs with explicit quantity semantics is a length. 

So in the interests of "make things internally consistent", I'd say that these should be changed to no semantics.

See my quote below from 5102 about no semantics == quantity.


Does this indicate a need to clarify the applicability of quantity vs no semantics in 5102bis?

Yes, it seems so.


Some other inconsistencies:

Boolean may be an identifier, it can't be a quantity:

    276  dataRecordsReliability  boolean  identifier
    333  hashDigestOutput  boolean  quantity


These all have no semantics. They should be "identifier":

    44  sourceIPv4Prefix  ipv4Address
    45  destinationIPv4Prefix  ipv4Address

    169  destinationIPv6Prefix  ipv6Address
    170  sourceIPv6Prefix  ipv6Address
    281  postNATSourceIPv6Address  ipv6Address
    282  postNATDestinationIPv6Address  ipv6Address

P.

On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote:


Dear all,

Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics.

However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier".

We propose that these all be changed to no semantics.

Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says,
3.2.1.  quantity

   A quantity value represents a discrete measured value pertaining to
   the record.  This is distinguished from counters that represent an
   ongoing measured value whose "odometer" reading is captured as part
   of a given record.  
   If no semantic qualifier is given, the
   Information Elements that have an integral data type should behave as
   a quantity.


Feedback?

Thanks,
Paul and Nick
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

  


--------------010400030609090500070201--

From trammell@tik.ee.ethz.ch  Thu Mar  1 23:14:50 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358821F892B for ; Thu,  1 Mar 2012 23:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.37
X-Spam-Level: 
X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=-0.371,  BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZwJ15aQ4kWE for ; Thu,  1 Mar 2012 23:14:49 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13321F8952 for ; Thu,  1 Mar 2012 23:14:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5528FD94A0; Fri,  2 Mar 2012 08:14:48 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aEGuvaRoAMIc; Fri,  2 Mar 2012 08:14:48 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E9F93D949E; Fri,  2 Mar 2012 08:14:47 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Brian Trammell 
In-Reply-To: <4F500BD3.8040007@cisco.com>
Date: Fri, 2 Mar 2012 08:14:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> <4F500BD3.8040007@cisco.com>
To: Paul Aitken 
X-Mailer: Apple Mail (2.1257)
Cc: Nicholas Brown , IETF IPFIX Working Group 
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Mar 2012 07:14:50 -0000

Hi, Paul,

On Mar 2, 2012, at 12:52 AM, Paul Aitken wrote:

>> Does this indicate a need to clarify the applicability of quantity vs =
no semantics in 5102bis?
>>=20
>=20
> Yes, it seems so.

Would there be a problem simply with striking quantity completely, and =
noting what the meaning of "no semantics" is?

(Indeed, the meaning of "no semantics" is type-dependent. Addresses are =
always identifiers. Numbers are usually quantities. And so on.)

> Some other inconsistencies:
>=20
> Boolean may be an identifier, it can't be a quantity:
>=20
>     276  dataRecordsReliability  boolean  identifier
>     333  hashDigestOutput  boolean  quantity

Agreed on quantity. Not clear to me what a boolean identifier is. "This =
is the thing you're looking for!" "This is not the thing you're looking =
for"... dataRecordsReliability is a (single) flag, which is (or should =
be) the default semantics for boolean.

> These all have no semantics. They should be "identifier":
>=20
>     44  sourceIPv4Prefix  ipv4Address
>     45  destinationIPv4Prefix  ipv4Address
>=20
>     169  destinationIPv6Prefix  ipv6Address
>     170  sourceIPv6Prefix  ipv6Address
>     281  postNATSourceIPv6Address  ipv6Address
>     282  postNATDestinationIPv6Address  ipv6Address

As addresses are only ever identifiers, should these not be no =
semantics?

RFC 5610 has a section 3.10 on restrictions in export of semantics per =
data type; this was extracted from (a subset of) the Information Element =
registry at the time (note that "default" here is the description of the =
codepoint for "no semantics")

3.10.  Data Type and Semantics Restrictions

   Note that the informationElementSemantics values defined in Section
   3.2 of [RFC5102] are primarily intended to differentiate semantic
   interpretation of numeric values, and that not all combinations of
   the informationElementDataType and informationElementSemantics
   Information Elements are valid; e.g., a counter cannot be encoded as
   an IPv4 address.  The following are acceptable values of
   informationElementSemantics:

   o  Any value is valid for unsigned informationElementDataType values
      ("unsigned8", "unsigned16", "unsigned32", or "unsigned64").

   o  Any value except "flags" is valid for signed
      informationElementDataType values ("signed8", "signed16",
      "signed32", or "signed64").

   o  Any value except "identifier" or "flags" is valid for floating-
      point informationElementDataType values ("float32" or "float64").

   o  Only "default" is valid for all other informationElementDataType
      values ("octetArray", "boolean", "macAddress", "string",
      "dateTimeSeconds", "dateTimeMilliseconds", "dateTimeMicroseconds",
      "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").

In the interests of self-consistency, I would suggest that cleanup =
should follow those guidelines, or the guidelines themselves should be =
updated by an erratum and/or moved into 5102bis and updated there.

Cheers,

Brian

>> On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote:
>>=20
>>=20
>>> Dear all,
>>>=20
>>> Reviewing IANA's IPFIX field list, we noticed that most of the =
*length fields have no semantics.
>>>=20
>>> However, mplsTopLabelPrefixLength has semantics of "identifier", =
while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength =
have semantics of "identifier".
>>>=20
>>> We propose that these all be changed to no semantics.
>>>=20
>>> Or better, that all lengths be changed to semantics of "quantity", =
since RFC5102 says,
>>> 3.2.1.  quantity
>>>=20
>>>    A quantity value represents a discrete measured value pertaining =
to
>>>    the record.  This is distinguished from counters that represent =
an
>>>    ongoing measured value whose "odometer" reading is captured as =
part
>>>    of a given record. =20
>>>=20
>>>    If no semantic qualifier is given, the
>>>    Information Elements that have an integral data type should =
behave as
>>>    a quantity.
>>>=20
>>>=20
>>>=20
>>> Feedback?
>>>=20
>>> Thanks,
>>> Paul and Nick
>>> _______________________________________________
>>> IPFIX mailing list
>>>=20
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>=20


From paitken@cisco.com  Fri Mar  2 01:51:00 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B274C21F8B21 for ; Fri,  2 Mar 2012 01:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.215
X-Spam-Level: 
X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X10VFcQb6+rz for ; Fri,  2 Mar 2012 01:50:59 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EF4C721F8B0F for ; Fri,  2 Mar 2012 01:50:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=5130; q=dns/txt; s=iport; t=1330681859; x=1331891459; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gcV4KDt28DQaeGVUiaGnthX+X6DiVjuUrlvGzVlWtsI=; b=aewzLnnc6sVOgXMMzYveldt3JRJ3nD1L8J6c66yYAMc18rUDkL+fa/GJ MmFJR+bZtmqsda2kKrjDZ6ni5YUaxd9uqIWPwA6aYF3ko8OVsNmOSnqPk bW2L8pB9vxMKbRwEmSOqmbnWDrtULBNayBquHINH3XH6h8um79Rj79MAT c=;
X-IronPort-AV: E=Sophos;i="4.73,517,1325462400"; d="scan'208";a="67521803"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Mar 2012 09:50:57 +0000
Received: from [10.55.88.82] (dhcp-10-55-88-82.cisco.com [10.55.88.82]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q229ovHf020222; Fri, 2 Mar 2012 09:50:57 GMT
Message-ID: <4F509802.3070202@cisco.com>
Date: Fri, 02 Mar 2012 09:50:58 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: Brian Trammell 
References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> <4F500BD3.8040007@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Nicholas Brown , IETF IPFIX Working Group 
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Mar 2012 09:51:00 -0000

Brian,

> Hi, Paul,
>
> On Mar 2, 2012, at 12:52 AM, Paul Aitken wrote:
>
>>> Does this indicate a need to clarify the applicability of quantity vs no semantics in 5102bis?
>>>
>> Yes, it seems so.
> Would there be a problem simply with striking quantity completely, and noting what the meaning of "no semantics" is?
>
> (Indeed, the meaning of "no semantics" is type-dependent. Addresses are always identifiers. Numbers are usually quantities. And so on.)

Rather than leave the semantics blank, with a hidden note elsewhere 
about what that means, we should aim to give semantics for each IE.


>> Some other inconsistencies:
>>
>> Boolean may be an identifier, it can't be a quantity:
>>
>>      276  dataRecordsReliability  boolean  identifier
>>      333  hashDigestOutput  boolean  quantity
> Agreed on quantity. Not clear to me what a boolean identifier is. "This is the thing you're looking for!" "This is not the thing you're looking for"... dataRecordsReliability is a (single) flag, which is (or should be) the default semantics for boolean.

I convinced myself that it's a True / False identifier.
In this specific case, it identifies whether or not data records are 
reliable.

"Quantity" suggests, "Yes, there is some hashDigestOutput" ??


>> These all have no semantics. They should be "identifier":
>>
>>      44  sourceIPv4Prefix  ipv4Address
>>      45  destinationIPv4Prefix  ipv4Address
>>
>>      169  destinationIPv6Prefix  ipv6Address
>>      170  sourceIPv6Prefix  ipv6Address
>>      281  postNATSourceIPv6Address  ipv6Address
>>      282  postNATDestinationIPv6Address  ipv6Address
> As addresses are only ever identifiers, should these not be no semantics?

No, they should say "identifier".

Else you're expecting the registry reader to understand that no 
semantics (an empty box) also has a meaning, and check the RFCs to 
discover what it is.


> RFC 5610 has a section 3.10 on restrictions in export of semantics per data type; this was extracted from (a subset of) the Information Element registry at the time (note that "default" here is the description of the codepoint for "no semantics")

Then perhaps the registry should say "default" rather than having a 
blank box - though it would be better to explicitly state the default 
for each.


> 3.10.  Data Type and Semantics Restrictions
>
>     Note that the informationElementSemantics values defined in Section
>     3.2 of [RFC5102] are primarily intended to differentiate semantic
>     interpretation of numeric values, and that not all combinations of
>     the informationElementDataType and informationElementSemantics
>     Information Elements are valid; e.g., a counter cannot be encoded as
>     an IPv4 address.  The following are acceptable values of
>     informationElementSemantics:
>
>     o  Any value is valid for unsigned informationElementDataType values
>        ("unsigned8", "unsigned16", "unsigned32", or "unsigned64").
>
>     o  Any value except "flags" is valid for signed
>        informationElementDataType values ("signed8", "signed16",
>        "signed32", or "signed64").
>
>     o  Any value except "identifier" or "flags" is valid for floating-
>        point informationElementDataType values ("float32" or "float64").
>
>     o  Only "default" is valid for all other informationElementDataType
>        values ("octetArray", "boolean", "macAddress", "string",
>        "dateTimeSeconds", "dateTimeMilliseconds", "dateTimeMicroseconds",
>        "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").

When you say, "any value", you're assuming that no new semantics are added.


> In the interests of self-consistency, I would suggest that cleanup should follow those guidelines, or the guidelines themselves should be updated by an erratum and/or moved into 5102bis and updated there.

Thanks,
P.


>>> On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote:
>>>
>>>
>>>> Dear all,
>>>>
>>>> Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics.
>>>>
>>>> However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier".
>>>>
>>>> We propose that these all be changed to no semantics.
>>>>
>>>> Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says,
>>>> 3.2.1.  quantity
>>>>
>>>>     A quantity value represents a discrete measured value pertaining to
>>>>     the record.  This is distinguished from counters that represent an
>>>>     ongoing measured value whose "odometer" reading is captured as part
>>>>     of a given record.
>>>>
>>>>     If no semantic qualifier is given, the
>>>>     Information Elements that have an integral data type should behave as
>>>>     a quantity.
>>>>
>>>>
>>>>
>>>> Feedback?
>>>>
>>>> Thanks,
>>>> Paul and Nick
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>>
>>>> IPFIX@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipfix


From trammell@tik.ee.ethz.ch  Fri Mar  2 04:22:58 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E127621F8B8F for ; Fri,  2 Mar 2012 04:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.239
X-Spam-Level: 
X-Spam-Status: No, score=-5.239 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhTW8F6CgoE1 for ; Fri,  2 Mar 2012 04:22:58 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB4A21F8B8D for ; Fri,  2 Mar 2012 04:22:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E41DAD930C; Fri,  2 Mar 2012 13:22:56 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F-nudL+EjWoX; Fri,  2 Mar 2012 13:22:56 +0100 (MET)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7FC12D9304; Fri,  2 Mar 2012 13:22:56 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Brian Trammell 
In-Reply-To: <4F509802.3070202@cisco.com>
Date: Fri, 2 Mar 2012 13:22:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> <4F500BD3.8040007@cisco.com>  <4F509802.3070202@cisco.com>
To: Paul Aitken 
X-Mailer: Apple Mail (2.1257)
Cc: Nicholas Brown , IETF IPFIX Working Group 
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Mar 2012 12:22:59 -0000

On Mar 2, 2012, at 10:50 AM, Paul Aitken wrote:

> Brian,
>=20
>> Hi, Paul,
>>=20
>> On Mar 2, 2012, at 12:52 AM, Paul Aitken wrote:
>>=20
>>>> Does this indicate a need to clarify the applicability of quantity =
vs no semantics in 5102bis?
>>>>=20
>>> Yes, it seems so.
>> Would there be a problem simply with striking quantity completely, =
and noting what the meaning of "no semantics" is?
>>=20
>> (Indeed, the meaning of "no semantics" is type-dependent. Addresses =
are always identifiers. Numbers are usually quantities. And so on.)
>=20
> Rather than leave the semantics blank, with a hidden note elsewhere =
about what that means, we should aim to give semantics for each IE.

Okay. So let's figure out how we want to express that then update the =
registry.

>>> Some other inconsistencies:
>>>=20
>>> Boolean may be an identifier, it can't be a quantity:
>>>=20
>>>     276  dataRecordsReliability  boolean  identifier
>>>     333  hashDigestOutput  boolean  quantity
>> Agreed on quantity. Not clear to me what a boolean identifier is. =
"This is the thing you're looking for!" "This is not the thing you're =
looking for"... dataRecordsReliability is a (single) flag, which is (or =
should be) the default semantics for boolean.
>=20
> I convinced myself that it's a True / False identifier.
> In this specific case, it identifies whether or not data records are =
reliable.

I'd read that as "this is the reliable record." Fits the definition of =
"identifier" if that definition is a little stretchy.

> "Quantity" suggests, "Yes, there is some hashDigestOutput" ??

"Quantity" suggests a typographical error IMO.

>>> These all have no semantics. They should be "identifier":
>>>=20
>>>     44  sourceIPv4Prefix  ipv4Address
>>>     45  destinationIPv4Prefix  ipv4Address
>>>=20
>>>     169  destinationIPv6Prefix  ipv6Address
>>>     170  sourceIPv6Prefix  ipv6Address
>>>     281  postNATSourceIPv6Address  ipv6Address
>>>     282  postNATDestinationIPv6Address  ipv6Address
>> As addresses are only ever identifiers, should these not be no =
semantics?
>=20
> No, they should say "identifier".
>=20
> Else you're expecting the registry reader to understand that no =
semantics (an empty box) also has a meaning, and check the RFCs to =
discover what it is.

Good point. That wouldn't particularly make things easier.

>> RFC 5610 has a section 3.10 on restrictions in export of semantics =
per data type; this was extracted from (a subset of) the Information =
Element registry at the time (note that "default" here is the =
description of the codepoint for "no semantics")
>=20
> Then perhaps the registry should say "default" rather than having a =
blank box - though it would be better to explicitly state the default =
for each.

Absolutely. This belongs in 5102bis, I think.=20

>> 3.10.  Data Type and Semantics Restrictions
>>=20
>>    Note that the informationElementSemantics values defined in =
Section
>>    3.2 of [RFC5102] are primarily intended to differentiate semantic
>>    interpretation of numeric values, and that not all combinations of
>>    the informationElementDataType and informationElementSemantics
>>    Information Elements are valid; e.g., a counter cannot be encoded =
as
>>    an IPv4 address.  The following are acceptable values of
>>    informationElementSemantics:
>>=20
>>    o  Any value is valid for unsigned informationElementDataType =
values
>>       ("unsigned8", "unsigned16", "unsigned32", or "unsigned64").
>>=20
>>    o  Any value except "flags" is valid for signed
>>       informationElementDataType values ("signed8", "signed16",
>>       "signed32", or "signed64").
>>=20
>>    o  Any value except "identifier" or "flags" is valid for floating-
>>       point informationElementDataType values ("float32" or =
"float64").
>>=20
>>    o  Only "default" is valid for all other =
informationElementDataType
>>       values ("octetArray", "boolean", "macAddress", "string",
>>       "dateTimeSeconds", "dateTimeMilliseconds", =
"dateTimeMicroseconds",
>>       "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").
>=20
> When you say, "any value", you're assuming that no new semantics are =
added.

Sorry, I cut the last part of the section, which says:

   Future Standards Actions that modify the Information Element Data
   Type subregistry or the Information Element Semantics subregistry
   should contain a Data Type and Semantics Restrictions section such as
   this one to define allowable combinations of type and semantics
   information.

However, that's not quite restrictive enough, because it also assumes no =
new types are added. (I personally think that semantics are more likely =
to be added than types, but we should be thorough.)

Shall I add this as an open issue on 5102bis?

Cheers,

Brian

>>>> On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote:
>>>>=20
>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> Reviewing IANA's IPFIX field list, we noticed that most of the =
*length fields have no semantics.
>>>>>=20
>>>>> However, mplsTopLabelPrefixLength has semantics of "identifier", =
while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength =
have semantics of "identifier".
>>>>>=20
>>>>> We propose that these all be changed to no semantics.
>>>>>=20
>>>>> Or better, that all lengths be changed to semantics of "quantity", =
since RFC5102 says,
>>>>> 3.2.1.  quantity
>>>>>=20
>>>>>    A quantity value represents a discrete measured value =
pertaining to
>>>>>    the record.  This is distinguished from counters that represent =
an
>>>>>    ongoing measured value whose "odometer" reading is captured as =
part
>>>>>    of a given record.
>>>>>=20
>>>>>    If no semantic qualifier is given, the
>>>>>    Information Elements that have an integral data type should =
behave as
>>>>>    a quantity.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Feedback?
>>>>>=20
>>>>> Thanks,
>>>>> Paul and Nick
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>>=20
>>>>> IPFIX@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipfix


From paitken@cisco.com  Fri Mar  2 04:32:22 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464FE21F8BAB for ; Fri,  2 Mar 2012 04:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.503
X-Spam-Level: 
X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdj5WytxbjBu for ; Fri,  2 Mar 2012 04:32:21 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFC21F8BA5 for ; Fri,  2 Mar 2012 04:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=152; q=dns/txt; s=iport; t=1330691541; x=1331901141; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4p8TK0Qa08w20MeQOj7GMry/nivjhS1CDJPN0A9cyfc=; b=c9PEsHJAA3fQANvAbPBgNS564LySTB/CYKCM+3O8r4VnjP9oRc6ETG77 r0lqBXuzJqMx3Oqq8jQ5ojJleTk5KXID9MJMRxeyJWaYE2zf+IfRDvTEW k2H+kVke1FMQJbMtcKWRFXbd4StNGfsdgJzR9NnDiVqG+RlmSfptTOQ6O E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAIAMy8UE+Q/khM/2dsb2JhbABDgwexIYEHgX0BAQEDARIBJUEFCwshJQ8CRgYNAQcBAR6HXwWbMwGefY9kBJU9hV+NFA
X-IronPort-AV: E=Sophos;i="4.73,517,1325462400"; d="scan'208";a="131161413"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2012 12:32:20 +0000
Received: from [10.55.88.82] (dhcp-10-55-88-82.cisco.com [10.55.88.82]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q22CWJnL020586; Fri, 2 Mar 2012 12:32:19 GMT
Message-ID: <4F50BDD4.60108@cisco.com>
Date: Fri, 02 Mar 2012 12:32:20 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: Brian Trammell 
References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> <4F500BD3.8040007@cisco.com>  <4F509802.3070202@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Mar 2012 12:32:22 -0000

Brian,

...

> Shall I add this as an open issue on 5102bis?

Yes, please list the issues.

We can discuss them in Paris, if not sooner.

P.

From Quittek@neclab.eu  Fri Mar  2 05:25:54 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC13721F89EB for ; Fri,  2 Mar 2012 05:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.181
X-Spam-Level: 
X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yavPwliBaNwa for ; Fri,  2 Mar 2012 05:25:54 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0187321F89E8 for ; Fri,  2 Mar 2012 05:25:54 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4E08828000207; Fri,  2 Mar 2012 14:25:53 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6Ey0q0wqx7V; Fri,  2 Mar 2012 14:25:53 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 28561280001D9; Fri,  2 Mar 2012 14:25:33 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 2 Mar 2012 14:25:33 +0100
From: Juergen Quittek 
To: Paul Aitken , Brian Trammell 
Thread-Topic: [IPFIX] IPFIX length fields
Thread-Index: AQHM+HfxVRuWEyLHUEKwBWT8PYiZjg==
Date: Fri, 2 Mar 2012 13:25:32 +0000
Message-ID: 
In-Reply-To: <4F500BD3.8040007@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Nicholas Brown , IETF IPFIX Working Group 
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Mar 2012 13:25:54 -0000

Hi all,

I agree that we should remove "quantity" from the observationTime* IEs.

Saying this, I am aware that these indeed are quantities specifying
the number of nano/micro/milliseconds since a given point in time.

But their semantics is sufficiently specified by their type.
The semantics of "quantity" does not add to clarifying its semantics.
That's why it rather should be removed.

Thanks,
    Juergen

On 02.03.12 00:52, "Paul Aitken"  wrote:

>
> =20
> =20
>    Brian,
>   =20
>   =20
>      Hi, Paul, Nick,
>
>It appears that "quantity" is applied a little haphazardly (indeed,
>"observationTime*" has quantity semantics which doesn't seen quite
>right), but that none of the IEs with explicit quantity semantics is a
>length.=20
>
>So in the interests of "make things internally consistent", I'd say that
>these should be changed to no semantics.
>
>   =20
>
>   =20
>    See my quote below from 5102 about no semantics =3D=3D quantity.
>   =20
>   =20
>   =20
>      Does this indicate a need to clarify the applicability of quantity
>vs no semantics in 5102bis?
>
>   =20
>
>   =20
>    Yes, it seems so.
>   =20
>   =20
>    Some other inconsistencies:
>   =20
>    Boolean may be an identifier, it can't be a quantity:
>   =20
>        276  dataRecordsReliability  boolean  identifier
>        333  hashDigestOutput  boolean  quantity
>   =20
>   =20
>    These all have no semantics. They should be "identifier":
>   =20
>        44  sourceIPv4Prefix  ipv4Address
>        45  destinationIPv4Prefix  ipv4Address
>   =20
>        169  destinationIPv6Prefix  ipv6Address
>        170  sourceIPv6Prefix  ipv6Address
>        281  postNATSourceIPv6Address  ipv6Address
>        282  postNATDestinationIPv6Address  ipv6Address
>   =20
>    P.
>   =20
>   =20
>      On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote:
>
>
>     =20
>        Dear all,
>
>Reviewing IANA's IPFIX field list, we noticed that most of the *length
>fields have no semantics.
>
>However, mplsTopLabelPrefixLength has semantics of "identifier", while
>ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have
>semantics of "identifier".
>
>We propose that these all be changed to no semantics.
>
>Or better, that all lengths be changed to semantics of "quantity", since
>RFC5102 says,
>3.2.1.  quantity
>
>   A quantity value represents a discrete measured value pertaining to
>   the record.  This is distinguished from counters that represent an
>   ongoing measured value whose "odometer" reading is captured as part
>   of a given record.
>   If no semantic qualifier is given, the
>   Information Elements that have an integral data type should behave as
>   a quantity.
>
>
>Feedback?
>
>Thanks,
>Paul and Nick
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>     =20
>
>     =20
>   =20
>
>   =20
> =20
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www.ietf.org/mailman/listinfo/ipfix


From andrewf@plixer.com  Mon Mar  5 13:43:07 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2B21F88C0 for ; Mon,  5 Mar 2012 13:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scxRttRSTazV for ; Mon,  5 Mar 2012 13:43:06 -0800 (PST)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 61E0A21F88BC for ; Mon,  5 Mar 2012 13:43:06 -0800 (PST)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Mar 2012 16:43:05 -0500
Message-ID: <4F553368.4070209@plixer.com>
Date: Mon, 05 Mar 2012 16:43:04 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120229 Thunderbird/13.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> <4F500BD3.8040007@cisco.com>  <4F509802.3070202@cisco.com>
In-Reply-To: <4F509802.3070202@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Mar 2012 21:43:05.0067 (UTC) FILETIME=[F259F3B0:01CCFB18]
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Mar 2012 21:43:07 -0000

On 03/02/2012 04:50 AM, Paul Aitken wrote:
> Brian,
>
>> Hi, Paul,
>>
>> On Mar 2, 2012, at 12:52 AM, Paul Aitken wrote:
>>
>>>> Does this indicate a need to clarify the applicability of quantity 
>>>> vs no semantics in 5102bis?
>>>>
>>> Yes, it seems so.
>> Would there be a problem simply with striking quantity completely, 
>> and noting what the meaning of "no semantics" is?
>>
>> (Indeed, the meaning of "no semantics" is type-dependent. Addresses 
>> are always identifiers. Numbers are usually quantities. And so on.)
>
> Rather than leave the semantics blank, with a hidden note elsewhere 
> about what that means, we should aim to give semantics for each IE.

Agreed.  If the semantics can be stated they should.


From andrewf@plixer.com  Mon Mar  5 15:01:01 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86B221E802B for ; Mon,  5 Mar 2012 15:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level: 
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWHupA2GED0U for ; Mon,  5 Mar 2012 15:01:01 -0800 (PST)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9A21E8028 for ; Mon,  5 Mar 2012 15:01:00 -0800 (PST)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Mar 2012 18:01:00 -0500
Message-ID: <4F5545AC.10307@plixer.com>
Date: Mon, 05 Mar 2012 18:01:00 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120229 Thunderbird/13.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <20120210155814.20182.97887.idtracker@ietfa.amsl.com> <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch>
In-Reply-To: <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Mar 2012 23:01:00.0390 (UTC) FILETIME=[D50FA060:01CCFB23]
Subject: Re: [IPFIX] Fwd:  I-D Action: draft-ietf-ipfix-ie-doctors-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Mar 2012 23:01:02 -0000

Hi Brian, all,

I gave this quick second read.  Other than the minor spelling and 
similar issues that I sent off list before last call this looks good.

-Andrew

On 02/10/2012 11:00 AM, Brian Trammell wrote:
> Hi, Nevil, all,
>
> Rev -01 of the ie-doctors draft is now available; this contains the final pending edits, and this revision is ready for WGLC.
>
> Many thanks, best regards,
>
> Brian
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-01.txt
>> Date: February 10, 2012 4:58:14 PM GMT+01:00
>> To: i-d-announce@ietf.org
>> Cc: ipfix@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF.
>>
>> 	Title           : Guidelines for Authors and Reviewers of IPFIX Information Elements
>> 	Author(s)       : Brian Trammell
>>                           Benoit Claise
>> 	Filename        : draft-ietf-ipfix-ie-doctors-01.txt
>> 	Pages           : 33
>> 	Date            : 2012-02-10
>>
>>    This document provides guidelines for the definition of IPFIX
>>    Information Elements for addition to the IANA IPFIX Information
>>    Element registry, in order to extend the applicability of the IPFIX
>>    protocol to new operations and management areas.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From trammell@tik.ee.ethz.ch  Mon Mar  5 22:56:12 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC2921E807C for ; Mon,  5 Mar 2012 22:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.658
X-Spam-Level: 
X-Spam-Status: No, score=-6.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5v6riClbcrS for ; Mon,  5 Mar 2012 22:56:11 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F021E805A for ; Mon,  5 Mar 2012 22:56:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7D5C3D9312; Tue,  6 Mar 2012 07:56:09 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rrK3u-3hUbNq; Tue,  6 Mar 2012 07:56:09 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3BA79D930D; Tue,  6 Mar 2012 07:56:09 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <4F5545AC.10307@plixer.com>
Date: Tue, 6 Mar 2012 07:56:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AE13AAD-7E11-450A-A6F5-AF6E15FC0876@tik.ee.ethz.ch>
References: <20120210155814.20182.97887.idtracker@ietfa.amsl.com> <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch> <4F5545AC.10307@plixer.com>
To: Andrew Feren 
X-Mailer: Apple Mail (2.1257)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Fwd:  I-D Action: draft-ietf-ipfix-ie-doctors-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 06:56:12 -0000

Hi, Andrew,

Many thanks for your review! (These issues have been fixed in a working =
draft to be submitted before the -01 deadline for Paris.)

Cheers,

Brian

On Mar 6, 2012, at 12:01 AM, Andrew Feren wrote:

> Hi Brian, all,
>=20
> I gave this quick second read.  Other than the minor spelling and =
similar issues that I sent off list before last call this looks good.
>=20
> -Andrew
>=20
> On 02/10/2012 11:00 AM, Brian Trammell wrote:
>> Hi, Nevil, all,
>>=20
>> Rev -01 of the ie-doctors draft is now available; this contains the =
final pending edits, and this revision is ready for WGLC.
>>=20
>> Many thanks, best regards,
>>=20
>> Brian
>>=20
>> Begin forwarded message:
>>=20
>>> From: internet-drafts@ietf.org
>>> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-01.txt
>>> Date: February 10, 2012 4:58:14 PM GMT+01:00
>>> To: i-d-announce@ietf.org
>>> Cc: ipfix@ietf.org
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the IP Flow Information Export =
Working Group of the IETF.
>>>=20
>>> 	Title           : Guidelines for Authors and Reviewers of IPFIX =
Information Elements
>>> 	Author(s)       : Brian Trammell
>>>                          Benoit Claise
>>> 	Filename        : draft-ietf-ipfix-ie-doctors-01.txt
>>> 	Pages           : 33
>>> 	Date            : 2012-02-10
>>>=20
>>>   This document provides guidelines for the definition of IPFIX
>>>   Information Elements for addition to the IANA IPFIX Information
>>>   Element registry, in order to extend the applicability of the =
IPFIX
>>>   protocol to new operations and management areas.
>>>=20
>>>=20
>>> A URL for this Internet-Draft is:
>>> =
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> This Internet-Draft can be retrieved at:
>>> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt
>>>=20
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From internet-drafts@ietf.org  Tue Mar  6 07:38:40 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7760321F8987; Tue,  6 Mar 2012 07:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrH7CR+MTI9m; Tue,  6 Mar 2012 07:38:39 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1A21F87A0; Tue,  6 Mar 2012 07:38:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120306153839.18402.74949.idtracker@ietfa.amsl.com>
Date: Tue, 06 Mar 2012 07:38:39 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-10.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 15:38:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Flow Selection Techniques
	Author(s)       : Salvatore D'Antonio
                          Tanja Zseby
                          Christian Henke
                          Lorenzo Peluso
	Filename        : draft-ietf-ipfix-flow-selection-tech-10.txt
	Pages           : 35
	Date            : 2012-03-06

   Flow selection is the process of selecting a subset of flows from all
   observed flows.  The Flow Selection Process may be located at an
   observation point, or on an IPFIX Mediator.  Flow selection reduces
   the effort of post-processing flow data and transferring Flow
   Records.  This document describes motivations for flow selection and
   presents flow selection techniques.  It provides an information model
   for configuring flow selection techniques and discusses what
   information about a flow selection process should be exported.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-10=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-10.=
txt


From salvatore.dantonio@uniparthenope.it  Tue Mar  6 07:46:35 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A950021F89A6 for ; Tue,  6 Mar 2012 07:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.682
X-Spam-Level: **
X-Spam-Status: No, score=2.682 tagged_above=-999 required=5 tests=[AWL=0.463,  BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk5N-I0LuIQr for ; Tue,  6 Mar 2012 07:46:34 -0800 (PST)
Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 3D83C21F89A0 for ; Tue,  6 Mar 2012 07:46:34 -0800 (PST)
Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id C1114148BC; Tue,  6 Mar 2012 15:46:32 +0000 (UTC)
Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d2d_8c111ece_67a3_11e1_a0f7_001372515a5c; Tue, 06 Mar 2012 16:46:32 +0100
Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 57E49C42EE; Tue,  6 Mar 2012 17:44:04 +0100 (CET)
Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 542ECC432D; Tue,  6 Mar 2012 17:44:04 +0100 (CET)
Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id EB78CC42EF; Tue,  6 Mar 2012 17:43:39 +0100 (CET)
Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 91A56148BC; Tue,  6 Mar 2012 16:46:07 +0100 (CET)
From: "Salvatore D'Antonio" 
To: "'Nevil Brownlee'" 
References: <4EC5C8A4.1040104@auckland.ac.nz> <4EC5E307.8080203@auckland.ac.nz> <003201ccdf47$f3f9fae0$dbedf0a0$@dantonio@uniparthenope.it> <4F29092D.5090003@auckland.ac.nz> <003201cce4ed$cd2f8f50$678eadf0$@dantonio@uniparthenope.it> <4F3FAC7F.8090408@auckland.ac.nz>
In-Reply-To: <4F3FAC7F.8090408@auckland.ac.nz>
Date: Tue, 6 Mar 2012 16:46:09 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AczuRFNSqGb+VsZmQSeig5qcp5MzjANWbSyA
Content-Language: it
Message-ID: <003301ccfbb0$401ed4c0$c05c7e40$@dantonio@uniparthenope.it>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20120306 #7178046, check: 20120306 clean
Cc: lorenzo.peluso@fokus.fraunhofer.de, christian.henke@tektronix.com, 'Tanja Zseby' , 'IPFIX list' 
Subject: [IPFIX] R: Flow Selection Techniques draft - remaining issues
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 15:46:35 -0000

Dear Nevil, all

The new version of the Draft on Flow Selection Techniques has been =
published
and available at=20

http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-=
10.
txt

I have modified the section on Property Match Filtering, added the =
sentence
(proposed by Nevil) on the IPR issue to the section on Flow filtering,
updated the References according to Brian=92s comment on normative and
informative RFC, fixed the capitalization of the Information Elements,  =
and
defined samplingFlowInterval, samplingFlowSpace, =
flowSamplingTimeInterval
and flowSamplingTimeSpace as unsigned64, instead of unsigned32, =
according to
Brian=92s comment.

Looking forward to your feedback.

Best regards,


Salvatore



-----Messaggio originale-----
Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz]=20
Inviato: sabato 18 febbraio 2012 14:50
A: Salvatore D'Antonio
Cc: Tanja Zseby; Henke, Christian; lorenzo.peluso@fokus.fraunhofer.de; =
IPFIX
list
Oggetto: Re: Flow Selection Techniques draft - remaining issues


Hi Salvatore et al:

The WGLC for the Selection Techniques draft finished last Wednesday, =
with
one review from Brian Trammel.

Brian felt the the Property Match Filtering section "seems pretty =
anaemic,"
but I see that section refers to RFC 5475. However 5475 seems to define =
it
as "A packet is selected if a specific field in the packet equals a
predefined value;" Brian wants to use a set of values for several =
fields,
which sounds a lot like using a template to select flows.  Could you add
a paragraph to the Property Match Filter section, please, pointing out
that using sets of fields/values to select flows is possible, preferable
with an example to make it clear?

My only other concern is the IPR question, we have consensus that making
all the filtering methods optional would be OK.  To do that, 5475 says
"In order to be compliant with PSAMP, at least one of proposed schemes =
MUST
be implemented." so that would be OK with 'this document' instead of
'PSAMP.'

Another possibility, which I've just thought of, and I think I like =
better,
would be to say "In order to be compliant with this document, at least
the Property Match Filtering MUST be implemented."  Which of these two
sentences do you think would be best?

With these two issues fixed, I believe we'd have WG consensus (at last)!

Cheers, Nevil



On 02/06/2012 08:38 AM, Salvatore D'Antonio wrote:
> Dear Nevil,
>
> In section 5.2.2 of the Draft we reference to the size-dependent =
sampling
> mechanism presented in Nick Duffield's paper "Charging from Sampled
Network
> Usage" as a possible method for flow record selection. Since patent n.
> 7080136 "Method and apparatus for size-dependent sampling for managing =
a
> data network" is on this sampling mechanism, we added an IPR =
disclosure
from
> AT&T on this. The IPR disclosure is related to version -05 of the =
Draft.
> Other techniques/algorithms are presented in the Draft, but as far as =
I
know
> they are not covered by patents. My feeling is that there is no need =
for
> other IPR disclosures.
> Anyways, to remove any doubts, we might add a definite statement on =
the
> optional use of such techniques for an implementor.
>
> What do you think?
>
> Kind regards,
>
> Salvatore
>
>
>
>
> -----Messaggio originale-----
> Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz]
> Inviato: mercoled=EC 1 febbraio 2012 10:43
> A: Salvatore D'Antonio
> Cc: tanja.zseby@fokus.fraunhofer.de; Nevil Brownlee
> Oggetto: Re: R: [IPFIX] DRAFT minutes for Thursday's IPFIX meeting
>
>
> Hi Salvatore&  Tanja:
>
> Thanks for your email; I'm now on sabbatical leave in Norway, so I =
have
> more time free to catch up on IPFIX - you'll have seen my note to the =
list
> about the flow selection draft.
>
> How do you feel about the draft's IPR situation?
>
> Cheers, Nevil
>
>
> On 01/30/2012 04:09 AM, Salvatore D'Antonio wrote:
>> Dear Nevil,
>>
>> We have not received any comment yet from the IPFIXers on the latest
> version
>> of the Draft on Flow Selection Techniques. The document is now in =
WGLC
> since
>> the current version contains many changes with respect to the version
>> presented at Quebec meeting.
>> I would be very grateful to you if you could send a reminder to the =
list
> in
>> order to invite the reviewers to provide us with their feedback on =
the
>> latest changes.
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>>
>> Salvatore
>>
>>
>> -----Messaggio originale-----
>> Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto =
di
>> Nevil Brownlee
>> Inviato: venerd=EC 18 novembre 2011 05:46
>> A: Romascanu, Dan (Dan)
>> Cc: ipfix@ietf.org
>> Oggetto: Re: [IPFIX] DRAFT minutes for Thursday's IPFIX meeting
>>
>>
>> Oops, too quick to hit send.  Here they are ...
>>
>> Cheers, Nevil
>>
>>
>> On 18/11/11 15:53, Nevil Brownlee wrote:
>>>
>>> Hi Dan et al:
>>>
>>> Here are our draft minutes, and a one-para summary of them.
>>>
>>> WG members: please send any corrections or improvements to me.
>>>
>>> Cheers, Nevil
>>
>
>


--=20
---------------------------------------------------------------------
  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
-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2112/4815 -  Data di =
rilascio:
17/02/2012

From andrewf@plixer.com  Tue Mar  6 08:54:25 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBF921F87DF for ; Tue,  6 Mar 2012 08:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.204
X-Spam-Level: 
X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfLppSb+Jv49 for ; Tue,  6 Mar 2012 08:54:23 -0800 (PST)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id B50A221F87DB for ; Tue,  6 Mar 2012 08:54:22 -0800 (PST)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Mar 2012 11:54:21 -0500
Message-ID: <4F56413D.5070507@plixer.com>
Date: Tue, 06 Mar 2012 11:54:21 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120229 Thunderbird/13.0a1
MIME-Version: 1.0
To: IETF IPFIX Working Group 
Content-Type: multipart/alternative; boundary="------------020105050003030408030004"
X-OriginalArrivalTime: 06 Mar 2012 16:54:21.0665 (UTC) FILETIME=[C7365510:01CCFBB9]
Subject: [IPFIX] rfc5103 lite
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 16:54:25 -0000

This is a multi-part message in MIME format.
--------------020105050003030408030004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

While reviewing the ie-doctors draft part of "4.10.  Avoiding Bad Ideas 
in Information Element Design" caught my attention.

"Specific examples of
    such Information Elements include initiatorOctets and responderOctets
    (which duplicate octetDeltaCount and its reverse per [RFC5103]) and
    initiatorPackets and responderPackets (the same, for
    packetDeltaCount)."

I agree that the initiatorOctets and initiatorPackets are redundant.  I 
also agree that in the context of IPFIX that responderOctets and 
responderPackets are made redundant by RFC 5103.  However, I think there 
is a valid use for the responderOctets and responderPackets IEs.

I see a lot of interest in implementing biflows, but many exporters are 
still exporting NetFlow v9 (RFC 3954).  The IEs for responderOctets and 
responderPackets allow a limited version of 5103 to be exported until 
the exporter can support IPFIX.  I'm not sure we want to paint these two 
IEs with the "bad idea" brush.  Maybe we could add a couple sentences to 
clarify the situation.

Something along the lines of
For 3954 use of responderOctets and responderPackets is OK, but don't 
expect new responder/reverse IEs to be added.  If you need more reverse 
IEs then IPFIX and 5103 should be implemented.

We should also fix initiatorPackets and responderPackets to not have 
"identifier" semantics.

-Andrew

--------------020105050003030408030004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    While reviewing the ie-doctors draft part of "4.10.  Avoiding Bad
    Ideas in Information Element Design" caught my attention.

    

    "Specific examples of

       such Information Elements include initiatorOctets and
    responderOctets

       (which duplicate octetDeltaCount and its reverse per [RFC5103])
    and

       initiatorPackets and responderPackets (the same, for

       packetDeltaCount)."

    

    I agree that the initiatorOctets and initiatorPackets are
    redundant.  I also agree that in the context of IPFIX that
    responderOctets and responderPackets are made redundant by RFC
    5103.  However, I think there is a valid use for the responderOctets
    and responderPackets IEs.

    

    I see a lot of interest in implementing biflows, but many exporters
    are still exporting NetFlow v9 (RFC 3954).  The IEs for
    responderOctets and responderPackets allow a limited version of 5103
    to be exported until the exporter can support IPFIX.  I'm not sure
    we want to paint these two IEs with the "bad idea" brush.  Maybe we
    could add a couple sentences to clarify the situation.

    

    Something along the lines of

    For 3954 use of responderOctets and responderPackets is OK, but
    don't expect new responder/reverse IEs to be added.  If you need
    more reverse IEs then IPFIX and 5103 should be implemented.

    

    We should also fix
    
    initiatorPackets and responderPackets to not have "identifier"
    semantics.

    

    -Andrew

  


--------------020105050003030408030004--

From trammell@tik.ee.ethz.ch  Tue Mar  6 09:21:47 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541EB21E80A9 for ; Tue,  6 Mar 2012 09:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJwJDEg7hD0u for ; Tue,  6 Mar 2012 09:21:46 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8146B21E80B5 for ; Tue,  6 Mar 2012 09:21:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DD453D9315; Tue,  6 Mar 2012 18:21:41 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qm5qb2niiXaw; Tue,  6 Mar 2012 18:21:41 +0100 (MET)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A1772D930C; Tue,  6 Mar 2012 18:21:41 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Brian Trammell 
In-Reply-To: <4F56413D.5070507@plixer.com>
Date: Tue, 6 Mar 2012 18:21:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch>
References: <4F56413D.5070507@plixer.com>
To: Andrew Feren 
X-Mailer: Apple Mail (2.1257)
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] rfc5103 lite
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 17:21:47 -0000

Hi, Andrew,

I'm okay making it clear that 4.10 describes IEs you shouldn't imitate =
when desiging new IEs, not IEs you shouldn't use. It seems little weird =
to me to stick a specific exception for a non-IETF protocol (3954 is =
Informational) in a document about extending an IETF protocol.

In the previous paragraph (new sentence on 3rd and 4th lines):

        However, for reasons of history, there
        are several Information Elements within the IANA registry which =
do not
        follow best practices in Information Element design. These =
Information
        Elements are not necessarily so flawed so as to require =
deprecation,
        but they should be explicitly ignored when looking for guidance =
as to
        whether a new Information Element should be added.

I think the paragraph you cite, though, is pretty clear that these IEs =
are being called out because they duplicate existing IEs.=20

That said... I'm a little confused as to how =
initiator/responderOctets/Packets allow 5103-lite in a V9-compatible =
way: they're allocated in IPFIX number space, not in v9 space. Can =
NetFlow V9 export such IEs? Are these exporters really using IPFIX =
without any IPFIX features (i.e., V9 with IPFIX message headers)? Or is =
it V9-heavy (V9 with new IPFIX IEs)?

As for semantics, yep. We need to do a complete semantics review as part =
of the 5102-bis effort. Thanks for pointing out yet another place where =
these are inconsistent, though; we have our work cut out for us. :)

Thanks, and cheers,

Brian

On Mar 6, 2012, at 5:54 PM, Andrew Feren wrote:

> While reviewing the ie-doctors draft part of "4.10.  Avoiding Bad =
Ideas in Information Element Design" caught my attention.
>=20
> "Specific examples of
>    such Information Elements include initiatorOctets and =
responderOctets
>    (which duplicate octetDeltaCount and its reverse per [RFC5103]) and
>    initiatorPackets and responderPackets (the same, for
>    packetDeltaCount)."
>=20
> I agree that the initiatorOctets and initiatorPackets are redundant.  =
I also agree that in the context of IPFIX that responderOctets and =
responderPackets are made redundant by RFC 5103.  However, I think there =
is a valid use for the responderOctets and responderPackets IEs.
>=20
> I see a lot of interest in implementing biflows, but many exporters =
are still exporting NetFlow v9 (RFC 3954).  The IEs for responderOctets =
and responderPackets allow a limited version of 5103     to be exported =
until the exporter can support IPFIX.  I'm not sure we want to paint =
these two IEs with the "bad idea" brush.  Maybe we could add a couple =
sentences to clarify the situation.
>=20
> Something along the lines of
> For 3954 use of responderOctets and responderPackets is OK, but don't =
expect new responder/reverse IEs to be added.  If you need more reverse =
IEs then IPFIX and 5103 should be implemented.
>=20
> We should also fix initiatorPackets and responderPackets to not have =
"identifier" semantics.
>=20
> -Andrew
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From paitken@cisco.com  Tue Mar  6 09:32:53 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A019011E8074 for ; Tue,  6 Mar 2012 09:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.508
X-Spam-Level: 
X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3spHB-Qc2tJe for ; Tue,  6 Mar 2012 09:32:48 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADD011E8085 for ; Tue,  6 Mar 2012 09:32:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=525; q=dns/txt; s=iport; t=1331055168; x=1332264768; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IduVQc1cSx95g2A68nRbPAxICF0aoj0TidkHwQsed2c=; b=InxX0A9vzyQCHB9grr/kL9q3/VQCb3NZGDsN+6J8YgTLG+qWkEToiuoc McRN9F5TlzeRTeeQa11Z11G2jp2wlBmCDrocQ+mnN0qpo79vV/Yp7/4/L zrfS9ZjlHM8avaUuLT2E3RCe6KUOsrF8SXpKpY6xEkXzxa7cWzzpY9KM7 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskGAK1JVk+Q/khN/2dsb2JhbABDgxaxZ4EHgX0BAQEDARIBJUAGCwshFg8JAwIBAgFFEwgBAR6HYAWgcgGXNI08gyIElT+FY4ozgmM
X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208";a="67819720"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Mar 2012 17:32:43 +0000
Received: from [10.61.83.123] (ams3-vpn-dhcp4988.cisco.com [10.61.83.123]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26HWh0W026407 for ; Tue, 6 Mar 2012 17:32:43 GMT
Message-ID: <4F564A3C.2060704@cisco.com>
Date: Tue, 06 Mar 2012 17:32:44 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4F56413D.5070507@plixer.com> <226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch>
In-Reply-To: <226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] rfc5103 lite
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 17:32:53 -0000

Brian,

> That said... I'm a little confused as to how initiator/responderOctets/Packets allow 5103-lite in a V9-compatible way: they're allocated in IPFIX number space, not in v9 space. Can NetFlow V9 export such IEs?

Yes, of course.

> Are these exporters really using IPFIX without any IPFIX features (i.e., V9 with IPFIX message headers)? Or is it V9-heavy (V9 with new IPFIX IEs)?

There's nothing heavy about it: equivalent definitions have been ported 
from the IPFIX infomodel to the NFv9 infomodel.

P.


From andrewf@plixer.com  Tue Mar  6 10:30:19 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088C121E80B4 for ; Tue,  6 Mar 2012 10:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bqXidp5Eb3F for ; Tue,  6 Mar 2012 10:30:17 -0800 (PST)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 7C74021E80A6 for ; Tue,  6 Mar 2012 10:29:29 -0800 (PST)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Mar 2012 13:29:28 -0500
Message-ID: <4F565788.5090503@plixer.com>
Date: Tue, 06 Mar 2012 13:29:28 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120229 Thunderbird/13.0a1
MIME-Version: 1.0
To: IETF IPFIX Working Group 
References: <4F56413D.5070507@plixer.com> <226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch>
In-Reply-To: <226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Mar 2012 18:29:28.0757 (UTC) FILETIME=[10E77650:01CCFBC7]
Subject: Re: [IPFIX] rfc5103 lite
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 18:30:19 -0000

Hi Brian,

On 03/06/2012 12:21 PM, Brian Trammell wrote:
> Hi, Andrew,
>
> I'm okay making it clear that 4.10 describes IEs you shouldn't imitate when desiging new IEs, not IEs you shouldn't use. It seems little weird to me to stick a specific exception for a non-IETF protocol (3954 is Informational) in a document about extending an IETF protocol.
Understood.  This is why I didn't flag this when I initially reviewed 
the ie-doctors draft.
>
> In the previous paragraph (new sentence on 3rd and 4th lines):
>
>          However, for reasons of history, there
>          are several Information Elements within the IANA registry which do not
>          follow best practices in Information Element design. These Information
>          Elements are not necessarily so flawed so as to require deprecation,
>          but they should be explicitly ignored when looking for guidance as to
>          whether a new Information Element should be added.
>
> I think the paragraph you cite, though, is pretty clear that these IEs are being called out because they duplicate existing IEs.
>
> That said... I'm a little confused as to how initiator/responderOctets/Packets allow 5103-lite in a V9-compatible way: they're allocated in IPFIX number space, not in v9 space.
In short these IEs don't require a PEN.

>   Can NetFlow V9 export such IEs? Are these exporters really using IPFIX without any IPFIX features (i.e., V9 with IPFIX message headers)? Or is it V9-heavy (V9 with new IPFIX IEs)?
Using your terminology I guess I would call what I am seeing "V9-heavy + 
vendor extensions".

I am seeing many NetFlow v9 exporters that

* send IEs above 127 (As long as they keep the the IPFIX datatype and 
semantics this is not a problem)
* implement vendor specific IEs without a PEN.  (I know of hundreds of 
vendor IEs above 32,767 defined by at least 5 vendors)

These same exporters are starting to implement biflows.  As much as I 
would prefer to see 5103, if v9 is being used I would prefer not to 
discourage the use of existing IEs.  Especially since the next step 
would be to define vendor specific reverse IEs.

However, you may be right that the current text is clear enough and 
ie-doctors isn't the place for a clarification.

-Andrew

>
> As for semantics, yep. We need to do a complete semantics review as part of the 5102-bis effort. Thanks for pointing out yet another place where these are inconsistent, though; we have our work cut out for us. :)
>
> Thanks, and cheers,
>
> Brian
>
> On Mar 6, 2012, at 5:54 PM, Andrew Feren wrote:
>
>> While reviewing the ie-doctors draft part of "4.10.  Avoiding Bad Ideas in Information Element Design" caught my attention.
>>
>> "Specific examples of
>>     such Information Elements include initiatorOctets and responderOctets
>>     (which duplicate octetDeltaCount and its reverse per [RFC5103]) and
>>     initiatorPackets and responderPackets (the same, for
>>     packetDeltaCount)."
>>
>> I agree that the initiatorOctets and initiatorPackets are redundant.  I also agree that in the context of IPFIX that responderOctets and responderPackets are made redundant by RFC 5103.  However, I think there is a valid use for the responderOctets and responderPackets IEs.
>>
>> I see a lot of interest in implementing biflows, but many exporters are still exporting NetFlow v9 (RFC 3954).  The IEs for responderOctets and responderPackets allow a limited version of 5103     to be exported until the exporter can support IPFIX.  I'm not sure we want to paint these two IEs with the "bad idea" brush.  Maybe we could add a couple sentences to clarify the situation.
>>
>> Something along the lines of
>> For 3954 use of responderOctets and responderPackets is OK, but don't expect new responder/reverse IEs to be added.  If you need more reverse IEs then IPFIX and 5103 should be implemented.
>>
>> We should also fix initiatorPackets and responderPackets to not have "identifier" semantics.
>>
>> -Andrew
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix


From andrewf@plixer.com  Tue Mar  6 10:49:04 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEC21E8096 for ; Tue,  6 Mar 2012 10:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.165,  BAYES_00=-2.599, J_CHICKENPOX_37=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWQx5docGmSv for ; Tue,  6 Mar 2012 10:49:04 -0800 (PST)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id D274E21E808C for ; Tue,  6 Mar 2012 10:49:03 -0800 (PST)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Mar 2012 13:49:03 -0500
Message-ID: <4F565C1F.7080909@plixer.com>
Date: Tue, 06 Mar 2012 13:49:03 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120229 Thunderbird/13.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4F50011C.1020508@cisco.com> <1AB7F5AF-265C-4EDC-AFFE-7E17A36102A8@tik.ee.ethz.ch> <4F500BD3.8040007@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Mar 2012 18:49:03.0443 (UTC) FILETIME=[CD125230:01CCFBC9]
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 18:49:04 -0000

On 03/02/2012 02:14 AM, Brian Trammell wrote:
> Hi, Paul,
[ snip ]
>
>
> 3.10.  Data Type and Semantics Restrictions
>
>     Note that the informationElementSemantics values defined in Section
>     3.2 of [RFC5102] are primarily intended to differentiate semantic
>     interpretation of numeric values, and that not all combinations of
>     the informationElementDataType and informationElementSemantics
>     Information Elements are valid; e.g., a counter cannot be encoded as
>     an IPv4 address.  The following are acceptable values of
>     informationElementSemantics:
>
>     o  Any value is valid for unsigned informationElementDataType values
>        ("unsigned8", "unsigned16", "unsigned32", or "unsigned64").
>
>     o  Any value except "flags" is valid for signed
>        informationElementDataType values ("signed8", "signed16",
>        "signed32", or "signed64").
>
>     o  Any value except "identifier" or "flags" is valid for floating-
>        point informationElementDataType values ("float32" or "float64").
>
>     o  Only "default" is valid for all other informationElementDataType
>        values ("octetArray", "boolean", "macAddress", "string",
>        "dateTimeSeconds", "dateTimeMilliseconds", "dateTimeMicroseconds",
>        "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").
>
> In the interests of self-consistency, I would suggest that cleanup should follow those guidelines, or the guidelines themselves should be updated by an erratum and/or moved into 5102bis and updated there.
I'd be in favor of updating the guidelines.  I would think that at least 
"identifier" could apply to octetArray, macAddress, string, ipv4Address, 
and/or ipv4Address.  For the addresses I think it would always apply.

I don't currently have a preference of erratum vs 5102bis.

-Andrew

From paitken@cisco.com  Tue Mar  6 13:50:44 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F169821E8053 for ; Tue,  6 Mar 2012 13:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.512
X-Spam-Level: 
X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iRHBfWv-ZLu for ; Tue,  6 Mar 2012 13:50:43 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D10DB21E8013 for ; Tue,  6 Mar 2012 13:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1273; q=dns/txt; s=iport; t=1331070643; x=1332280243; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1gg3yxa7Eb+utgRgm55iiQFIk6sCJdp77O1dP+7k9iA=; b=LQKb2c8Lkw5KeHCcZwJtIK0VtW5svNXr5tOCvuD4DppwyUgjFGV8CC0w EPq+NWidwHAwDSQO7Hy3vhFdiVbaMoPxiRd5B2m91QyibmKAMj7iHn5lP o2iXVfB7/H4wfc5rAl6qfFQgufPxkhgcS3J7PYO7M+R2Kz5NzkBh26YcR U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuMGACiGVk+Q/khM/2dsb2JhbABDgwmxd4EHgX0BAQEDARIBJUABBQsLIRYPCQMCAQIBRQYNAQcBAR6HYAWaPwGfGpBwBJU/hWOKM4Jj
X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="131516491"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2012 21:50:41 +0000
Received: from [10.61.83.123] (ams3-vpn-dhcp4988.cisco.com [10.61.83.123]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26Lofh5019512; Tue, 6 Mar 2012 21:50:41 GMT
Message-ID: <4F5686B2.9060600@cisco.com>
Date: Tue, 06 Mar 2012 21:50:42 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: Andrew Feren 
References: <4F56413D.5070507@plixer.com>	<226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch> <4F565788.5090503@plixer.com>
In-Reply-To: <4F565788.5090503@plixer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] rfc5103 lite
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 21:50:44 -0000

Andrew,

> I am seeing many NetFlow v9 exporters that
>
> * send IEs above 127

Of course. It's a 16-bit number space.


> (As long as they keep the the IPFIX datatype and semantics this is not 
> a problem)

Note that NFv9 and IPFIX are two different protocols, so there's no 
requirement for the IPFIX datatype and semantics to apply to the same 
field ID in NFv9.

- although in our case, we've endeavoured to do this as much as 
possible, assuming virtual equality between the two infomodels.


> * implement vendor specific IEs without a PEN.  (I know of hundreds of 
> vendor IEs above 32,767 defined by at least 5 vendors)

NFv9 doesn't have any vendor-specific IEs. It's a cisco protocol, and we 
might define any field to have any meaning at any time.

Also, there's no requirement for non-cisco vendors to use IDs > 32768. 
They could use any ID in the NFv9 range.

After discussing with Mike, I recently allocated some blocks of IDs 
within the NFv9 range for different vendors, in an effort to prevent us 
re-defining the same fields for different purposes.
It's only a pity that the vendors didn't approach me first.


Vendors, reach out to me if you're exporting your own NFv9 fields so we 
can avoid ID collisions.

P.

From n.brownlee@auckland.ac.nz  Wed Mar  7 02:28:36 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD53821F8704 for ; Wed,  7 Mar 2012 02:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.413
X-Spam-Level: 
X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 331BYbvIROiM for ; Wed,  7 Mar 2012 02:28:35 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5640B21F8703 for ; Wed,  7 Mar 2012 02:28:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1331116114; x=1362652114; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=mx86mgC7k3OnW2hmuMznJSdf4YZO9ZwcJtQFfgCDqGE=; b=ujfc2/kkcM8KAZNIn6+2v9FkWbpfAqz7RMOcgcbqlryVaMLKi2eNTIF5 OI879N7Q3XvYVqk+34+wjpii1oZLeYGpmzTTzYIUlpo1K2vUaH1LIhTxp waOy+0UxdXSBtZGABSomPF6k4uwUsaOSDE8dhKpQKhImmBGiMBL+wE6MU Q=;
X-IronPort-AV: E=Sophos;i="4.73,545,1325415600"; d="scan'208";a="108070382"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 158.38.40.197 - Outgoing - Outgoing-SSL
Received: from unigjest-dhcp197.uninett.no (HELO [158.38.40.197]) ([158.38.40.197]) by mx2-int.auckland.ac.nz with ESMTP; 07 Mar 2012 23:28:30 +1300
Message-ID: <4F57384A.6090909@auckland.ac.nz>
Date: Wed, 07 Mar 2012 02:28:26 -0800
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX list 
Subject: [IPFIX] write-up for IPFIX Flow Selection Draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 10:28:37 -0000

Hi Dan:

Here's the write-up for this draft, would you please submit it
to IESG for publication.  I realise that it's not long until IETF-83,
however I'm sending this to you now because it should complete
the work items of the IPFIX charter's previous version.

Cheers, Nevil


Draft: draft-ietf-ipfix-flow-selection-tech-10.txt
Title: Flow Selection Techniques


As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding,
this is the current template for the Document Shepherd Write-Up.
Changes are expected over time.  This version is dated February 1, 2007.


    (1.a)  Who is the Document Shepherd for this document?  Has the
           Document Shepherd personally reviewed this version of the
           document and, in particular, does he or she believe this
           version is ready for forwarding to the IESG for publication?

   Nevil Brownlee.  I have reviewed this draft, I believe it's ready
   for publication.

    (1.b)  Has the document had adequate review both from key WG members
           and from key non-WG members?  Does the Document Shepherd have
           any concerns about the depth or breadth of the reviews that
           have been performed?

   Yes.  This draft had a WGLC in August 2011, which raised important
   issues, mostly concerning its relationship to the PSAMP selection
   RFC.  It was revised to address those issues, and had a second
   WGLC in February 2012.  That raised a few further issues; these have
   been addressed in the current version.

    (1.c)  Does the Document Shepherd have concerns that the document
           needs more review from a particular or broader perspective,
           e.g., security, operational complexity, someone familiar with
           AAA, internationalization or XML?

   No.

    (1.d)  Does the Document Shepherd have any specific concerns or
           issues with this document that the Responsible Area Director
           and/or the IESG should be aware of?  For example, perhaps he
           or she is uncomfortable with certain parts of the document, or
           has concerns whether there really is a need for it.  In any
           event, if the WG has discussed those issues and has indicated
           that it still wishes to advance the document, detail those
           concerns here.  Has an IPR disclosure related to this document
           been filed?  If so, please include a reference to the
           disclosure and summarize the WG discussion and conclusion on
           this issue.

   This draft raised IPR concerns, in the same manner as the PSAMP
   selection draft had done.  Nick Duffield (AT&T) commented that
   the AT&T IPR claim relates only to statistical sampling, and PSAMP
   handled this by saying "at least on of the sampling techniques
   must be implemented."
   In this draft, we have tightened that up a little by saying
   "a conforming implementation MUST implement at least the
   Property Match Filtering."

    (1.e)  How solid is the WG consensus behind this document?  Does it
           represent the strong concurrence of a few individuals, with
           others being silent, or does the WG as a whole understand and
           agree with it?

   The WG has reached full consensus on this draft.

    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
           discontent?  If so, please summarise the areas of conflict in
           separate email messages to the Responsible Area Director.  (It
           should be in a separate email because this questionnaire is
           entered into the ID Tracker.)

   No.

    (1.g)  Has the Document Shepherd personally verified that the
           document satisfies all ID nits?  (See
           http://www.ietf.org/ID-Checklist.html and
           http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
           not enough; this check needs to be thorough.  Has the document
           met all formal review criteria it needs to, such as the MIB
           Doctor, media type and URI type reviews?

   The ID nits checker finds six nots concerned with references.
   In my opinion these are all Editorial, and - since the IETF-83
   drafts deadline is very close now - can be fixed later on,
   say after IETF Last Call.

    (1.h)  Has the document split its references into normative and
           informative?  Are there normative references to documents that
           are not ready for advancement or are otherwise in an unclear
           state?  If such normative references exist, what is the
           strategy for their completion?  Are there normative references
           that are downward references, as described in [RFC3967]?  If
           so, list these downward references to support the Area
           Director in the Last Call procedure for them [RFC3967].

   Yes.  There no references to non-existing documents.
   The only issue here are the ID nits mentioned above.

    (1.i)  Has the Document Shepherd verified that the document IANA
           consideration section exists and is consistent with the body
           of the document?  If the document specifies protocol
           extensions, are reservations requested in appropriate IANA
           registries?  Are the IANA registries clearly identified?  If
           the document creates a new registry, does it define the
           proposed initial contents of the registry and an allocation
           procedure for future registrations?  Does it suggest a
           reasonable name for the new registry?  See [RFC2434].  If the
           document describes an Expert Review process has Shepherd
           conferred with the Responsible Area Director so that the IESG
           can appoint the needed Expert during the IESG Evaluation?

   Yes.  No new IANA registries are required.

    (1.j)  Has the Document Shepherd verified that sections of the
           document that are written in a formal language, such as XML
           code, BNF rules, MIB definitions, etc., validate correctly in
           an automated checker?

   There are no sections in a formal language.

    (1.k)  The IESG approval announcement includes a Document
           Announcement Write-Up.  Please provide such a Document
           Announcement Write-Up?  Recent examples can be found in the
           "Action" announcements for approved documents.  The approval
           announcement contains the following sections:

           Technical Summary
    Flow selection is the process of selecting a subset of flows from all
    observed flows.  The Flow Selection Process may be located at an
    observation point, or on an IPFIX Mediator.  Flow selection reduces
    the effort of post-processing flow data and transferring Flow
    Records.  This document describes motivations for flow selection and
    presents flow selection techniques.  It provides an information model
    for configuring flow selection techniques and discusses what
    information about a flow selection process should be exported.

           Working Group Summary
    This document has been extensively reviewed by the WG, and has
    had two WGLCs.  I believe that all the issues raised have been
    resolved; we now have clear WG consensus.

           Document Quality
    I'm not aware of any implementations of IPFIX flow selection.
    Brian Trammell provided reviews that were particularly useful
    to the draft's authors.

           Personnel
   Shepherd: Nevil Brownlee
   AD: Dan Romascanu / Benoit Claise
   IANA Expert:  Nevil Brownlee / Juergen Quittek

-- 
---------------------------------------------------------------------
  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


From internet-drafts@ietf.org  Wed Mar  7 09:16:21 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDACF21E80C1; Wed,  7 Mar 2012 09:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ugs71yJ+jik; Wed,  7 Mar 2012 09:16:19 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAF821E8017; Wed,  7 Mar 2012 09:16:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120307171619.27644.81039.idtracker@ietfa.amsl.com>
Date: Wed, 07 Mar 2012 09:16:19 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 17:16:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Guidelines for Authors and Reviewers of IPFIX Informatio=
n Elements
	Author(s)       : Brian Trammell
                          Benoit Claise
	Filename        : draft-ietf-ipfix-ie-doctors-02.txt
	Pages           : 33
	Date            : 2012-03-07

   This document provides guidelines for the definition of IPFIX
   Information Elements for addition to the IANA IPFIX Information
   Element registry, in order to extend the applicability of the IPFIX
   protocol to new operations and management areas.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-02.txt


From trammell@tik.ee.ethz.ch  Wed Mar  7 09:20:34 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9221F8710 for ; Wed,  7 Mar 2012 09:20:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRG3wVOXJ4aS for ; Wed,  7 Mar 2012 09:20:33 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A895B21F870F for ; Wed,  7 Mar 2012 09:20:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D481DD9309 for ; Wed,  7 Mar 2012 18:20:32 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g1ieW1bftrmH for ; Wed,  7 Mar 2012 18:20:32 +0100 (MET)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9A9F1D9307 for ; Wed,  7 Mar 2012 18:20:32 +0100 (MET)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Mar 2012 18:20:32 +0100
References: <20120307171619.27644.81039.idtracker@ietfa.amsl.com>
To: IETF IPFIX Working Group 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [IPFIX] Fwd:  I-D Action: draft-ietf-ipfix-ie-doctors-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 17:20:34 -0000

Greetings, all,

This revision of the draft addresses WGLC comments received to date =
(thanks, Andrew!).=20

Best regards,

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-02.txt
> Date: March 7, 2012 6:16:19 PM GMT+01:00
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the IP Flow Information Export =
Working Group of the IETF.
>=20
> 	Title           : Guidelines for Authors and Reviewers of IPFIX =
Information Elements
> 	Author(s)       : Brian Trammell
>                          Benoit Claise
> 	Filename        : draft-ietf-ipfix-ie-doctors-02.txt
> 	Pages           : 33
> 	Date            : 2012-03-07
>=20
>   This document provides guidelines for the definition of IPFIX
>   Information Elements for addition to the IANA IPFIX Information
>   Element registry, in order to extend the applicability of the IPFIX
>   protocol to new operations and management areas.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-02.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-02.txt
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From internet-drafts@ietf.org  Wed Mar  7 23:28:11 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7221E8057; Wed,  7 Mar 2012 23:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level: 
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooUPphfvByp8; Wed,  7 Mar 2012 23:28:11 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A52921E802D; Wed,  7 Mar 2012 23:28:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120308072811.2229.44171.idtracker@ietfa.amsl.com>
Date: Wed, 07 Mar 2012 23:28:11 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 07:28:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Specification of the IP Flow Information eXport (IPFIX) =
Protocol for the Exchange of Flow Information
	Author(s)       : Benoit Claise
                          Brian Trammell
	Filename        : draft-ietf-ipfix-protocol-rfc5101bis-01.txt
	Pages           : 66
	Date            : 2012-03-07

   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting Traffic Flow information over
   the network.  In order to transmit Traffic Flow information from an
   Exporting Process to an information Collecting Process, a common
   representation of flow data and a standard means of communicating
   them is required.  This document describes how the IPFIX Data and
   Template Records are carried over a number of transport protocols
   from an IPFIX Exporting Process to an IPFIX Collecting Process.  This
   document obsoletes RFC 5101.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-01=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-01.=
txt


From trammell@tik.ee.ethz.ch  Thu Mar  8 00:11:05 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5FF21F8554 for ; Thu,  8 Mar 2012 00:11:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.654
X-Spam-Level: 
X-Spam-Status: No, score=-6.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THs3t7mjUhhU for ; Thu,  8 Mar 2012 00:11:05 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0A08A21F84B3 for ; Thu,  8 Mar 2012 00:11:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C748AD9307 for ; Thu,  8 Mar 2012 09:11:02 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1ZHaNDWvVObC for ; Thu,  8 Mar 2012 09:11:02 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 775D9D9300 for ; Thu,  8 Mar 2012 09:11:02 +0100 (MET)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Mar 2012 09:11:02 +0100
References: <20120308072811.2229.44171.idtracker@ietfa.amsl.com>
To: IETF IPFIX Working Group 
Message-Id: <558064F4-BC67-46E7-BF3C-9D12CBAB72D6@tik.ee.ethz.ch>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 08:11:06 -0000

Greetings, all,

Revision -01 of rfc5101bis has been posted, encompassing commentary to =
date on the draft. The biggest changes are the reorganization of =
Sections 8, 9, and 10 to improve readability by:

1. moving all Template management considerations into section 8 (as =
template management is the most complex part of the protocol);

2. identifying Template management and Collecting Process considerations =
common to all transports; and

3. aligning the structure of the transport-specific considerations =
sections.

Additionally:

References to the IP-ness of packets have been removed where not =
necessary.

RFC6520 (DTLS heartbeat) now SHOULD be used for long-lived sessions.

Given the impracticality of signaling receiver error in a fundamentally =
unidirectional protocol, situations where the CP MUST drop an =
association in 5101 have been changed to MUST ignore SHOULD log in =
5101bis; this goes along with the relaxation of template management =
restrictions in the -00 revision.

Full diffs can be read at =
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-=
01.

The big remaining open issue would appear to be that we need to interop =
several features which have never been interop'd; I presume this would =
be a point of discussion at the WG meeting in Paris.

Best regards,

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: [IPFIX] I-D Action: =
draft-ietf-ipfix-protocol-rfc5101bis-01.txt
> Date: March 8, 2012 8:28:11 AM GMT+01:00
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the IP Flow Information Export =
Working Group of the IETF.
>=20
> 	Title           : Specification of the IP Flow Information =
eXport (IPFIX) Protocol for the Exchange of Flow Information
> 	Author(s)       : Benoit Claise
>                          Brian Trammell
> 	Filename        : draft-ietf-ipfix-protocol-rfc5101bis-01.txt
> 	Pages           : 66
> 	Date            : 2012-03-07
>=20
>   This document specifies the IP Flow Information Export (IPFIX)
>   protocol that serves for transmitting Traffic Flow information over
>   the network.  In order to transmit Traffic Flow information from an
>   Exporting Process to an information Collecting Process, a common
>   representation of flow data and a standard means of communicating
>   them is required.  This document describes how the IPFIX Data and
>   Template Records are carried over a number of transport protocols
>   from an IPFIX Exporting Process to an IPFIX Collecting Process.  =
This
>   document obsoletes RFC 5101.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-0=
1.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-01=
.txt
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From andrewf@plixer.com  Thu Mar  8 06:14:03 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B126621F8717 for ; Thu,  8 Mar 2012 06:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.167
X-Spam-Level: 
X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAVQmYjiNP-J for ; Thu,  8 Mar 2012 06:14:02 -0800 (PST)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 200E121F8557 for ; Thu,  8 Mar 2012 06:13:51 -0800 (PST)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Mar 2012 09:13:45 -0500
Message-ID: <4F58BE98.3000303@plixer.com>
Date: Thu, 08 Mar 2012 09:13:44 -0500
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120304 Thunderbird/13.0a1
MIME-Version: 1.0
To: IETF IPFIX Working Group , Paul Aitken 
References: <4F56413D.5070507@plixer.com>	<226542FB-7B3C-4565-87BE-E800DD89D844@tik.ee.ethz.ch> <4F565788.5090503@plixer.com> <4F5686B2.9060600@cisco.com>
In-Reply-To: <4F5686B2.9060600@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Mar 2012 14:13:45.0046 (UTC) FILETIME=[AC2A7760:01CCFD35]
Subject: Re: [IPFIX] rfc5103 lite
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 14:14:04 -0000

On 03/06/2012 04:50 PM, Paul Aitken wrote:
> Andrew,
>
>> I am seeing many NetFlow v9 exporters that
>>
>> * send IEs above 127
>
> Of course. It's a 16-bit number space.
Agreed.  I was mostly responding to Brian's "not in v9 space" comment.  
I assumed he was referring to "Information Element identifier values in 
the sub-range of  1-127 are compatible with field types used by NetFlow 
version 9" from RFC 5102.

>> (As long as they keep the the IPFIX datatype and semantics this is 
>> not a problem)
>
> Note that NFv9 and IPFIX are two different protocols, so there's no 
> requirement for the IPFIX datatype and semantics to apply to the same 
> field ID in NFv9.
Understood.
>
> - although in our case, we've endeavoured to do this as much as 
> possible, assuming virtual equality between the two infomodels.
And I appreciate that effort.  Since NFv9 is Cisco's protocol I tend to 
treat what Cisco does for v9 as "standard", but point taken that there 
is no actual requirement.

>> * implement vendor specific IEs without a PEN.  (I know of hundreds 
>> of vendor IEs above 32,767 defined by at least 5 vendors)
>
> NFv9 doesn't have any vendor-specific IEs. It's a cisco protocol, and 
> we might define any field to have any meaning at any time.

OK, but I wasn't sure what else to call an IE that isn't in any 
standard, is sent only from one vendor, and is sent using a protocol 
that looks suspiciously like NetFlow v9.  :-)

>
> Also, there's no requirement for non-cisco vendors to use IDs > 32768. 
> They could use any ID in the NFv9 range.

Agreed.  My bias toward keeping v9 IEs that are not also standard IPFIX 
in a range that won't conflict with an eventual IPFIX IE leaked through.

>
> After discussing with Mike, I recently allocated some blocks of IDs 
> within the NFv9 range for different vendors, in an effort to prevent 
> us re-defining the same fields for different purposes.
> It's only a pity that the vendors didn't approach me first.
>
> Vendors, reach out to me if you're exporting your own NFv9 fields so 
> we can avoid ID collisions.

Thanks for taking that on.

-Andrew


From internet-drafts@ietf.org  Thu Mar  8 07:15:47 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE91B21F8772; Thu,  8 Mar 2012 07:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPCDsMpWNNKZ; Thu,  8 Mar 2012 07:15:46 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB8121F8713; Thu,  8 Mar 2012 07:15:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120308151545.9663.73331.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2012 07:15:45 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 15:15:48 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Information Model for IP Flow Information eXport (IPFIX)
	Author(s)       : Benoit Claise
                          Brian Trammell
	Filename        : draft-ietf-ipfix-information-model-rfc5102bis-01.txt
	Pages           : 30
	Date            : 2012-03-08

This memo defines an overview of the information model for the IP Flow
Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol
for encoding measured traffic information and information related to the
traffic Observation Point, the traffic Metering Process, and the
Exporting Process.  Although developed for the IPFIX protocol, the model
is defined in an open way that easily allows using it in other
protocols, interfaces, and applications.  This document obsoletes RFC
5102.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc5=
102bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc51=
02bis-01.txt


From bclaise@cisco.com  Thu Mar  8 07:19:47 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86CE21F877A for ; Thu,  8 Mar 2012 07:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level: 
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfkcnSSgD4ao for ; Thu,  8 Mar 2012 07:19:47 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D51F321F8778 for ; Thu,  8 Mar 2012 07:19:46 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q28FJjxx016711 for ; Thu, 8 Mar 2012 16:19:45 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q28FJjXs026545 for ; Thu, 8 Mar 2012 16:19:45 +0100 (CET)
Message-ID: <4F58CE10.5010608@cisco.com>
Date: Thu, 08 Mar 2012 16:19:44 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "ipfix@ietf.org" 
References: <20120308151545.9663.73331.idtracker@ietfa.amsl.com>
In-Reply-To: <20120308151545.9663.73331.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120308151545.9663.73331.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------060603030908050604090701"
Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 15:19:48 -0000

This is a multi-part message in MIME format.
--------------060603030908050604090701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Minor edits compared to the previous version, which was posted on 
January 24th.
The main point of this new version is to be up to date with the latest 
open issue list, and to cover one more errata (reported since the 
previous version).

Regards, Benoit.

-------- Original Message --------
Subject: 	[IPFIX] I-D Action: 
draft-ietf-ipfix-information-model-rfc5102bis-01.txt
Date: 	Thu, 08 Mar 2012 07:15:45 -0800
From: 	internet-drafts@ietf.org
To: 	i-d-announce@ietf.org
CC: 	ipfix@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF.

	Title           : Information Model for IP Flow Information eXport (IPFIX)
	Author(s)       : Benoit Claise
                           Brian Trammell
	Filename        : draft-ietf-ipfix-information-model-rfc5102bis-01.txt
	Pages           : 30
	Date            : 2012-03-08

This memo defines an overview of the information model for the IP Flow
Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol
for encoding measured traffic information and information related to the
traffic Observation Point, the traffic Metering Process, and the
Exporting Process.  Although developed for the IPFIX protocol, the model
is defined in an open way that easily allows using it in other
protocols, interfaces, and applications.  This document obsoletes RFC
5102.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc5102bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc5102bis-01.txt

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix




--------------060603030908050604090701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    Minor edits compared to the previous version, which was posted on
    January 24th.

    The main point of this new version is to be up to date with the
    latest open issue list, and to cover one more errata (reported since
    the previous version).

    

    Regards, Benoit.

    

    -------- Original Message --------
    

      
        

          Subject: 
          [IPFIX] I-D Action:
            draft-ietf-ipfix-information-model-rfc5102bis-01.txt
        

        

          Date: 
          Thu, 08 Mar 2012 07:15:45 -0800
        

        

          From: 
          internet-drafts@ietf.org
        

        

          To: 
          i-d-announce@ietf.org
        

        

          CC: 
          ipfix@ietf.org
        

      
    

    

    

    
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF.

	Title           : Information Model for IP Flow Information eXport (IPFIX)
	Author(s)       : Benoit Claise
                          Brian Trammell
	Filename        : draft-ietf-ipfix-information-model-rfc5102bis-01.txt
	Pages           : 30
	Date            : 2012-03-08

This memo defines an overview of the information model for the IP Flow
Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol
for encoding measured traffic information and information related to the
traffic Observation Point, the traffic Metering Process, and the
Exporting Process.  Although developed for the IPFIX protocol, the model
is defined in an open way that easily allows using it in other
protocols, interfaces, and applications.  This document obsoletes RFC
5102.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc5102bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc5102bis-01.txt

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix




  


--------------060603030908050604090701--

From n.brownlee@auckland.ac.nz  Fri Mar  9 07:41:38 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1821F86B4 for ; Fri,  9 Mar 2012 07:41:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level: 
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np-IYb-U0coe for ; Fri,  9 Mar 2012 07:41:37 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9E21F86AB for ; Fri,  9 Mar 2012 07:41:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1331307697; x=1362843697; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=wpt/g3XxuqnP+3QaHUCnkBocS/QGMebECMfZEehLW8Q=; b=QcUnNj3qZ/GhT9NCNbiBFzOiNgl8x6OORhp9/XZrY9IAiFvNzNeee0+K 48TLQpRmeqQHUY/M4Fqcd3mmCZ/ml1a/Hy6Se6AzBYsXjMrAPL8UFjsoH tRL3EJqu/ETe0o6z+LtoxyYsqlH+W0nhA6tyzCvpHmwJ7HeY527ipCnvP w=;
X-IronPort-AV: E=Sophos;i="4.73,558,1325415600"; d="scan'208";a="108711777"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 158.38.40.197 - Outgoing - Outgoing-SSL
Received: from unigjest-dhcp197.uninett.no (HELO [158.38.40.197]) ([158.38.40.197]) by mx2-int.auckland.ac.nz with ESMTP; 10 Mar 2012 04:41:35 +1300
Message-ID: <4F5A24AC.6000406@auckland.ac.nz>
Date: Fri, 09 Mar 2012 07:41:32 -0800
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: IPFIX list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] DRAFT agenda for IPFIX meeting at IETF-83 (Paris)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Mar 2012 15:41:38 -0000

Hi all:

Here's my first draft of the agenda for Paris.
  - Before the meeting, would the authors/editors of each of
    the WG drafts plese let me know who will be presenting it.
  - Anyone wanting to present new drafts, or add other agend
    items, please let me know

Cheers, Nevil

===========================================
IP Flow Information Export WG (ipfix)
DRAFT-00   Agenda for IETF 83, Paris
Thursday, 29 March, 1740-1940, room 212/213
===========================================

Chairs:
Juergen Quittek 
Nevil Brownlee  

AGENDA:

1. Agenda review                                            =  5 min

2. Update from last meeting / WG Status (Nevil)             = 10 min
      IPFIX Export per SCTP Stream
        In AUTH48 state

      IPFIX Configuration Model
        draft-ietf-ipfix-configuration-model-10, 18 Jul 11
        Waiting on PSAMP MIB
      PSAMP MIB
        draft-ietf-ipfix-psamp-mib-04.txt, 27 Feb 12
        Waiting on IPFIX MIB
      IPFIX MIB  (charter item 6.)
        draft-ietf-ipfix-rfc5815bis-01, 20 Jan 12
        In IETF LC, IESG telechat 15 Mar

      Flow Selection Techniques
       draft-ietf-ipfix-flow-selection-tech-10,  6 Mar 12
       write-up sent Wed, 6 Mar 12

3. Discussion of Interoperation Testing of features         = 15 min
    changes in 5101 and 5102 bis,  progression to Full Standard

3. New charter work items                                   = 75 min
    a) IPFIX Aggregation
         draft-ietf-ipfix-a9n-03, 27 Feb 12

    b) Specification of the IP Flow Information eXport (IPFIX)
       Protocol for the Exchange of Flow Information
         draft-ietf-ipfix-protocol-rfc5101bis-01, 7 Mar 11

    c) Information Model for IP Flow Information eXport (IPFIX)
         draft-ietf-ipfix-information-model-rfc5102bis-00, 24 Jan 12

    d) Guidelines for Information Elements
         draft-ietf-ipfix-ie-doctors-02, 7 Mar 12

    e) Protocol for PFIX Mediation
         draft-ietf-ipfix-mediation-protocol-00, 6 Dec 11

    f) Exporting MIB objects
         draft-johnson-ipfix-mib-variable-export-03, 31 Oct 11

    g) IEs for Data Link Layer Traffic Measurement
         draft-kashima-ipfix-data-link-layer-monitoring-06, 14 Sep 11

4. Other drafts ?


5. Discussion of future direction for IPF (if time allows) = 10 min


6. Any Other Business                                       =  5 min


Presentation slides will be available at
   https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=83
   (search for IPFIX in the Operations and Management Area)

Participation via jabber is offered at ipfix@jabber.ietf.org

-- 
---------------------------------------------------------------------
  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


From internet-drafts@ietf.org  Mon Mar 12 07:59:01 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81B21F85B6; Mon, 12 Mar 2012 07:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level: 
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKu5h22JKyTD; Mon, 12 Mar 2012 07:59:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9093B21F85D9; Mon, 12 Mar 2012 07:59:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120312145900.23951.87555.idtracker@ietfa.amsl.com>
Date: Mon, 12 Mar 2012 07:59:00 -0700
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-rfc5815bis-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 14:59:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Definitions of Managed Objects for IP Flow Information E=
xport
	Author(s)       : Thomas Dietz
                          Atsushi Kobayashi
                          Benoit Claise
                          Gerhard Muenz
	Filename        : draft-ietf-ipfix-rfc5815bis-02.txt
	Pages           : 68
	Date            : 2012-03-12

   This document defines managed objects for IP Flow Information eXport
   (IPFIX).  These objects provide information for monitoring IPFIX
   Exporters and IPFIX Collectors including the basic configuration
   information.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-02.txt


From ayourtch@cisco.com  Mon Mar 12 14:07:58 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5011E8135 for ; Mon, 12 Mar 2012 14:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7wLjtJFApMt for ; Mon, 12 Mar 2012 14:07:58 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B2FE911E812D for ; Mon, 12 Mar 2012 14:07:57 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2CL7u3L002060 for ; Mon, 12 Mar 2012 22:07:56 +0100 (CET)
Received: from ams-ayourtch-8719.cisco.com (ams-ayourtch-8719.cisco.com [10.55.144.250]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2CL7nxK019739; Mon, 12 Mar 2012 22:07:49 +0100 (CET)
Date: Mon, 12 Mar 2012 22:07:48 +0100 (CET)
From: Andrew Yourtchenko 
X-X-Sender: ayourtch@ayourtch-lnx
To: ipfix@ietf.org
Message-ID: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [IPFIX] New Version Notification for draft-yourtchenko-cisco-ies-03.txt (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 21:07:58 -0000

Hi all,

just to let you know that we've submitted the new version of the draft.

Very minor edits and updates to keep in sync with the other drafts'
versioning.

--a

---------- Forwarded message ----------
Date: Mon, 12 Mar 2012 12:52:47 -0700
From: internet-drafts@ietf.org
To: ayourtch@cisco.com
Cc: bclaise@cisco.com, paitken@cisco.com
Subject: New Version Notification for draft-yourtchenko-cisco-ies-03.txt

A new version of I-D, draft-yourtchenko-cisco-ies-03.txt has been successfully submitted by Andrew Yourtchenko and posted to the IETF repository.

Filename:	 draft-yourtchenko-cisco-ies
Revision:	 03
Title:		 Cisco Specific Information Elements reused in IPFIX
Creation date:	 2012-03-12
WG ID:		 Individual Submission
Number of pages: 20

Abstract:
    This document describes some additional Information Elements of Cisco
    Systems, Inc. that are not listed in RFC3954.




The IETF Secretariat


From Quittek@neclab.eu  Tue Mar 13 03:29:48 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3378821F8713 for ; Tue, 13 Mar 2012 03:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.465
X-Spam-Level: 
X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUyMz54t83QZ for ; Tue, 13 Mar 2012 03:29:47 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9405721F8709 for ; Tue, 13 Mar 2012 03:29:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 51DEB100888 for ; Tue, 13 Mar 2012 11:30:02 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33DvUB+Y4kjJ for ; Tue, 13 Mar 2012 11:30:02 +0100 (CET)
Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 39609100887 for ; Tue, 13 Mar 2012 11:29:57 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 11:29:41 +0100
From: Juergen Quittek 
To: IETF IPFIX Working Group 
Thread-Topic: Planned Freeze of rfc-editor.org 
Thread-Index: AQHNAMNRj+l8cLpXKUObUvqG68yF9ZZn9hgA
Date: Tue, 13 Mar 2012 10:29:40 +0000
Message-ID: 
In-Reply-To: <20120313024327.GB29036@rfc-editor.org>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.7.0.92]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0151A7E6AF7534489A148DA125359DD1@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPFIX] FW: Planned Freeze of rfc-editor.org 
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 10:29:48 -0000

Dear all,

Everyone who has ongoing discussion with the RFC-Editor,
Please be aware that the RFC database will be frozen on
March 13-14.

Thanks,
    Juergen

On 13.03.12 02:43, "RFC Editor"  wrote:

>Greetings All,
>
>Just a reminder that information generated from the RFC Editor
>database will be frozen starting at midnight (PDT) tonight.  Please
>see the mail below for more details.
>
>Thank you,
>RFC Editor
>
>On Thu, Mar 08, 2012 at 11:33:30AM -0800, RFC Editor wrote:
>> Greetings All,
>>=20
>> Please note there will be a freeze on March 13-14 for information at
>> rfc-editor.org  that is generated from the
>> database.  The RFC Editor will continue to work on documents, but this
>> won't be reflected on rfc-editor.org  (e.g.,
>> the queue page will not be updated).  Errata submission and
>> verification pages will be temporarily closed.  Updates will resume by
>> noon PDT, March 15.
>>=20
>> Following the freeze, the RFC Editor will provide a new view of the
>> publication queue that shows additional data and is sortable by
>> column.  Additionally, the accuracy of the statistics used by the RFC
>> Editor for reporting purposes will be improved.
>>=20
>> Thank you.
>>=20
>> RFC Editor


From n.brownlee@auckland.ac.nz  Tue Mar 13 06:32:45 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB021F8795 for ; Tue, 13 Mar 2012 06:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNYXJYPQGQP6 for ; Tue, 13 Mar 2012 06:32:44 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36FDD21F878E for ; Tue, 13 Mar 2012 06:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1331645564; x=1363181564; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=26qnamjsnk7ob+KMJyMNzTfJKX0LoW6M7KMpjiSDuRk=; b=jPez7uHlQV375xz4C75XgNETo0k5GGzUJsbS7QIo1mPlknYBqvSRzsgc uA37+urdG9FTr7epoijErbeQVRBFMfReDcYO40JpmjPWK8S/ap5n3DzVb H37EpIsn1DhaER/KRkNSb4ZeCuyxtSI38/Sk+ilhj9Olhm/3/axJ7Yfzt E=;
X-IronPort-AV: E=Sophos;i="4.73,576,1325415600"; d="scan'208";a="109501676"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 78.142.161.130 - Outgoing - Outgoing-SSL
Received: from unknown (HELO [192.168.1.167]) ([78.142.161.130]) by mx2-int.auckland.ac.nz with ESMTP; 14 Mar 2012 02:32:42 +1300
Message-ID: <4F5F4C78.5010201@auckland.ac.nz>
Date: Tue, 13 Mar 2012 06:32:40 -0700
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: IPFIX list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] IETF-83 agenda, version -01
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 13:32:45 -0000

Hi all:

A revised version of our agenda for IETF-83 in Paris is now on
the meeting's agenda page, i.e. at
   http://www.ietf.org/proceedings/83/agenda/agenda-83-ipfix.txt

Cheers, Nevil

-- 
---------------------------------------------------------------------
  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


From Quittek@neclab.eu  Tue Mar 13 19:02:24 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CFF21E803B for ; Tue, 13 Mar 2012 19:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.172
X-Spam-Level: 
X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hF9kJuo7-7Y for ; Tue, 13 Mar 2012 19:02:23 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 78CA121E8041 for ; Tue, 13 Mar 2012 19:02:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4E1671008BA; Wed, 14 Mar 2012 03:02:41 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OMKVzn-jMEq; Wed, 14 Mar 2012 03:02:41 +0100 (CET)
Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2E6341008A4; Wed, 14 Mar 2012 03:02:21 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 14 Mar 2012 03:01:57 +0100
From: Juergen Quittek 
To: Carter Bullard 
Thread-Topic: [IPFIX] recent ipfix drafts and argus
Thread-Index: AQHNAYZwMFkRaj4aAUWqz83i5N301w==
Date: Wed, 14 Mar 2012 02:01:59 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.7.0.92]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <8E6DDE1EB065CB4F80702F8644E73EB3@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 02:02:24 -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"  wrote:

>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
>150 E. 57th Street Suite 12D
>New York, New York 10022
>
>+1 212 588-9133 Phone
>+1 212 588-9134 Fax
>
>
>
>
>
>On Mar 1, 2012, at 12:16 PM, Carter Bullard wrote:
>
>
>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
>150 E. 57th Street Suite 12D
>New York, New York 10022
>
>+1 212 588-9133 Phone
>+1 212 588-9134 Fax
>
>
>
>On Mar 1, 2012, at 11:36 AM, Carter Bullard wrote:
>
>
>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=20
>
>
>
>
>
>On 29.02.12 17:38, "Carter Bullard"  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
>
>
>
>=A9 and prediction of flow statistics from sampled packet =A9 - 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
>
>
>
>IPFIX@ietf.org
>
>
>
>https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>
>
>
>
>
>--=20
>
>---------------------------------------------------------------------
>
>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
>
>IPFIX@ietf.org
>
>https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>
>_______________________________________________
>
>IPFIX mailing list
>
>IPFIX@ietf.org
>
>https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>


From carter@qosient.com  Tue Mar 13 20:38:41 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0FC21F849C for ; Tue, 13 Mar 2012 20:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.262
X-Spam-Level: 
X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnWOir-cVNnE for ; Tue, 13 Mar 2012 20:38:39 -0700 (PDT)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id B0EF621F8499 for ; Tue, 13 Mar 2012 20:38:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 21F0F28592; Tue, 13 Mar 2012 23:38:32 -0400 (EDT)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 13CE728590; Tue, 13 Mar 2012 23:38:31 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_B1DB8416-FACA-412D-8925-3D3A93E79E8B"; protocol="application/pkcs7-signature"; micalg=sha1
From: Carter Bullard 
In-Reply-To: 
Date: Tue, 13 Mar 2012 23:38:29 -0400
Message-Id: <0273AB96-7743-419B-872B-A1DF8C68A603@qosient.com>
References: 
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1257)
Cc: Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 03:38:41 -0000

--Apple-Mail=_B1DB8416-FACA-412D-8925-3D3A93E79E8B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E6F29CE3-99A9-43EA-ACB6-D553A60C2D9D"


--Apple-Mail=_E6F29CE3-99A9-43EA-ACB6-D553A60C2D9D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1250

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=85,  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.=20

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


--Apple-Mail=_E6F29CE3-99A9-43EA-ACB6-D553A60C2D9D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1250


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/f=
ile-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" =
<carter@qosient.com> =
wrote:

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
150 =
E. 57th Street Suite 12D
New =
York, New York 10022

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





On Mar 1, 2012, =
at 12:16 PM, Carter Bullard wrote:


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
150 =
E. 57th Street Suite 12D
New =
York, New York 10022

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



On Mar 1, 2012, =
at 11:36 AM, Carter Bullard wrote:


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" <carter@qosient.com> =
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



=8A and =
prediction of flow statistics from sampled packet =8A - 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



IPFIX@ietf.org



https://www.ietf.org/=
mailman/listinfo/ipfix









-- =


------------------------------------------------------------=
---------

Nevil Brownlee =
            &n=
bsp;      Computer Science Department | =
ITS

Phone: +64 9 373 7599 x88941 =
            Th=
e University of Auckland

FAX: +64 9 373 =
7453   Private Bag 92019, Auckland 1142, New =
Zealand























_______________________________________________

IPFIX mailing list

IPFIX@ietf.org

https://www.ietf.org/=
mailman/listinfo/ipfix





_______________________________________________

IPFIX mailing list

IPFIX@ietf.org

https://www.ietf.org/=
mailman/listinfo/ipfix



_______________________________________________
IPFIX mailing =
list
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix







=

--Apple-Mail=_E6F29CE3-99A9-43EA-ACB6-D553A60C2D9D--

--Apple-Mail=_B1DB8416-FACA-412D-8925-3D3A93E79E8B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDAzMzgzMFowIwYJKoZIhvcNAQkE
MRYEFNsr31B1sRGNIAZzLSsbFgE4muGqMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
AF3tXHrHZsMYqTNUX52Pv5TlcjuVkjFrecyxsagqwo/gvBbYPGyfqJl02yki16mUncuUxXmfo3eX
itFfm2txuYB7MNuqIEHmCrs9nX2YykI3D8Y1bjYwM/wyaJmnEcyvol2bz47G04fsApLFnJidYhip
gT5UE5hCuIzbVTetvhuSQyVElYQTqV+9ulHZRTkNTLQFL8GFf2kiUUawdMFMOKgOoApQsfn3MKL8
e1JFnmJQdPz/yX25EHfXU9OdEe47xNclvF/vZp004jD/5YKdacC3LgSqi4hckJuKpKjJzgbf9b/2
3KCnr4l/0Nh8ExouVAMnkggEZlT2YhMrNEMJFvkAAAAAAAA=

--Apple-Mail=_B1DB8416-FACA-412D-8925-3D3A93E79E8B--

From trammell@tik.ee.ethz.ch  Wed Mar 14 06:17:40 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FE521F8513 for ; Wed, 14 Mar 2012 06:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gokGtEX-bvZp for ; Wed, 14 Mar 2012 06:17:40 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C189421F84EB for ; Wed, 14 Mar 2012 06:17:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E041BD9307; Wed, 14 Mar 2012 14:17:38 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IjJd0Rmz3GRs; Wed, 14 Mar 2012 14:17:38 +0100 (MET)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8C298D9305; Wed, 14 Mar 2012 14:17:38 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1250
From: Brian Trammell 
In-Reply-To: <0273AB96-7743-419B-872B-A1DF8C68A603@qosient.com>
Date: Wed, 14 Mar 2012 14:17:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <0273AB96-7743-419B-872B-A1DF8C68A603@qosient.com>
To: Carter Bullard 
X-Mailer: Apple Mail (2.1257)
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 13:17:41 -0000

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=20=

with respect to BCP 78), we make no representation that the document=20
describes an original _invention_ at all; I'm therefore somewhat =
confused=20
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.
>=20
> However, BCP 78 states clearly that the authors, because they are
> explicitly granting rights to the IETF regarding use, derivative works
> etc=85,  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.=20
>=20
> 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.
>=20
> Carter
>=20
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E. 57th Street Suite 12D
> New York, New York 10022
>=20
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>=20
>=20
>=20
> On Mar 13, 2012, at 10:01 PM, Juergen Quittek wrote:
>=20
>> Hi Carter,
>>=20
>> Thank you for pointing to potential issues with patents on
>> draft-ietf-ipfix-a9n.
>>=20
>> 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 .
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> You suggested to check if Avaya is holding some of these patents
>> by now.  Dan Romascanu volunteered to to so.
>>=20
>> Thanks,
>>    Juergen


From ietf-ipr@ietf.org  Thu Mar 15 08:42:01 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C00421F8757; Thu, 15 Mar 2012 08:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.417
X-Spam-Level: 
X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtwedaSARFXT; Thu, 15 Mar 2012 08:42:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BA121F8750; Thu, 15 Mar 2012 08:42:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IETF Secretariat 
To: arno@wagner.name, bclaise@cisco.com, trammell@tik.ee.ethz.ch
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120315154201.14125.86357.idtracker@ietfa.amsl.com>
Date: Thu, 15 Mar 2012 08:42:01 -0700
X-Mailman-Approved-At: Thu, 15 Mar 2012 09:03:42 -0700
Cc: ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz, ipr-announce@ietf.org
Subject: [IPFIX] IPR Disclosure: Avaya Inc. 's Statement about IPR related to	draft-ietf-ipfix-a9n-03
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 15:42:01 -0000

Dear Arno Wagner, Benoit Claise, Brian Trammell:

 An IPR disclosure that pertains to your Internet-Draft entitled "Flow
Aggregation for the IP Flow Information Export (IPFIX) Protocol" (draft-iet=
f-
ipfix-a9n) was submitted to the IETF Secretariat on 2012-03-15 and has been
posted on the "IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/1715/). The title of the IPR disclosure is
"Avaya Inc. 's Statement about IPR related to draft-ietf-ipfix-a9n-03."");

The IETF Secretariat


From n.brownlee@auckland.ac.nz  Sat Mar 17 00:32:48 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9829921F8610 for ; Sat, 17 Mar 2012 00:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7mtsqEi327Q for ; Sat, 17 Mar 2012 00:32:48 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF6721F8667 for ; Sat, 17 Mar 2012 00:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1331969567; x=1363505567; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=2utAlNK6v6jYa2QEeDwQUCGkHvSk2KG7I/+o48NolH0=; b=BW5Q6H5qjt4jWMUaoJrMahceq5DZODkRRixdaAz2iIZTb53gV0sHCEUe M9b2NlmJltdTsAOLXMz+d//U64W7AYMEMWU/Z6Ko/UsiUSOJllxrJt07W bW1ZSRrz5ls33c6ryFenL8NNyYK/rbdifobasFFo2N9XJ0ZMhXr9LwP8g o=;
X-IronPort-AV: E=Sophos;i="4.73,602,1325415600"; d="scan'208";a="110463702"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 78.142.168.245 - Outgoing - Outgoing-SSL
Received: from unknown (HELO [192.168.2.14]) ([78.142.168.245]) by mx2-int.auckland.ac.nz with ESMTP; 17 Mar 2012 20:32:43 +1300
Message-ID: <4F643E10.2000008@auckland.ac.nz>
Date: Sat, 17 Mar 2012 00:32:32 -0700
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: IPFIX list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Darkspace and UnSolicited Traffic Analysis (DUST)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 07:32:48 -0000

Hi IPFIXers:

If you're interested in this topic, CAIDA are holding a workshop to
discuss it this May, see
     http://www.caida.org/workshops/dust/1205/

Cheers, Nevil

-- 
---------------------------------------------------------------------
  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


From ietf-ipr@ietf.org  Tue Mar 20 10:15:08 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0621F872E; Tue, 20 Mar 2012 10:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level: 
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rELFe2qgrgG6; Tue, 20 Mar 2012 10:15:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D3621F8559; Tue, 20 Mar 2012 10:15:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IETF Secretariat 
To: arno@wagner.name, bclaise@cisco.com, trammell@tik.ee.ethz.ch
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120320171507.6867.50213.idtracker@ietfa.amsl.com>
Date: Tue, 20 Mar 2012 10:15:07 -0700
Cc: ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz, ipr-announce@ietf.org
Subject: [IPFIX] IPR Disclosure: Cisco's Statement of IPR Related to	draft-ietf-ipfix-a9n-03
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Mar 2012 17:15:08 -0000

Dear Arno Wagner, Benoit Claise, Brian Trammell:

 An IPR disclosure that pertains to your Internet-Draft entitled "Flow
Aggregation for the IP Flow Information Export (IPFIX) Protocol" (draft-iet=
f-
ipfix-a9n) was submitted to the IETF Secretariat on 2012-03-19 and has been
posted on the "IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/1726/). The title of the IPR disclosure is
"Cisco's Statement of IPR Related to draft-ietf-ipfix-a9n-03."");

The IETF Secretariat


From dromasca@avaya.com  Wed Mar 21 09:42:21 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6721E804D for ; Wed, 21 Mar 2012 09:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.868
X-Spam-Level: 
X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoVRcyecOwGh for ; Wed, 21 Mar 2012 09:42:21 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1322A21E805E for ; Wed, 21 Mar 2012 09:42:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKMEak+HCzI1/2dsb2JhbABEtn+BB4ILAQEDEh4KMSABFRUGDAwHVwEEGxqHaJdehBucHpAeYwSbbooYgmg
X-IronPort-AV: E=Sophos;i="4.73,624,1325480400";  d="scan'208";a="615279"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Mar 2012 12:41:58 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Mar 2012 12:26:22 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Mar 2012 17:41:52 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD review of draft-ietf-ipfix-flow-selection-tech-10.txt
Thread-Index: Ac0HgYT2PNNa/4XrS9iDIJxRD2mpEw==
From: "Romascanu, Dan (Dan)" 
To: "IETF IPFIX Working Group" 
Subject: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-10.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 16:42:21 -0000

Please find below the AD review of
draft-ietf-ipfix-flow-selection-tech-10.txt.=20

The document is in a good enough shape to be sent to IETF LC. Please
consider my comments together with the other IETF LC comments.=20

The comments are divided into T (Technical) and E (Editorial).=20

T1. In section 5.1.2:=20

   Nevertheless there MAY be the incentive to apply Hash-
   based Flow Filtering not on the packet level during the Metering
   Process, for example when the size of the selection range and
   therefore the sampling probability is dependent on the number of
   observed flows.

I think that the usage of a capitalized RFC 2119 MAY is not justified
here.=20

T2. In section 6.1 please provide references for the hash functions
mentioned as possible functions.

T3. In section 7:=20

   In this section we describe Information Elements (IEs) that SHOULD be
   exported by a flow selection process in order to support the
   interpretation of measurement results from flow measurements where
   only some flows are selected. =20

Why is this a SHOULD and not a MUST? What are the exception cases?=20

T4. Also in section 7:=20

   All counters SHOULD be exported and reset when a new
   measurement interval starts.

Why is this a SHOULD and not a MUST? What are the exception cases? Are
exporting counters and reset of counters independent, in other words can
some counters be exported but not reset when a new measurement interval
starts?=20

T5. Where are allocated all the IDs marked as TBD in the table in
Section 7? I do not see a request for allocation in the IANA
considerations section. What am I missing?

T6. Even if configuration methods and protocols are out of the scope of
this document I believe that this statement in the Security
Considerations section is not sufficient:=20

   Nevertheless, a full analysis and assessment of threats for
   configuration and reporting has to be done if configuration or
   reporting methods are proposed.

I think that this document needs at least make a complete assessment of
the threats and place requirements in the configuration and reporting
methods to be later defined.=20


E1. Three of the missing references prompted up by idnits seem to be
indeed missing references:=20

  =3D=3D Missing Reference: 'RFC5226' is mentioned on line 868, but not
     defined
     'administered by IANA and are subject to Expert Review [RFC5226...'

  =3D=3D Missing Reference: 'I-D.dkcm-ipfix-rfc5815bis' is mentioned on =
line
     1330, but not defined
     'according to the procedures set forth in
[I-D.dkcm-ipfix-rfc5815b...'

  =3D=3D Missing Reference: 'GoRe07' is mentioned on line 1372, but not
     defined
'[GoRe07]....'


E2. Drop the comma from 'The reason is, that flow-state dependent ...'

E3. Section 5.2.1:

Systematic sampling MAY BE applied during the Metering
   Process.

BE needs not be capitalized.=20

E4. It would be useful to nuumber the Tables in the document like the
one in Section 6, for later references in other documents.=20


Regards,

Dan


From iesg-secretary@ietf.org  Thu Mar 22 00:37:03 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D90021F8649; Thu, 22 Mar 2012 00:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SieXedu6lRz; Thu, 22 Mar 2012 00:37:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E5421F8646; Thu, 22 Mar 2012 00:37:02 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120322073702.8254.33467.idtracker@ietfa.amsl.com>
Date: Thu, 22 Mar 2012 00:37:02 -0700
Cc: ipfix@ietf.org
Subject: [IPFIX] Last Call:  (Flow	Selection Techniques) to Proposed Standard
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 07:37:03 -0000

The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Flow Selection Techniques'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-04-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Flow selection is the process of selecting a subset of flows from all
   observed flows.  The Flow Selection Process may be located at an
   observation point, or on an IPFIX Mediator.  Flow selection reduces
   the effort of post-processing flow data and transferring Flow
   Records.  This document describes motivations for flow selection and
   presents flow selection techniques.  It provides an information model
   for configuring flow selection techniques and discusses what
   information about a flow selection process should be exported.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1540/




From wwwrun@rfc-editor.org  Sat Mar 24 11:15:32 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B8621F85FC; Sat, 24 Mar 2012 11:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.157
X-Spam-Level: 
X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8icnKuczNS3D; Sat, 24 Mar 2012 11:15:32 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66821F8604; Sat, 24 Mar 2012 11:15:32 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 8327D72ED05; Sat, 24 Mar 2012 11:14:21 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120324181421.8327D72ED05@rfc-editor.org>
Date: Sat, 24 Mar 2012 11:14:21 -0700 (PDT)
Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] RFC 6526 on IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Mar 2012 18:15:32 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6526

        Title:      IP Flow Information Export (IPFIX) 
                    Per Stream Control Transmission Protocol (SCTP) 
                    Stream 
        Author:     B. Claise, P. Aitken,
                    A. Johnson, G. Muenz
        Status:     Standards Track
        Stream:     IETF
        Date:       March 2012
        Mailbox:    bclaise@cisco.com, 
                    paitken@cisco.com, 
                    andrjohn@cisco.com,  muenz@net.in.tum.de
        Pages:      23
        Characters: 51285
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ipfix-export-per-sctp-stream-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6526.txt

This document specifies an extension to the specifications
in RFC 5101, IP Flow Information Export (IPFIX), when using
the Partial Reliability extension of SCTP (PR-SCTP, Partial
Reliability Stream Control Transmission Protocol).

When implemented at both the Exporting Process and Collecting Process,
this method offers several advantages, such as the ability to
calculate Data Record losses for PR-SCTP per Template, immediate export of
Template Withdrawal Messages, immediate reuse of Template IDs
within an SCTP stream, reduced likelihood of Data Record loss,
and reduced demands on the Collecting Process.  When implemented
in only the Collecting Process or Exporting Process, then normal IPFIX
behavior will be seen without all of the additional benefits.  
[STANDARDS-TRACK]

This document is a product of the IP Flow Information Export Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From kashima@nttv6.net  Sun Mar 25 11:13:09 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ACF21E8013 for ; Sun, 25 Mar 2012 11:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZK+djzCNiQY for ; Sun, 25 Mar 2012 11:13:08 -0700 (PDT)
Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 496FA21E800C for ; Sun, 25 Mar 2012 11:13:02 -0700 (PDT)
Received: from [10.60.227.219] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q2PIDi3Z055721 for ; Mon, 26 Mar 2012 03:13:44 +0900 (JST) (envelope-from kashima@nttv6.net)
Date: Mon, 26 Mar 2012 03:11:39 +0900
From: Shingo KASHIMA 
To: ipfix@ietf.org
Message-Id: <20120326031139.8285.1AB7FA03@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Mailer: Becky! ver. 2.57.01 [ja]
Subject: [IPFIX] Fw: New Version Notification for draft-kashima-ipfix-data-link-layer-monitoring-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 18:13:09 -0000

Hi IPFIXer,

I posted  draft-kashima-ipfix-data-link-layer-monitoring-07.
http://tools.ietf.org/html/draft-kashima-ipfix-data-link-layer-monitoring-07
Soon this draft will be draft-ietf-ipfix-data-link-layer-monitoring-00.

The differences from -06 are as follows:

  - adding "the relationship between Ethernet header filelds and
    Information Elements " in section 6,
    according to the comment raised by Laxmi Mukund.

  - adding new Information Elements related to octet counter and
    packet length for layer 2 in section 3.11 - 3.24

Best Regards,
Shingo.

Forwarded by Shingo KASHIMA 
----------------------- Original Message -----------------------
From:    internet-drafts@ietf.org
To:      kashima@nttv6.net
Date:    Mon, 12 Mar 2012 13:02:52 -0700
Subject: New Version Notification for draft-kashima-ipfix-data-link-layer-monitoring-07.txt
----

A new version of I-D, draft-kashima-ipfix-data-link-layer-monitoring-07.txt has been successfully submitted by Shingo Kashima and posted to the IETF repository.

Filename:	 draft-kashima-ipfix-data-link-layer-monitoring
Revision:	 07
Title:		 Information Elements for Data Link Layer Traffic Measurement
Creation date:	 2012-03-12
WG ID:		 Individual Submission
Number of pages: 34

Abstract:
   This document describes Information Elements related to data link
   layer.  They are used by the IP Flow Information Export (IPFIX)
   protocol for encoding measured data link layer traffic information.

                                                                                  


The IETF Secretariat
--------------------- Original Message Ends --------------------


From hs@123.org  Mon Mar 26 01:46:51 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6182921F84DE for ; Mon, 26 Mar 2012 01:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O0Uy9Q1Jt1s for ; Mon, 26 Mar 2012 01:46:50 -0700 (PDT)
Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5964121F84AA for ; Mon, 26 Mar 2012 01:46:49 -0700 (PDT)
X-RZG-AUTH: :JH8HfU+kYd9xQ6m0ynnj9hHxvZXYXks+pm8dQxa2PdmCs29qNiFcVPCDoyjkieY9bbqiT4QWmOnEENFFtAToAZ2VyaGx
X-RZG-CLASS-ID: mo05
Received: from [IPv6:2001:df8:0:16:a288:b4ff:fec4:e230] ([2001:df8:0:16:a288:b4ff:fec4:e230]) by smtp.strato.de (fruni mo49) (RZmta 28.2 AUTH) with ESMTPA id Y06e6fo2Q7p8cS for ; Mon, 26 Mar 2012 10:46:44 +0200 (MEST)
Message-ID: <4F702CF4.4040203@123.org>
Date: Mon, 26 Mar 2012 10:46:44 +0200
From: Hendrik Scholz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: ipfix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] initial draft for RTP message transport in IPFIX
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 08:46:51 -0000

Hi!

Some time ago I submitted an initial draft describing the transport
of RTP media stream (quality) information in IPFIX packets.

The announcement is here:
http://www.ietf.org/mail-archive/web/i-d-announce/current/msg42805.html
and the draft is named draft-scholz-ipfix-rtp-msg-00

I believe this is part of a larger set of documents, namely the
draft-trammell-ipfix-sip-msg draft and a third yet to be written 
correlation draft to map between SIP packets/sessions in IPFIX and the 
RTP media streams as described by the -rtp-msg draft.

I would like to get your feedback on the content, esp on the
transport of the media quality.
draft-wu-xrblock-rtcp-xr-quality-monitoring-08 has a mechanism
to convey the type of MOS, the calculation algorithm and the actual
values.
Should we use the same mechanism?

There is a list of open TODOs in section 12 of the document.

Cheers,
  Hendrik

-- 
Hendrik Scholz 

From aakhter@cisco.com  Mon Mar 26 02:04:13 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDFF21F854D for ; Mon, 26 Mar 2012 02:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.599
X-Spam-Level: 
X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS2ZElotJL7z for ; Mon, 26 Mar 2012 02:04:13 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDFD21F8516 for ; Mon, 26 Mar 2012 02:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3478; q=dns/txt; s=iport; t=1332752653; x=1333962253; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Xj71T27lgqOy3gDWiJ92MF+L0ZU0n+NxS3Xcro+kXi0=; b=AjPmlBhbTWkAReVZ4PRVNI2F0YUXIQe4P5S9/Tg5/ot6DP+9apGMx6uP YvAXs9DX4NXGbdzaJvzomE4Ed/vYvgLkI0nJXlmuXk0jV5Mia3v4Y+iSH BSoUHuJGzHXy7VwdGH7pN/vq21l3Ialr0SnMfnPTcoSXpJo/dWrLOtrcg c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAEwwcE+tJV2d/2dsb2JhbABEuDCBB4IJAQEBBAEBAQ8BHQotBwQFDgQCAQgRAwEBAQsGFwEGASYfCQgBAQQBEggah2gLmgueO5BFYwSIV44ajTSBaIMF
X-IronPort-AV: E=Sophos;i="4.73,649,1325462400"; d="scan'208";a="66330693"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 26 Mar 2012 09:04:12 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2Q94Cb8029247;  Mon, 26 Mar 2012 09:04:12 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 26 Mar 2012 04:04:12 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 04:04:09 -0500
Message-ID: <7F298ACC76CC154F832B6D02852D169F078D56C7@XMB-RCD-101.cisco.com>
In-Reply-To: <20120326031139.8285.1AB7FA03@nttv6.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Fw: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-07.txt
thread-index: Ac0KsvHvkl9Req3EQSW6kiOL3bEjVgAdTWPQ
References: <20120326031139.8285.1AB7FA03@nttv6.net>
From: "Aamer Akhter (aakhter)" 
To: "Shingo KASHIMA" , 
X-OriginalArrivalTime: 26 Mar 2012 09:04:12.0384 (UTC) FILETIME=[696EA600:01CD0B2F]
Subject: Re: [IPFIX] Fw: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 09:04:14 -0000

Hi Shingo,


Please find my comments regarding
draft-kashima-ipfix-data-link-layer-monitoring-07 below:


Sec 2.3
 - given the section context it might be worthwhile to mention LAG
connections and how these can be tracked using the
ingressPhysicalInterface and egressPhysicalInterface.=20
- it is unclear what this section means for IPFIX information elements.
(perhaps none?)

Sec 3.1
- would it be possible to add a 'units' field? I think dataLinkFrameSize
is to be expressed in bytes, but let's be explicit.

Sec 3.2
- given the provider and customer l2 spans, does it make sense to
further refine what is meant by ' carries n octets from the data link
frame
      of a selected frame'

Sec 3.5
- It's not clear to me what sectionObservedOctets is actually reporting
on.=20

3.12. postMCastL2OctetDeltaCount
- Is the L2 mcast behavior any different (in this area for reporting)
for 802.1Qbh rather than traditional L2 bridges? (I don't know the
answer for sure.) I think we just need to make sure that both cases
(802.1Qbh and regular bridges can use this field.=20

3.17. droppedL2OctetDeltaCount
- I think this is also referring to policy drops (for example done by
relay in 802.1Qbh), not just regular drops (QoS, broadcast suppression
etc.) Is the 802.1Qbh case to be handled in any special way?=20

3.19 and 3.20 description is exactly the same (copy and paste error?)


-----Original Message-----
From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
Of Shingo KASHIMA
Sent: Sunday, March 25, 2012 2:12 PM
To: ipfix@ietf.org
Subject: [IPFIX] Fw: New Version Notification
fordraft-kashima-ipfix-data-link-layer-monitoring-07.txt


Hi IPFIXer,

I posted  draft-kashima-ipfix-data-link-layer-monitoring-07.
http://tools.ietf.org/html/draft-kashima-ipfix-data-link-layer-monitorin
g-07
Soon this draft will be draft-ietf-ipfix-data-link-layer-monitoring-00.

The differences from -06 are as follows:

  - adding "the relationship between Ethernet header filelds and
    Information Elements " in section 6,
    according to the comment raised by Laxmi Mukund.

  - adding new Information Elements related to octet counter and
    packet length for layer 2 in section 3.11 - 3.24

Best Regards,
Shingo.

Forwarded by Shingo KASHIMA 
----------------------- Original Message -----------------------
From:    internet-drafts@ietf.org
To:      kashima@nttv6.net
Date:    Mon, 12 Mar 2012 13:02:52 -0700
Subject: New Version Notification for
draft-kashima-ipfix-data-link-layer-monitoring-07.txt
----

A new version of I-D,
draft-kashima-ipfix-data-link-layer-monitoring-07.txt has been
successfully submitted by Shingo Kashima and posted to the IETF
repository.

Filename:	 draft-kashima-ipfix-data-link-layer-monitoring
Revision:	 07
Title:		 Information Elements for Data Link Layer Traffic
Measurement
Creation date:	 2012-03-12
WG ID:		 Individual Submission
Number of pages: 34

Abstract:
   This document describes Information Elements related to data link
   layer.  They are used by the IP Flow Information Export (IPFIX)
   protocol for encoding measured data link layer traffic information.

=20



The IETF Secretariat
--------------------- Original Message Ends --------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

From internet-drafts@ietf.org  Mon Mar 26 02:04:36 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7018921F85F0; Mon, 26 Mar 2012 02:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level: 
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTy7ItRwJ56F; Mon, 26 Mar 2012 02:04:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A20C21F85E5; Mon, 26 Mar 2012 02:04:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120326090436.19632.36210.idtracker@ietfa.amsl.com>
Date: Mon, 26 Mar 2012 02:04:36 -0700
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-rfc5815bis-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 09:04:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Definitions of Managed Objects for IP Flow Information E=
xport
	Author(s)       : Thomas Dietz
                          Atsushi Kobayashi
                          Benoit Claise
                          Gerhard Muenz
	Filename        : draft-ietf-ipfix-rfc5815bis-03.txt
	Pages           : 69
	Date            : 2012-03-26

   This document defines managed objects for IP Flow Information eXport
   (IPFIX).  These objects provide information for monitoring IPFIX
   Exporters and IPFIX Collectors including the basic configuration
   information.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-03.txt


From iesg-secretary@ietf.org  Mon Mar 26 02:31:18 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B30621F8601; Mon, 26 Mar 2012 02:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmgTlpma-AKZ; Mon, 26 Mar 2012 02:31:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791F921F8603; Mon, 26 Mar 2012 02:31:17 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120326093117.27675.12733.idtracker@ietfa.amsl.com>
Date: Mon, 26 Mar 2012 02:31:17 -0700
Cc: ipfix chair , ipfix mailing list , RFC Editor 
Subject: [IPFIX] Protocol Action: 'Definitions of Managed Objects for IP Flow	Information Export' to Proposed Standard	(draft-ietf-ipfix-rfc5815bis-03.txt)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 09:31:18 -0000

The IESG has approved the following document:
- 'Definitions of Managed Objects for IP Flow Information Export'
  (draft-ietf-ipfix-rfc5815bis-03.txt) as a Proposed Standard

This document is the product of the IP Flow Information Export Working
Group.

The IESG contact persons are Dan Romascanu and Ronald Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ipfix-rfc5815bis/




Technical Summary

   This document defines managed objects for IP Flow Information eXport
   (IPFIX).  These objects provide information for monitoring IPFIX
   Exporters and IPFIX Collectors including the basic configuration
   information.

Working Group Summary

   This is a minor update of RFC 5815. Changes concern the registration
   method of IPFIX packet selector functions by IANA and the
   Integration of errata filed for RFC 5815. The update is included
   in the current WG charter. The update was discussed at several
   WG meetings and on the mailing list.

Document Quality

   The document is a minor updates of RFC5815. The document underwent
   a WG last call in the IPFIX WG in order to maintain the quality
   that RFC 5815 already has.

Personnel

   Juergen Quittek is shepherding this document. Dan Romascanu is the
   responsible area director. 

RFC Editor Note

   Please add to the header of the document 'Obsoletes RFC 5815 when approved'. 



From HKaplan@acmepacket.com  Mon Mar 26 13:29:51 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF621E80E1 for ; Mon, 26 Mar 2012 13:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.316
X-Spam-Level: 
X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trswPW40wrAW for ; Mon, 26 Mar 2012 13:29:50 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 857EB21E800E for ; Mon, 26 Mar 2012 13:29:46 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 26 Mar 2012 16:29:45 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 16:29:45 -0400
From: Hadriel Kaplan 
To: Hendrik Scholz 
Thread-Topic: comments on draft-scholz-ipfix-rtp-msg-00
Thread-Index: AQHNC48uVrbMCL91AkquL/bmeS14cA==
Date: Mon, 26 Mar 2012 20:29:45 +0000
Message-ID: <7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com>
References: <4F702CF4.4040203@123.org>
In-Reply-To: <4F702CF4.4040203@123.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0B35C051E1E4DB40BAB39CADDAAA7D0E@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 20:29:51 -0000

Howdy,
I read draft-scholz-ipfix-rtp-msg-00 and have some initial comments, mostly=
 at a high level for now instead of per-IE.

1) From a IPFIX IANA allocation perspective, it makes sense to get IANA-ass=
igned IE numbers for things that could be exported from different vendors, =
instead of using PENs.  Quite a few of the IEs in this draft are fairly ven=
dor-specific, however.  I mean in the sense that few media-monitoring vendo=
rs report the same type of information as in this draft.  I think there is =
some commonality across vendors, but it's a smaller list.  How do you want =
to handle that?  Do we get in a room and agree on a common list?

2) Some of the IEs in here imply the IPFIX records could be generated per-R=
TP packet.  I don't think you want to do that.  Some media-monitoring syste=
ms handle multiple millions of RTP packets per second.=20

3) Some of the IEs imply there's a single SSRC for a flow - are you assumin=
g a flow is by definition the 6-tuple of IP src/dest, port src/dest, transp=
ort type, and SSRC?  In other words, if there are two or more SSRCs in the =
same 5-tuple, would they be separate IPFIX flows? (they're only one "RTP" s=
ession from an RTP and SDP perspective)

-hadriel


From hendrik.scholz@voipfuture.com  Tue Mar 27 04:33:40 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE30621F89AE for ; Tue, 27 Mar 2012 04:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level: 
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEii15u6tX+g for ; Tue, 27 Mar 2012 04:33:40 -0700 (PDT)
Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93321F89AD for ; Tue, 27 Mar 2012 04:33:34 -0700 (PDT)
X-Footer: dm9pcGZ1dHVyZS5jb20=
Received: from [172.17.0.230] ([31.18.170.85]) (authenticated user hscholz@voipfuture.com) by mail.voipfuture.com (Kerio Connect 7.3.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Tue, 27 Mar 2012 13:25:50 +0200
Message-ID: <4F71A577.5000105@voipfuture.com>
Date: Tue, 27 Mar 2012 13:33:11 +0200
From: Hendrik Scholz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4F702CF4.4040203@123.org> <7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com>
In-Reply-To: <7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 11:33:41 -0000

Hi Hadriel,

On 03/26/2012 10:29 PM, Hadriel Kaplan wrote:
> 1) From a IPFIX IANA allocation perspective, it makes sense to get IANA-assigned IE numbers for things that could be exported from different vendors, instead of using PENs.  Quite a few of the IEs in this draft are fairly vendor-specific, however.  I mean in the sense that few media-monitoring vendors report the same type of information as in this draft.  I think there is some commonality across vendors, but it's a smaller list.  How do you want to handle that?  Do we get in a room and agree on a common list?

I'd be happy to separate the information elements into the ones that
are relevant to (or can be generated by) a larger audience and the more 
specific ones. Brian also mentioned something in this direction.

> 2) Some of the IEs in here imply the IPFIX records could be generated per-RTP packet.  I don't think you want to do that.  Some media-monitoring systems handle multiple millions of RTP packets per second.

Per-RTP packet record generation is not intended but it must be
possible to generate flow records for sections (e.g. 10 seconds)
of an RTP stream. In case of transient problems a higher
granularity will show isolated issues (e.g. a short period
of packet loss).
The records should allow mediators (or collectors) to aggregate
data from multiple records into a longer RTP stream.
So as a worst-case an IPFIX recording describing a single RTP
packet is possible but should not be the default.
The same mechanism should also apply to the -sip-msg records.
It should be possible to describe the outline of a session
as well as push a single SIP message for troubleshooting applications.

> 3) Some of the IEs imply there's a single SSRC for a flow - are you assuming a flow is by definition the 6-tuple of IP src/dest, port src/dest, transport type, and SSRC?  In other words, if there are two or more SSRCs in the same 5-tuple, would they be separate IPFIX flows? (they're only one "RTP" session from an RTP and SDP perspective)

Yes, a separate SSRC in between two nodes should be recorded
in separate records. After all these streams would most likely
belong to separate calls.

Also note that draft-akhter-opsawg-perfmon-ipfix-02 is available
and I duplicated some of the work done by Aamer.

Cheers,
  Hendrik

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email hendrik.scholz@voipfuture.com   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086


From HKaplan@acmepacket.com  Tue Mar 27 14:41:01 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C041021E8122 for ; Tue, 27 Mar 2012 14:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level: 
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y8MoiyptK7d for ; Tue, 27 Mar 2012 14:41:01 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5321E8011 for ; Tue, 27 Mar 2012 14:41:01 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 17:40:59 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 17:40:59 -0400
From: Hadriel Kaplan 
To: Hendrik Scholz 
Thread-Topic: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
Thread-Index: AQHNDGJL4V0jkuyb8U2R3E7hSp6bfg==
Date: Tue, 27 Mar 2012 21:40:58 +0000
Message-ID: <90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com>
References: <4F702CF4.4040203@123.org> <7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com> <4F71A577.5000105@voipfuture.com>
In-Reply-To: <4F71A577.5000105@voipfuture.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2FCCFAD111C1CC4EAEAF01372AB6762E@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 21:41:01 -0000

On Mar 27, 2012, at 1:33 PM, Hendrik Scholz wrote:

>> 3) Some of the IEs imply there's a single SSRC for a flow - are you assu=
ming a flow is by definition the 6-tuple of IP src/dest, port src/dest, tra=
nsport type, and SSRC?  In other words, if there are two or more SSRCs in t=
he same 5-tuple, would they be separate IPFIX flows? (they're only one "RTP=
" session from an RTP and SDP perspective)
>=20
> Yes, a separate SSRC in between two nodes should be recorded
> in separate records. After all these streams would most likely
> belong to separate calls.

As much as I'd love for that to be the case, technically they might or migh=
t not.  For normal voice between two users it's always the case.  But RFC 3=
550 always supported separate SSRCs in the same RTP session and thus in the=
 same 5-tuple, and RTCWeb and CLUE Working Groups have both been talking ab=
out using that ability. (so for example video from multiple cameras goes in=
 the same RTP session, with separate SSRCs)  At least that's what I believe=
 they're thinking of.  And of course even for a normal voice call there cou=
ld be an SSRC collision, changing the SSRC mid-call.

I'm ok with assuming one, just wondering what we do if we get a second one.=
  I think you're saying we should treat is as a separate flow from an IPFIX=
 reporting perspective, right?

-hadriel


From aakhter@cisco.com  Tue Mar 27 15:57:00 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E4F21E8147 for ; Tue, 27 Mar 2012 15:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.069
X-Spam-Level: 
X-Spam-Status: No, score=-109.069 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, LONGWORDS=1.803, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEHK3eV5ZHYb for ; Tue, 27 Mar 2012 15:56:59 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA7221E80B9 for ; Tue, 27 Mar 2012 15:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=3555; q=dns/txt; s=iport; t=1332889019; x=1334098619; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=L/xKF0sur6MDOx9XfHyQSP9cAh3vfCZeRsTMx4DJDpI=; b=RYW6xvNcP5AMui6/AhPdyetniIM0VGr2quPT7ugHBleu49r8KY7E4TOB OPmIONezOUwukAPTMP6ASIHIymvVC1yLwvGCZcqU11/6JAQmVlVncbZDK AxMnO6EJm58cS1lICwgxh29IuEuuVxjC9QOMRGa3EZCaONV6A837Jas7w Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOdEck+tJV2b/2dsb2JhbABDuG6BB4IJAQEBAwEBAQEPAR0KNAsMBAIBCA4DBAEBCwYXAQYBJh8JCAIEARIIGodjBQuedZcaBJAsYwSIWJtOgWiDBQ
X-IronPort-AV: E=Sophos;i="4.73,659,1325462400"; d="scan'208";a="69929761"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 27 Mar 2012 22:56:58 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2RMuwKR010029;  Tue, 27 Mar 2012 22:56:58 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 27 Mar 2012 17:56:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Mar 2012 17:56:52 -0500
Message-ID: <7F298ACC76CC154F832B6D02852D169F079F3D37@XMB-RCD-101.cisco.com>
In-Reply-To: <90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
thread-index: AQHNDGJL4V0jkuyb8U2R3E7hSp6bfpZ+vbwQ
References: <4F702CF4.4040203@123.org><7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com><4F71A577.5000105@voipfuture.com> <90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com>
From: "Aamer Akhter (aakhter)" 
To: "Hadriel Kaplan" , "Hendrik Scholz" 
X-OriginalArrivalTime: 27 Mar 2012 22:56:58.0757 (UTC) FILETIME=[EA1FDB50:01CD0C6C]
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 22:57:00 -0000

Hadriel,

Multiple SSRC within the 5-tuple is how the CTS product line encodes
multiple audio/video channels. Other implementations eg. T3 series use
different 5-tuples.=20

(5-tuple =3D ipsrc, ipdst, iprotocol, l4ports)

" we should treat is as a separate flow from an IPFIX reporting
perspective, right?"

this is exactly what is done in the implementation of:

	draft-akhter-opsawg-perfmon-ipfix
	draft-akhter-opsawg-perfmon-method

In fact, the key fields for the default RTP template (IOS configuration
follows):

    match ipv4 protocol
    match ipv4 source address
    match ipv4 destination address
    match transport source-port
    match transport destination-port
    match transport rtp ssrc

and the collect fields are:

    collect routing forwarding-status
    collect ipv4 dscp
    collect ipv4 ttl
    collect transport packets expected counter
    collect transport packets lost counter
    collect transport packets lost rate
    collect transport event packet-loss counter
    collect transport rtp jitter mean
    collect transport rtp jitter minimum
    collect transport rtp jitter maximum
    collect interface input
    collect interface output
    collect counter bytes
    collect counter packets
    collect counter bytes rate
    collect counter packets dropped
    collect timestamp interval
    collect application media bytes counter
    collect application media bytes rate
    collect application media packets counter
    collect application media packets rate
    collect application media event
    collect monitor event

If the 'rtp ssrc' is not set as a key field, the various metrics form
the differing SSRC flows are aggregated to how a IPFIX 'flow' is
defined.



-----Original Message-----
From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
Of Hadriel Kaplan
Sent: Tuesday, March 27, 2012 5:41 PM
To: Hendrik Scholz
Cc: 
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00


On Mar 27, 2012, at 1:33 PM, Hendrik Scholz wrote:

>> 3) Some of the IEs imply there's a single SSRC for a flow - are you=20
>> assuming a flow is by definition the 6-tuple of IP src/dest, port=20
>> src/dest, transport type, and SSRC?  In other words, if there are two

>> or more SSRCs in the same 5-tuple, would they be separate IPFIX=20
>> flows? (they're only one "RTP" session from an RTP and SDP=20
>> perspective)
>=20
> Yes, a separate SSRC in between two nodes should be recorded in=20
> separate records. After all these streams would most likely belong to=20
> separate calls.

As much as I'd love for that to be the case, technically they might or
might not.  For normal voice between two users it's always the case.
But RFC 3550 always supported separate SSRCs in the same RTP session and
thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have both
been talking about using that ability. (so for example video from
multiple cameras goes in the same RTP session, with separate SSRCs)  At
least that's what I believe they're thinking of.  And of course even for
a normal voice call there could be an SSRC collision, changing the SSRC
mid-call.

I'm ok with assuming one, just wondering what we do if we get a second
one.  I think you're saying we should treat is as a separate flow from
an IPFIX reporting perspective, right?

-hadriel

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

From inacio@cert.org  Wed Mar 28 03:48:54 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA921F8A43 for ; Wed, 28 Mar 2012 03:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.349
X-Spam-Level: 
X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scLTdwkBA6Pr for ; Wed, 28 Mar 2012 03:48:53 -0700 (PDT)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 936D721F8997 for ; Wed, 28 Mar 2012 03:48:53 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id q2SAmnXZ016156; Wed, 28 Mar 2012 06:48:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1332931729; bh=izB7v2vCm06ikReNON7u4IcmHvaCASsDQdsx8ByxYbw=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=IP5FFUYAbpqZQ9vgPVBxso5xq7orJ+NChN82M7XiH6/w35t77NKbdPURcqXKtl/wC BKFTl2gvJJ12iOs1tpvKNr85E9gaVeOdIBdEVIdukheQ9kN5V7M6WmZBSlWH3bD/ZH xJQxw6fKfpkyNO7hcvx7v2uh21aqNTcceHVkSxLg=
Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id q2SAmnxY013400; Wed, 28 Mar 2012 06:48:49 -0400
Received: from EXCHANGE.sei.cmu.edu ([10.64.28.12]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Wed, 28 Mar 2012 06:48:49 -0400
From: Chris Inacio 
To: "ipfix@ietf.org" 
Date: Wed, 28 Mar 2012 06:48:47 -0400
Thread-Topic: draft-claise-export-application-info-in-ipfix-05
Thread-Index: Ac0M0Fq1INu+kbCfT+K58XXKYcMq6Q==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPFIX] draft-claise-export-application-info-in-ipfix-05
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 10:48:54 -0000

http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-05

ClassEngineID + SelectorID - shouldn't this be 32-bits and possible to be s=
hortened using reduced size encoding?  I'm not sure there is any advantage =
to saying you won't know until you see the Engine ID; and seriously, from a=
n implementation point of view; building the decoder, I'm not going to care=
 while parsing the information.  I will only care when doing the human disp=
lay level - when I have to do the lookups.  For the protocol, (on the wire,=
) I prefer a 32-bit field.

I think the reference to the Cisco L7 registry should be removed from the m=
ain body text; and if possible added to some type of appendix.

Is defaulting to TCP for protocol conflicts the best answer?  Why not just =
make it relevant to the transport contained in another IE?

Aren't the IEEE standards you reference, well standards: e.g. normative, no=
t informative?

Can we add the definition of how to get an online registry into the documen=
t, and the XML definition of the registry?  We have all those possible regi=
stry entries - why not define the interchange (lightweight) to get registry=
 of app labels, and an options record to to be to specify its address.

e.g.

Name: applicationRegistry
      Description:
        Specifies a URN where section 8.x well formed application registry =
information may be retrieved.
      Abstract Data Type: string
      Data Type Semantics: URN
      ElementId: 
      Status:
    =20




	
		Cisco
		_date_
	        VER
  		VER
	
	
		
		
		.
		.
		.
	




Then the Cisco specific references within the document above can be moved i=
nto the section related to how to get specific registries.


What missing:

I need data extracted from fields as well; with a big question on how to ef=
ficiently index into it.  I see two possibilities:

(1)  We have a general registry of useful fields (I have no idea how to bui=
ld this even close to comprehensively):
	1 - user
	2 - organization
	3 - command
	4- command path
	5 - =85

and then using structured data, under an application level, you can have so=
mething like application id:
	+--------------+---------------------------------------+
	|    1              | (string) inacio                            |
        +--------------+---------------------------------------+
        |    2              | (string) CERT                            |
        +--------------+---------------------------------------+

for something like an X.509 certificate.

(2) define the fields specifically to the application protocols, which mean=
s extending the registry type information from above:

X.509.user =3D inacio
X.509.org =3D CERT

for example.  But that leads to IE explosion.


Lastly, also, why all the reserved registry numbers?  We're inventing somet=
hing new, aren't we?  ;)

Chris


From HKaplan@acmepacket.com  Wed Mar 28 03:56:06 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9C21F896A for ; Wed, 28 Mar 2012 03:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJW3CY2tbc0W for ; Wed, 28 Mar 2012 03:56:05 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0621F89C7 for ; Wed, 28 Mar 2012 03:56:05 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 06:56:02 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 06:56:02 -0400
From: Hadriel Kaplan 
To: "Aamer Akhter (aakhter)" 
Thread-Topic: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
Thread-Index: AQHNDNFdm5pcXpkw0kaR2dMa2rWSPg==
Date: Wed, 28 Mar 2012 10:56:01 +0000
Message-ID: <13B5187B-06D6-4E44-9E85-D092D3348954@acmepacket.com>
References: <4F702CF4.4040203@123.org><7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com><4F71A577.5000105@voipfuture.com> <90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com> <7F298ACC76CC154F832B6D02852D169F079F3D37@XMB-RCD-101.cisco.com>
In-Reply-To: <7F298ACC76CC154F832B6D02852D169F079F3D37@XMB-RCD-101.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <43ECA6BFD5725746A385B1A9A7FE0135@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 10:56:06 -0000

Makes sense to me.

OK, so as I said in another email, the tricky part about this will be comin=
g up with a consistent set of metrics across vendors, because if it's just =
one vendor's implementation model then it really shouldn't get an IANA-allo=
cated IE number, should it?  It's effectively proprietary and that's what P=
ENs are for, no?  Otherwise we'll be allocating hundreds of IANA-numberspac=
e IEs, different ones for each vendor (my company alone has around few doze=
n different reported fields for RTP/RTCP).

-hadriel
p.s. why are your drafts in OPSAWG?


On Mar 28, 2012, at 12:56 AM, Aamer Akhter (aakhter) wrote:

> Hadriel,
>=20
> Multiple SSRC within the 5-tuple is how the CTS product line encodes
> multiple audio/video channels. Other implementations eg. T3 series use
> different 5-tuples.=20
>=20
> (5-tuple =3D ipsrc, ipdst, iprotocol, l4ports)
>=20
> " we should treat is as a separate flow from an IPFIX reporting
> perspective, right?"
>=20
> this is exactly what is done in the implementation of:
>=20
> 	draft-akhter-opsawg-perfmon-ipfix
> 	draft-akhter-opsawg-perfmon-method
>=20
> In fact, the key fields for the default RTP template (IOS configuration
> follows):
>=20
>    match ipv4 protocol
>    match ipv4 source address
>    match ipv4 destination address
>    match transport source-port
>    match transport destination-port
>    match transport rtp ssrc
>=20
> and the collect fields are:
>=20
>    collect routing forwarding-status
>    collect ipv4 dscp
>    collect ipv4 ttl
>    collect transport packets expected counter
>    collect transport packets lost counter
>    collect transport packets lost rate
>    collect transport event packet-loss counter
>    collect transport rtp jitter mean
>    collect transport rtp jitter minimum
>    collect transport rtp jitter maximum
>    collect interface input
>    collect interface output
>    collect counter bytes
>    collect counter packets
>    collect counter bytes rate
>    collect counter packets dropped
>    collect timestamp interval
>    collect application media bytes counter
>    collect application media bytes rate
>    collect application media packets counter
>    collect application media packets rate
>    collect application media event
>    collect monitor event
>=20
> If the 'rtp ssrc' is not set as a key field, the various metrics form
> the differing SSRC flows are aggregated to how a IPFIX 'flow' is
> defined.
>=20
>=20
>=20
> -----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
> Of Hadriel Kaplan
> Sent: Tuesday, March 27, 2012 5:41 PM
> To: Hendrik Scholz
> Cc: 
> Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
>=20
>=20
> On Mar 27, 2012, at 1:33 PM, Hendrik Scholz wrote:
>=20
>>> 3) Some of the IEs imply there's a single SSRC for a flow - are you=20
>>> assuming a flow is by definition the 6-tuple of IP src/dest, port=20
>>> src/dest, transport type, and SSRC?  In other words, if there are two
>=20
>>> or more SSRCs in the same 5-tuple, would they be separate IPFIX=20
>>> flows? (they're only one "RTP" session from an RTP and SDP=20
>>> perspective)
>>=20
>> Yes, a separate SSRC in between two nodes should be recorded in=20
>> separate records. After all these streams would most likely belong to=20
>> separate calls.
>=20
> As much as I'd love for that to be the case, technically they might or
> might not.  For normal voice between two users it's always the case.
> But RFC 3550 always supported separate SSRCs in the same RTP session and
> thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have both
> been talking about using that ability. (so for example video from
> multiple cameras goes in the same RTP session, with separate SSRCs)  At
> least that's what I believe they're thinking of.  And of course even for
> a normal voice call there could be an SSRC collision, changing the SSRC
> mid-call.
>=20
> I'm ok with assuming one, just wondering what we do if we get a second
> one.  I think you're saying we should treat is as a separate flow from
> an IPFIX reporting perspective, right?
>=20
> -hadriel
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From aakhter@cisco.com  Wed Mar 28 04:09:55 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9E321F89F4 for ; Wed, 28 Mar 2012 04:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.219
X-Spam-Level: 
X-Spam-Status: No, score=-110.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ4AH2+ckOOE for ; Wed, 28 Mar 2012 04:09:49 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7B28421F8985 for ; Wed, 28 Mar 2012 04:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=5638; q=dns/txt; s=iport; t=1332932973; x=1334142573; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9tXAu+spWAZ3raXqcXzNU1FM8YDppGWnXMLruioqOBA=; b=biKG0inSyVztNHLPU1BxCylYmNshvGBi2qDYJskrIEzshjERLz/M5Lbj fiBiOngcmorFUjBIQaW+45YmHZlR/aL+HLxAv5pgnFWIVw7Y2uqs5JLNd gqjo7CcMCCHHJ9O4dt9I+Qde/8mUh8SPWmnXjGCqQVVjrMpwDffeCU55n 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAA3wck+tJXHA/2dsb2JhbABFuG2BB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgOAwQBAQEKBhcBBgEmHwkIAgQTCBqHYwULm1OfG5AvYwSIWI4ajTSBaIMFgT4
X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="69842044"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 28 Mar 2012 11:09:33 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2SB9WIo025859;  Wed, 28 Mar 2012 11:09:32 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 28 Mar 2012 06:09:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Mar 2012 06:09:27 -0500
Message-ID: <7F298ACC76CC154F832B6D02852D169F079F3DE9@XMB-RCD-101.cisco.com>
In-Reply-To: <13B5187B-06D6-4E44-9E85-D092D3348954@acmepacket.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
thread-index: AQHNDNFdm5pcXpkw0kaR2dMa2rWSPpZ/ibsw
References: <4F702CF4.4040203@123.org><7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com><4F71A577.5000105@voipfuture.com> <90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com> <7F298ACC76CC154F832B6D02852D169F079F3D37@XMB-RCD-101.cisco.com> <13B5187B-06D6-4E44-9E85-D092D3348954@acmepacket.com>
From: "Aamer Akhter (aakhter)" 
To: "Hadriel Kaplan" 
X-OriginalArrivalTime: 28 Mar 2012 11:09:32.0257 (UTC) FILETIME=[4073B510:01CD0CD3]
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 11:09:55 -0000

Hi Hadriel,

I completely agree, the cross-vendor comparison is one of the main
reasons we want to standardize the methodology not just the IEs and why
there are 2 drafts-- one for each. It is not as simple as, just do (in
the case of RTP) what RFC3550 says. :-)

Some history re OPSAWG:=20

	There was actually a IPFIX version a really long time ago:
		http://tools.ietf.org/html/draft-akhter-ipfix-perfmon-01
(IE and methodology was in one doc)

	Based on the feedback from the IPFIX WG itself in one of the
meetings the IE allocation and the methodology were separated and moved
to another WG.=20

	I'll paraphrase the discussion as: "IPFIX WG really only does
IPFIX structure and IE allocation, so come back when the methodology is
sorted out"

	I've been searching for a home ever since. The latest I heard
today is that it should be IPPM as they will now take passive
measurements.=20

Regards,
aa

-----Original Message-----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20
Sent: Wednesday, March 28, 2012 6:56 AM
To: Aamer Akhter (aakhter)
Cc: Hendrik Scholz; 
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00


Makes sense to me.

OK, so as I said in another email, the tricky part about this will be
coming up with a consistent set of metrics across vendors, because if
it's just one vendor's implementation model then it really shouldn't get
an IANA-allocated IE number, should it?  It's effectively proprietary
and that's what PENs are for, no?  Otherwise we'll be allocating
hundreds of IANA-numberspace IEs, different ones for each vendor (my
company alone has around few dozen different reported fields for
RTP/RTCP).

-hadriel
p.s. why are your drafts in OPSAWG?


On Mar 28, 2012, at 12:56 AM, Aamer Akhter (aakhter) wrote:

> Hadriel,
>=20
> Multiple SSRC within the 5-tuple is how the CTS product line encodes=20
> multiple audio/video channels. Other implementations eg. T3 series use

> different 5-tuples.
>=20
> (5-tuple =3D ipsrc, ipdst, iprotocol, l4ports)
>=20
> " we should treat is as a separate flow from an IPFIX reporting=20
> perspective, right?"
>=20
> this is exactly what is done in the implementation of:
>=20
> 	draft-akhter-opsawg-perfmon-ipfix
> 	draft-akhter-opsawg-perfmon-method
>=20
> In fact, the key fields for the default RTP template (IOS=20
> configuration
> follows):
>=20
>    match ipv4 protocol
>    match ipv4 source address
>    match ipv4 destination address
>    match transport source-port
>    match transport destination-port
>    match transport rtp ssrc
>=20
> and the collect fields are:
>=20
>    collect routing forwarding-status
>    collect ipv4 dscp
>    collect ipv4 ttl
>    collect transport packets expected counter
>    collect transport packets lost counter
>    collect transport packets lost rate
>    collect transport event packet-loss counter
>    collect transport rtp jitter mean
>    collect transport rtp jitter minimum
>    collect transport rtp jitter maximum
>    collect interface input
>    collect interface output
>    collect counter bytes
>    collect counter packets
>    collect counter bytes rate
>    collect counter packets dropped
>    collect timestamp interval
>    collect application media bytes counter
>    collect application media bytes rate
>    collect application media packets counter
>    collect application media packets rate
>    collect application media event
>    collect monitor event
>=20
> If the 'rtp ssrc' is not set as a key field, the various metrics form=20
> the differing SSRC flows are aggregated to how a IPFIX 'flow' is=20
> defined.
>=20
>=20
>=20
> -----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf

> Of Hadriel Kaplan
> Sent: Tuesday, March 27, 2012 5:41 PM
> To: Hendrik Scholz
> Cc: 
> Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
>=20
>=20
> On Mar 27, 2012, at 1:33 PM, Hendrik Scholz wrote:
>=20
>>> 3) Some of the IEs imply there's a single SSRC for a flow - are you=20
>>> assuming a flow is by definition the 6-tuple of IP src/dest, port=20
>>> src/dest, transport type, and SSRC?  In other words, if there are=20
>>> two
>=20
>>> or more SSRCs in the same 5-tuple, would they be separate IPFIX=20
>>> flows? (they're only one "RTP" session from an RTP and SDP
>>> perspective)
>>=20
>> Yes, a separate SSRC in between two nodes should be recorded in=20
>> separate records. After all these streams would most likely belong to

>> separate calls.
>=20
> As much as I'd love for that to be the case, technically they might or

> might not.  For normal voice between two users it's always the case.
> But RFC 3550 always supported separate SSRCs in the same RTP session=20
> and thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have=20
> both been talking about using that ability. (so for example video from

> multiple cameras goes in the same RTP session, with separate SSRCs) =20
> At least that's what I believe they're thinking of.  And of course=20
> even for a normal voice call there could be an SSRC collision,=20
> changing the SSRC mid-call.
>=20
> I'm ok with assuming one, just wondering what we do if we get a second

> one.  I think you're saying we should treat is as a separate flow from

> an IPFIX reporting perspective, right?
>=20
> -hadriel
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From inacio@cert.org  Wed Mar 28 04:33:18 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414C521F88F3 for ; Wed, 28 Mar 2012 04:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level: 
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf6XEAigV9Wo for ; Wed, 28 Mar 2012 04:33:16 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF8D21F88A9 for ; Wed, 28 Mar 2012 04:33:16 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id q2SBXBxQ013498; Wed, 28 Mar 2012 07:33:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1332934391; bh=RoUyXs0dX6o/MSrUdolhxHxFzlnILPKbW0aN/2POfnE=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=b1/WlvynNElPqpmPZKgRJg6AHM4lBOeDfHb0zlaISDcnvbTodwqac8BNBFSf9fsHr cJc6r+N4yugK4Crviisa/xBvx2a28i1sSiHXReJj7/3w1BLsArO7lZy1M7gUfZO+o6 nby3zAG8NPgDfGrz4hPkYqH69OvWk/ATXrQZtYQY=
Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id q2SBXBDn005072; Wed, 28 Mar 2012 07:33:11 -0400
Received: from EXCHANGE.sei.cmu.edu ([10.64.28.12]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Wed, 28 Mar 2012 07:33:11 -0400
From: Chris Inacio 
To: Paul Aitken 
Date: Wed, 28 Mar 2012 07:33:10 -0400
Thread-Topic: [IPFIX] IPFIX length fields
Thread-Index: Ac0M1o4CcRIWwLaVRDWvJ4ul0abh+Q==
Message-ID: <946A3ADE-BAAF-41C9-8C30-A82EFC9D9ADD@cert.org>
References: <4F50011C.1020508@cisco.com>
In-Reply-To: <4F50011C.1020508@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Nicholas Brown , IETF IPFIX Working Group 
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 11:33:18 -0000

I vote to keep IPaddress as a semantic type.  Because I can do things like =
masking / subnetting, etc. when it is an IPAddress - but I don't think abou=
t doing that with an identifier.

We are currently implementing stuff the depends on IP (v4/v6) as a semantic=
 meaning.

I assume I can do pretty much *nothing* intelligent operationally, masking,=
 flags, ranges, summation, etc.  with identifier.  Only key matching.  But =
I know I can do more with an IP address.

Chris


On Mar 1, 2012, at 6:07 PM, Paul Aitken wrote:

> Dear all,
>=20
> Reviewing IANA's IPFIX field list, we noticed that most of the *length fi=
elds have no semantics.
>=20
> However, mplsTopLabelPrefixLength has semantics of "identifier", while et=
hernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semanti=
cs of "identifier".
>=20
> We propose that these all be changed to no semantics.
>=20
> Or better, that all lengths be changed to semantics of "quantity", since =
RFC5102 says,
> 3.2.1.  quantity
>=20
>    A quantity value represents a discrete measured value pertaining to
>    the record.  This is distinguished from counters that represent an
>    ongoing measured value whose "odometer" reading is captured as part
>    of a given record. =20
> If no semantic qualifier is given, the
>    Information Elements that have an integral data type should behave as
>    a quantity.
>=20
>=20
> Feedback?
>=20
> Thanks,
> Paul and Nick
> 


From n.brownlee@auckland.ac.nz  Wed Mar 28 06:46:20 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19621E81C6 for ; Wed, 28 Mar 2012 06:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZiQhTvjbARg for ; Wed, 28 Mar 2012 06:46:18 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 369CE21E81BF for ; Wed, 28 Mar 2012 06:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1332942378; x=1364478378; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=eyZU95q4AF2xxxIFG9fMjC2T+3yTGSaK8TWTO5fbwMw=; b=LYlNzbEer94LX7BCc0ByOJaGGy+wpCHLNkK+OW8ZDTzpD/v8ghmqLo82 aYeMLzEd5Wclzg7m3VWmNjlbvrtAJBSYu4XGfJ/wPPzEaQjIywqKXPV5L 0O2O2xz23iBnnSiprTzWLet/bVJyVI7K4VVa/e20BV10ugxd9LWAnSUkz U=;
X-IronPort-AV: E=Sophos;i="4.75,331,1330858800"; d="scan'208";a="113940985"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 130.129.18.109 - Outgoing - Outgoing-SSL
Received: from dhcp-126d.meeting.ietf.org (HELO [130.129.18.109]) ([130.129.18.109]) by mx2-int.auckland.ac.nz with ESMTP; 29 Mar 2012 02:46:14 +1300
Message-ID: <4F731623.5010403@auckland.ac.nz>
Date: Wed, 28 Mar 2012 06:46:11 -0700
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: IPFIX list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Agenda for tomorrow's meeting
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 13:46:20 -0000

Hi all:

I've posted the latest version of the agenda to the Meeting
Materials page,
https://datatracker.ietf.org/meeting/83/materials.html

Also posted are the first five slide sets.  Authors, please send me
your slides as soon as possible so that I can get them posted
not too much after 1300 tomorrow.

The Agenda on the Meeting Materials page seems to take a while to
update, so here's the text version of the agenda ...

===========================================
IP Flow Information Export WG (ipfix)
Agenda for IETF 83, Paris
Thursday, 29 March, 1740-1940, room 212/213
===========================================

Chairs:
Juergen Quittek 
Nevil Brownlee  

AGENDA:

1. Agenda review                                            =  5 min

2. Update from last meeting / WG Status (Nevil)             = 10 min
      IPFIX Export per SCTP Stream
        RFC 6526 published  12 Mar 12

      IPFIX Configuration Model
        draft-ietf-ipfix-configuration-model-10, 18 Jul 11
        Waiting on PSAMP MIB
      PSAMP MIB
        draft-ietf-ipfix-psamp-mib-04.txt, 27 Feb 12
        Waiting on IPFIX MIB
      IPFIX MIB  (charter item 6)  (RFC-Ed C139)
        draft-ietf-ipfix-rfc5815bis-01, 20 Jan 12
        Approved  26 Mar 12

      Flow Selection Techniques
       draft-ietf-ipfix-flow-selection-tech-10,  6 Mar 12
       IETF last call started  21 Mar 12

      draft-claise-export-application-info-in-ipfix-05
        has been sent to IESG as an Individual submission

      IPR disclosures for IPFIX Aggregation (Avaya, Cisco)

3. New charter work items                                   = 70 min
    a) IPFIX Aggregation  (Brian Trammell)
         draft-ietf-ipfix-a9n-03, 27 Feb 12

    b) Specification of the IP Flow Information eXport (IPFIX)
       Protocol for the Exchange of Flow Information
           (Brian Trammell)
         draft-ietf-ipfix-protocol-rfc5101bis-01, 7 Mar 11

    c) Information Model for IP Flow Information eXport (IPFIX)
           (Brian Trammell)
         draft-ietf-ipfix-information-model-rfc5102bis-00, 24 Jan 12

    d) Guidelines for Information Elements  (Brian Trammell)
         draft-ietf-ipfix-ie-doctors-02, 7 Mar 12

    e) Protocol for PFIX Mediation  (Brian Trammell)
         draft-ietf-ipfix-mediation-protocol-00, 6 Dec 11

    f) IEs for Data Link Layer Traffic Measurement  (Paul Aitken)
         draft-kashima-ipfix-data-link-layer-monitoring-07, 12 Mar 12

    g) Exporting MIB objects  (Paul Aitken)
         draft-johnson-ipfix-mib-variable-export-04, 12 Mar 12

4. Other drafts                                              = 20 min
    a) Reporting Unobserved Fields in IPFIX  (Paul Aitken)
         draft-aitken-ipfix-unobserved-field,  30 Jan 12

    b) Cisco Specific Information Elements reused in IPFIX
         (Paul Aitken)
         draft-yourtchenko-cisco-ies-03, 12 Mar 12

draft-scholz-ipfix-rtp-msg-00, 5 Mar 12  H Scholtz

5. Discussion of future direction for IPFIX (if time allows) = 10 min

6. Any Other Business                                       =  5 min


Presentation slides will be available at
   https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=83
   (search for IPFIX in the Operations and Management Area)

Participation via jabber is offered at ipfix@jabber.ietf.org


Cheers, Nevil

-- 
---------------------------------------------------------------------
  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


From HKaplan@acmepacket.com  Wed Mar 28 17:53:22 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3BC21E80B9 for ; Wed, 28 Mar 2012 17:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level: 
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HswWfrgcqhew for ; Wed, 28 Mar 2012 17:53:21 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0121E800F for ; Wed, 28 Mar 2012 17:53:21 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 20:53:16 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 20:53:16 -0400
From: Hadriel Kaplan 
To: "Aamer Akhter (aakhter)" 
Thread-Topic: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
Thread-Index: AQHNDUZTm5pcXpkw0kaR2dMa2rWSPg==
Date: Thu, 29 Mar 2012 00:53:16 +0000
Message-ID: 
References: <4F702CF4.4040203@123.org><7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com><4F71A577.5000105@voipfuture.com> <90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com> <7F298ACC76CC154F832B6D02852D169F079F3D37@XMB-RCD-101.cisco.com> <13B5187B-06D6-4E44-9E85-D092D3348954@acmepacket.com> <7F298ACC76CC154F832B6D02852D169F079F3DE9@XMB-RCD-101.cisco.com>
In-Reply-To: <7F298ACC76CC154F832B6D02852D169F079F3DE9@XMB-RCD-101.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: multipart/alternative; boundary="_000_E5ADAC3ACE5C43A99DBFDDCF472C1022acmepacketcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 00:53:22 -0000

--_000_E5ADAC3ACE5C43A99DBFDDCF472C1022acmepacketcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


On Mar 28, 2012, at 1:09 PM, Aamer Akhter (aakhter) wrote:

Based on the feedback from the IPFIX WG itself in one of the
meetings the IE allocation and the methodology were separated and moved
to another WG.

I think the WG may want to reconsider that.  It creates two documents which=
 overlap significantly, except the IANA allocation one is less text with fe=
wer explicit details, while the methodology has the details.  So an impleme=
ntor would basically need to read both docs anyway, and creating two docume=
nts to shepherd/publish is just extra overhead for the submitter, IESG and =
RFC editor.  What's the real benefit?

This is the diff of the files:
http://tools.ietf.org/rfcdiff?url1=3Ddraft-akhter-opsawg-perfmon-method-02.=
txt;url2=3Ddraft-akhter-opsawg-perfmon-ipfix-02.txt 

Seems kinda silly, no?
Just my 2 cents, looking at it from the outside.

-hadriel


--_000_E5ADAC3ACE5C43A99DBFDDCF472C1022acmepacketcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <03AF063C68955E40B5381D995879920C@acmepacket.com>
Content-Transfer-Encoding: quoted-printable











On Mar 28, 2012, at 1:09 PM, Aamer Akhter (aakhter) wrote:






Based =
on the feedback from the IPFIX WG itself in one of the

meetings the IE allocation and the methodology were separated and moved

to another WG. 










I think the WG may want to reconsider that.  It creates two docum=
ents which overlap significantly, except the IANA allocation one is less te=
xt with fewer explicit details, while the methodology has the details. &nbs=
p;So an implementor would basically need to
 read both docs anyway, and creating two documents to shepherd/publish is j=
ust extra overhead for the submitter, IESG and RFC editor.  What's the=
 real benefit?







This is the diff of the files:








Seems kinda silly, no?


Just my 2 cents, looking at it from the outside.







-hadriel









--_000_E5ADAC3ACE5C43A99DBFDDCF472C1022acmepacketcom_--

From n.brownlee@auckland.ac.nz  Thu Mar 29 02:27:43 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03E821F87C5 for ; Thu, 29 Mar 2012 02:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl23v2j4EOsc for ; Thu, 29 Mar 2012 02:27:42 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED921F87C6 for ; Thu, 29 Mar 2012 02:27:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1333013262; x=1364549262; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=noDvHesj87/FTKANvngJ4/NGNJJA7UmaHy+asw4ucCo=; b=aUn9OaY2PH7lFc0DtHcyr1TuwiZ6Fsrmx9nWrL7rm/LYb1ua+oC+szTL WHBu7RCTDl42OldW4Relb1qV1S2aL/tK3YcQgev7kq+KD31b0x+q9C1eP a7c9GL+2l+XwsuiknMZN/5srQDncQIdJXyo8bvJENTw/0U2eXi7XkJ7bL 4=;
X-IronPort-AV: E=Sophos;i="4.75,336,1330858800"; d="scan'208";a="114205420"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 130.129.18.109 - Outgoing - Outgoing-SSL
Received: from dhcp-126d.meeting.ietf.org (HELO [130.129.18.109]) ([130.129.18.109]) by mx2-int.auckland.ac.nz with ESMTP; 29 Mar 2012 22:27:40 +1300
Message-ID: <4F742B07.7080407@auckland.ac.nz>
Date: Thu, 29 Mar 2012 02:27:35 -0700
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Hendrik Scholz 
References: <4F731623.5010403@auckland.ac.nz> <4F741866.7040809@123.org>  <4F74240B.8000707@123.org>
In-Reply-To: <4F74240B.8000707@123.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX list 
Subject: Re: [IPFIX] Agenda for tomorrow's meeting
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 09:27:43 -0000

Hi all:

I've added this draft to the IPFIX agenda fpor this afternoon.

Cheers, Nevil


On 03/29/2012 01:57 AM, Hendrik Scholz wrote:
> Hi all,
>
> On 03/29/2012 10:43 AM, Brian Trammell wrote:
>> To clarify, I indicated that (in my opinion) there was probably enough
>> slack in the schedule to try to bash the agenda to add these slides to the
>> end. This isn't "getting time through Brian", so please do not represent
>> it as such. I have no authority over the agenda, even if I am taking up
>> quite a lot of it this time. :)
>
> Ok, sorry for asserting this. Somehow magically my draft showed up
> on the agenda even though I haven't talked to Nevil/Juergen yet.
> In that case I would like to ask for some time at the end of the
> session and bring this up during the agenda bash if needed.
>
> The 'where to put this draft' discussion is on the slides and
> I believe once Aamer and I have the new drafts ready we'll
> send them to the new working groups.
>
> Thanks a lot,
> Hendrik
>


-- 
---------------------------------------------------------------------
  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


From paitken@cisco.com  Thu Mar 29 05:25:51 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A410A21F8AAE for ; Thu, 29 Mar 2012 05:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.536
X-Spam-Level: 
X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-YiDjSqaVlD for ; Thu, 29 Mar 2012 05:25:44 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5821F8AAA for ; Thu, 29 Mar 2012 05:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=5170; q=dns/txt; s=iport; t=1333023943; x=1334233543; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qiipnGz5vhpvvYSEVI/j3kQbPxLfkSjAnwKVancYuQE=; b=a0MhE+8kPG8H44iX6ghX2bgcr5NlzegH3INf4mO4k8UeMcAUXZpPGf27 Ldnm+H7On9Rc7Rh9h+2v4V4jI978N/VvRyFr5sMhvR9gzQdeGovK6OXw6 +5oPs3dh+kZlWz3goOSM/59zgqbIBqgi+njXZgHuaMS+jhW8HgA48ajIn k=;
X-IronPort-AV: E=Sophos;i="4.73,668,1325462400";  d="scan'208,217";a="133718149"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2012 12:25:42 +0000
Received: from [10.55.83.89] (dhcp-10-55-83-89.cisco.com [10.55.83.89]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2TCPg64014095; Thu, 29 Mar 2012 12:25:42 GMT
Message-ID: <4F7454C6.4090900@cisco.com>
Date: Thu, 29 Mar 2012 13:25:42 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <4F702CF4.4040203@123.org><7EF1B485-21D1-4D3E-9C55-15C327D771C5@acmepacket.com><4F71A577.5000105@voipfuture.com>	<90A8412F-65CE-42FB-9BEF-B8BA30C1A0AF@acmepacket.com>	<7F298ACC76CC154F832B6D02852D169F079F3D37@XMB-RCD-101.cisco.com>	<13B5187B-06D6-4E44-9E85-D092D3348954@acmepacket.com>	<7F298ACC76CC154F832B6D02852D169F079F3DE9@XMB-RCD-101.cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060107040707010603070305"
Cc: "" 
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 12:25:51 -0000

This is a multi-part message in MIME format.
--------------060107040707010603070305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Aamer, Hadriel,

FYI, draft-ietf-ipfix-ie-doctors-02 says everything should be in one doc:

    Optionally, a Working Group or individual contributor may choose to
    publish an RFC detailing the new IPFIX application.  Such an RFC
    should contain discussion of the new application, the Information
    Element definitions as in Section 4, as well as suggested Templates
    and examples of the use of those Templates within the new application


P.


On 29/03/12 01:53, Hadriel Kaplan wrote:
>
> On Mar 28, 2012, at 1:09 PM, Aamer Akhter (aakhter) wrote:
>
>> Based on the feedback from the IPFIX WG itself in one of the
>> meetings the IE allocation and the methodology were separated and moved
>> to another WG.
>
> I think the WG may want to reconsider that.  It creates two documents 
> which overlap significantly, except the IANA allocation one is less 
> text with fewer explicit details, while the methodology has the 
> details.  So an implementor would basically need to read both docs 
> anyway, and creating two documents to shepherd/publish is just extra 
> overhead for the submitter, IESG and RFC editor.  What's the real benefit?
>
> This is the diff of the files:
> http://tools.ietf.org/rfcdiff?url1=draft-akhter-opsawg-perfmon-method-02.txt;url2=draft-akhter-opsawg-perfmon-ipfix-02.txt 
> 
>
> Seems kinda silly, no?
> Just my 2 cents, looking at it from the outside.
>
> -hadriel
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------060107040707010603070305
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Aamer, Hadriel,

    

    FYI, draft-ietf-ipfix-ie-doctors-02 says everything should be in one
    doc:

    

    
   Optionally, a Working Group or individual contributor may choose to
   publish an RFC detailing the new IPFIX application.  Such an RFC
   should contain discussion of the new application, the Information
   Element definitions as in Section 4, as well as suggested Templates
   and examples of the use of those Templates within the new application

    

    P.

    

    

    On 29/03/12 01:53, Hadriel Kaplan wrote:
    

      
      

      

        
On Mar 28, 2012, at 1:09 PM, Aamer Akhter (aakhter) wrote:

        

        

          
Based
            on the feedback from the IPFIX WG itself in one of the

            meetings the IE allocation and the methodology were
            separated and moved

            to another WG. 

          

        

      

      

      
I think the WG may want to reconsider that.  It creates two
        documents which overlap significantly, except the IANA
        allocation one is less text with fewer explicit details, while
        the methodology has the details.  So an implementor would
        basically need to read both docs anyway, and creating two
        documents to shepherd/publish is just extra overhead for the
        submitter, IESG and RFC editor.  What's the real benefit?

      


      

      
This is the diff of the files:

      
      


      

      
Seems kinda silly, no?

      
Just my 2 cents, looking at it from the outside.

      


      

      
-hadriel

      


      

      

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

  


--------------060107040707010603070305--

From andrewf@plixer.com  Thu Mar 29 08:32:48 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C8721E820F for ; Thu, 29 Mar 2012 08:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level: 
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGH1eTT71GDz for ; Thu, 29 Mar 2012 08:32:47 -0700 (PDT)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFB221E8200 for ; Thu, 29 Mar 2012 08:32:46 -0700 (PDT)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Mar 2012 11:32:45 -0400
Message-ID: <4F74809D.4070304@plixer.com>
Date: Thu, 29 Mar 2012 11:32:45 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120318 Thunderbird/14.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4F50011C.1020508@cisco.com> <946A3ADE-BAAF-41C9-8C30-A82EFC9D9ADD@cert.org>
In-Reply-To: <946A3ADE-BAAF-41C9-8C30-A82EFC9D9ADD@cert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Mar 2012 15:32:45.0692 (UTC) FILETIME=[307C63C0:01CD0DC1]
Subject: Re: [IPFIX] IPFIX length fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 15:32:48 -0000

Hi Chris,

The datatype is IPAddress.  Why do you also need a semantic type of 
IPAddress?

-Andrew

On 03/28/2012 07:33 AM, Chris Inacio wrote:
>
> I vote to keep IPaddress as a semantic type.  Because I can do things like masking / subnetting, etc. when it is an IPAddress - but I don't think about doing that with an identifier.
>
> We are currently implementing stuff the depends on IP (v4/v6) as a semantic meaning.
>
> I assume I can do pretty much *nothing* intelligent operationally, masking, flags, ranges, summation, etc.  with identifier.  Only key matching.  But I know I can do more with an IP address.
>
> Chris
>
>
> On Mar 1, 2012, at 6:07 PM, Paul Aitken wrote:
>
>> Dear all,
>>
>> Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics.
>>
>> However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier".
>>
>> We propose that these all be changed to no semantics.
>>
>> Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says,
>> 3.2.1.  quantity
>>
>>     A quantity value represents a discrete measured value pertaining to
>>     the record.  This is distinguished from counters that represent an
>>     ongoing measured value whose "odometer" reading is captured as part
>>     of a given record.
>> If no semantic qualifier is given, the
>>     Information Elements that have an integral data type should behave as
>>     a quantity.
>>
>>
>> Feedback?
>>
>> Thanks,
>> Paul and Nick
>> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix



From aakhter@cisco.com  Thu Mar 29 08:42:32 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C513D21F8753 for ; Thu, 29 Mar 2012 08:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.253
X-Spam-Level: 
X-Spam-Status: No, score=-110.253 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPzidsCgCu7d for ; Thu, 29 Mar 2012 08:42:31 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D981121F86C3 for ; Thu, 29 Mar 2012 08:42:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=4558; q=dns/txt; s=iport; t=1333035734; x=1334245334; h=mime-version:subject:date:message-id:from:to:cc; bh=RKNLzsQlJJCfFHEKbIC9OkHfMUCt71wdJejUbfRcB4c=; b=O593WJDnwagQxKFqXO6x8kYrWwhwAuT1Xm2bFlMIB0SI4SMhgv7bNjd7 C7pqtbg5SVuOvk4SA0XM1o5To4Lf2rOMeHb+HRcU0EqXdpME3LM1XjBnf 4ki2ySwUVFMXqGqfvFLV/lduoLAATggaCdDqJcqTcwX+1HtUw/Zgkz4PA E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAHqBdE+tJXG+/2dsb2JhbAA7CYJGtkuBB4IJAQEBBBIBCREDSRIBDBENBhgHVwEEEwgah2icDp8qinQIgn+CQWMEiFibT4FogwWBPg
X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208,217";a="70497578"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 29 Mar 2012 15:42:13 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2TFgDBi030141;  Thu, 29 Mar 2012 15:42:13 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Mar 2012 10:42:13 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0DC2.828F3DB3"
Date: Thu, 29 Mar 2012 10:42:08 -0500
Message-ID: <7F298ACC76CC154F832B6D02852D169F079F436B@XMB-RCD-101.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Mail regarding draft-trammell-ipfix-sip-msg
thread-index: Ac0NwgcvT5/l87WLRLmY+8NV/frZlg==
From: "Aamer Akhter (aakhter)" 
To: 
X-OriginalArrivalTime: 29 Mar 2012 15:42:13.0092 (UTC) FILETIME=[82AEC240:01CD0DC2]
Cc: ipfix@ietf.org
Subject: [IPFIX] Mail regarding draft-trammell-ipfix-sip-msg
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 15:42:33 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD0DC2.828F3DB3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please find my comments regarding draft-trammell-ipfix-sip-msg-02 below:

=20

A1) Are the IEs below (and perhaps others) really SIP specific. It would
be good to have generic DialFrom and DialTo for example that apply
outside of SIP.=20

=20

sipFromURI=20

sipToURI=20

observationtype

=20

=20

A2) I did not see anything the represents the contact (aka Display
Information). This is sometimes useful, and there are several examples
(the stuff in quotes) below  (in the case of SIP) :

=20

contact From/To. This would be the items (in the case of SIP) in the
quotes. (3 examples below)

P-Asserted-Identity: "Cullen Jennings" 

Remote-Party-ID: "John Doe"
;party=3Dcalling;id-type=3Dsubscriber;privacy=3Dfull;sc=
reen=3D
yes

From: "A. G. Bell"  ;tag=3Da48s

=20

Regards,

=20

aa


------_=_NextPart_001_01CD0DC2.828F3DB3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Please =
find my comments regarding draft-trammell-ipfix-sip-msg-02 =
below:
 
A1) Are the IEs below (and perhaps others) really SIP =
specific. It would be good to have generic DialFrom and DialTo for =
example that apply outside of SIP. 
 
sipFromURI 
sipToURI 
observationtype
 
 
A2) I did =
not see anything the represents the contact (aka Display Information). =
This is sometimes useful, and there are several examples (the stuff in =
quotes) below  (in the case of SIP) :
 
contact =
From/To. This would be the items (in the case of SIP) in the quotes. (3 =
examples below)
 P-Asserted-Identity: =
"Cullen Jennings" =
<sip:fluffy@cisco.com>
 =
Remote-Party-ID: "John Doe" =
<sip:jdoe@foo.com>;party=3Dcalling;id-type=3Dsubscriber;privacy=3Df=
ull;screen=3Dyes
 From: "A. G. =
Bell" <sip:agb@bell-telephone.com> =
;tag=3Da48s
 
Regards,
 
aa

------_=_NextPart_001_01CD0DC2.828F3DB3--

From aakhter@cisco.com  Thu Mar 29 09:14:44 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C522221F880D for ; Thu, 29 Mar 2012 09:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.282
X-Spam-Level: 
X-Spam-Status: No, score=-110.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou1s488J8YPf for ; Thu, 29 Mar 2012 09:14:43 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B19F121F882D for ; Thu, 29 Mar 2012 09:14:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=3011; q=dns/txt; s=iport; t=1333037676; x=1334247276; h=mime-version:subject:date:message-id:from:to:cc; bh=ZfAum+TSDP0pr3vFQPDRCv0MPATfOjNM/8cJerdhWjI=; b=ibjaAufAum/KDcQ4wJb6y5PPo2A04twZa3YibuLXHDNQvvlx26mqkaMm vmZ70kzOJc8swZ2iTkLfCUTMBgO6ENI4Hab9WThl8K41IpxpqIks4/0M3 WCLIBFZFZt5jQQYUM8Z9xs8PPWGsKQ9GsOhpveD7VLbN6FyRJXz3UO34J g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACmJdE+tJXG+/2dsb2JhbABEgka2TIEHggsBBBIBCREDSRIBDB4GGAdXAQQbGodonAifKop8gn+CQWMEiFibT4FogwWBPg
X-IronPort-AV: E=Sophos;i="4.73,669,1325462400"; d="scan'208,217";a="70473141"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 29 Mar 2012 16:14:30 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2TGEUHA015611;  Thu, 29 Mar 2012 16:14:30 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Mar 2012 11:14:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0DC7.04E2A7EB"
Date: Thu, 29 Mar 2012 11:14:25 -0500
Message-ID: <7F298ACC76CC154F832B6D02852D169F079F43A7@XMB-RCD-101.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Mail regarding draft-ietf-ipfix-protocol-rfc5101bis
thread-index: Ac0NxFF1TNd7dcbaSOWrUIb0Tjsczg==
From: "Aamer Akhter (aakhter)" 
To: 
X-OriginalArrivalTime: 29 Mar 2012 16:14:29.0810 (UTC) FILETIME=[050E7920:01CD0DC7]
Cc: ipfix@ietf.org
Subject: [IPFIX] Mail regarding draft-ietf-ipfix-protocol-rfc5101bis
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 16:14:45 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD0DC7.04E2A7EB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Regarding draft-ietf-ipfix-protocol-rfc5101bis-01:

=20

I might have missed it but does the new specification detail how a
collector is to process multiple similar-type information elements? This
would be outside the context of RFC6313 (structured data).

=20

For example, should the collector take only the first, the last, or
(preferably) record all of the elements?=20

=20

Regards,

aa


------_=_NextPart_001_01CD0DC7.04E2A7EB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Regarding =
draft-ietf-ipfix-protocol-rfc5101bis-01:
 
I might have =
missed it but does the new specification detail how a collector is to =
process multiple similar-type information elements? This would be =
outside the context of RFC6313 (structured data).
 
For example, =
should the collector take only the first, the last, or (preferably) =
record all of the elements? 
 
Regards,
aa

------_=_NextPart_001_01CD0DC7.04E2A7EB--

From bclaise@cisco.com  Thu Mar 29 09:56:35 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4621F8981 for ; Thu, 29 Mar 2012 09:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoE3h6sqqBj6 for ; Thu, 29 Mar 2012 09:56:35 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4921F88E9 for ; Thu, 29 Mar 2012 09:56:33 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2TGjQFV003984 for ; Thu, 29 Mar 2012 18:45:26 +0200 (CEST)
Received: from [10.55.82.100] (dhcp-10-55-82-100.cisco.com [10.55.82.100]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2TGjPUp012693 for ; Thu, 29 Mar 2012 18:45:25 +0200 (CEST)
Message-ID: <4F7491A5.4030604@cisco.com>
Date: Thu, 29 Mar 2012 18:45:25 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] IEs re-ordering in an Aggregator
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 16:56:35 -0000

Dear all,

One more point for the issue discussed today in the working: the 
re-ordering in aggregator.
RFC5101:

    The order of the Scope Fields, as defined in the Options
    Template Record, is irrelevant in this case.  However, if the order
    of the Scope Fields in the Options Template Record is relevant, the
    order of the Scope Fields MUST be used.  For example, if the first
    scope defines the filtering function, while the second scope defines
    the sampling function, the order of the scope is important.

We should maybe address the order of the scoped IEs separately.

Regards, Benoit.
	





From HKaplan@acmepacket.com  Thu Mar 29 10:00:26 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5B121E80B2 for ; Thu, 29 Mar 2012 10:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.502
X-Spam-Level: 
X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t198eqRcsFRz for ; Thu, 29 Mar 2012 10:00:24 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2021E8053 for ; Thu, 29 Mar 2012 10:00:23 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Mar 2012 13:00:21 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 13:00:21 -0400
From: Hadriel Kaplan 
To: "Aamer Akhter (aakhter)" 
Thread-Topic: Mail regarding draft-trammell-ipfix-sip-msg
Thread-Index: AQHNDc1tRCohPS53nkWhS4Fogxjo3g==
Date: Thu, 29 Mar 2012 17:00:21 +0000
Message-ID: 
References: <7F298ACC76CC154F832B6D02852D169F079F436B@XMB-RCD-101.cisco.com>
In-Reply-To: <7F298ACC76CC154F832B6D02852D169F079F436B@XMB-RCD-101.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: multipart/alternative; boundary="_000_FA2A694BADEB490F9A95E336E7007F3Dacmepacketcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" , "" 
Subject: Re: [IPFIX] Mail regarding draft-trammell-ipfix-sip-msg
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 17:00:26 -0000

--_000_FA2A694BADEB490F9A95E336E7007F3Dacmepacketcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Aamer,
comments inline...

On Mar 29, 2012, at 5:42 PM, Aamer Akhter (aakhter) wrote:

Please find my comments regarding draft-trammell-ipfix-sip-msg-02 below:

A1) Are the IEs below (and perhaps others) really SIP specific. It would be=
 good to have generic DialFrom and DialTo for example that apply outside of=
 SIP.

Well=85 for sipFromURI/sipToURI they wouldn't be "DialFrom" or "DialTo" bec=
ause the ones in this draft encode the literal value of the SIP From or To =
header field URIs from the SIP Message.  They don't, for example, necessari=
ly represent the calling or called parties of a SIP INVITE request.  And al=
so they were meant to capture the whole From or To URI, not just the user d=
igits (since in SIP the rest of it matters too, and it may not be digits).

ISUP, for example has a Calling-Party-Number but it's not syntactically the=
 same, and even from a semantics perspective they're not equivalent (ISUP C=
gPN has screening info for example, that is not in SIP From header URIs).  =
For H.323 I suppose you could take the calling party and convert it to an H=
.323 URL (ie, RFC 3508), but it would be unnatural/weird.

Having said that, both the To and From headers in SIP (RFC 3261) really ori=
ginated in HTTP (RFC 2616), so I guess in theory we could call them httpFro=
mAddrSpec and httpToAddrSpec.  Personally I think that would be super confu=
sing to administrators, though.

I agree with you that the sipObservationType should be generic and not SIP-=
specific.  I guess my question is if it should be something like observatio=
nType with what values exactly?


sipFromURI
sipToURI
observationtype


A2) I did not see anything the represents the contact (aka Display Informat=
ion). This is sometimes useful, and there are several examples (the stuff i=
n quotes) below  (in the case of SIP) :

contact From/To. This would be the items (in the case of SIP) in the quotes=
. (3 examples below)
P-Asserted-Identity: "Cullen Jennings" 
Remote-Party-ID: "John Doe" ;party=3Dcalling;id-type=3Dsu=
bscriber;privacy=3Dfull;screen=3Dyes
From: "A. G. Bell"  ;tag=3Da48s

I don't think you mean the "contact" - there's a "Contact" header in SIP os=
 it confuses me to use that word. :)

I think what you're looking for is one IE field for the "source" of the SIP=
 message, regardless of which header is used to determine who/what the sour=
ce is?

So far we haven't wanted to make the SIP IEs require interpretation or much=
 intelligence on the monitor/exporter.  Instead we've just described them a=
s being literal copies of SIP fields (header fields or URIs).  For example,=
 in any given SIP Request, it can have the above headers as you show (well,=
 technically Remote-Party-ID is a proprietary Cisco header, not a well-know=
n header).  Which one of those the IPFIX exporter decides to use for a gene=
ric "source" information is up to a bunch of logic - for example whether th=
e P-Asserted-Identity is trusted, then it should supersede the From URI; bu=
t if you support the Cisco header you may prefer it to identify the "source=
" over the others, or not.

Or do you actually mean the display-name portion of the above headers? (the=
 part inside the double-quotes would be the display-name)

-hadriel


--_000_FA2A694BADEB490F9A95E336E7007F3Dacmepacketcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <436264D85CC1D546A0DAA3711F75C94E@acmepacket.com>
Content-Transfer-Encoding: quoted-printable








Hi Aamer,


comments inline...






On Mar 29, 2012, at 5:42 PM, Aamer Akhter (aakhter) wrote:











Please find my comments regarding draft-trammell-ipfix-sip-msg-02 below:



 



A1) Are the IEs below (and perhaps others) really SIP specific. It would be=
 good to have generic DialFrom and DialTo for example that apply outside of=
 SIP.













Well=85 for sipFromURI/sipToURI they wouldn't be "DialFrom" =
or "DialTo" because the ones in this draft encode the literal val=
ue of the SIP From or To header field URIs from the SIP Message.  They=
 don't, for example, necessarily represent the calling or called
 parties of a SIP INVITE request.  And also they were meant to capture=
 the whole From or To URI, not just the user digits (since in SIP the rest =
of it matters too, and it may not be digits).







ISUP, for example has a Calling-Party-Number but it's not syntacticall=
y the same, and even from a semantics perspective they're not equivalent (I=
SUP CgPN has screening info for example, that is not in SIP From header URI=
s).  For H.323 I suppose you could
 take the calling party and convert it to an H.323 URL (ie, RFC 3508), but =
it would be unnatural/weird.







Having said that, both the To and From headers in SIP (RFC 3261) reall=
y originated in HTTP (RFC 2616), so I guess in theory we could call them ht=
tpFromAddrSpec and httpToAddrSpec.  Personally I think that would be s=
uper confusing to administrators, though.







I agree with you that the sipObservationType should be generic and not=
 SIP-specific.  I guess my question is if it should be something like =
observationType with what values exactly?











sipFromURI















sipToURI



observationtype



 



 



A2) I did not see anything the represents the contact (aka Display Informat=
ion). This is sometimes useful, and there are several examples (the stuff i=
n quotes) below  (in the case of SIP) :



 



contact From/To. This would be the items (in the case of SIP) in the quotes=
. (3 examples below)



P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@c=
isco.com>



Remote-Party-ID: "John Doe" <sip:jdoe@foo.com>;pa=
rty=3Dcalling;id-type=3Dsubscriber;privacy=3Dfull;screen=3Dyes


From: "A. G. Bell" <sip:agb@bell-telephone.com=
> ;tag=3Da48s












I don't think you mean the "contact" - there's a "Conta=
ct" header in SIP os it confuses me to use that word. :)







I think what you're looking for is one IE field for the "source&q=
uot; of the SIP message, regardless of which header is used to determine wh=
o/what the source is?






So far we haven't wanted to make the SIP IEs require interpretation or much=
 intelligence on the monitor/exporter.  Instead we've just described t=
hem as being literal copies of SIP fields (header fields or URIs).  Fo=
r example, in any given SIP Request, it can
 have the above headers as you show (well, technically Remote-Party-ID is a=
 proprietary Cisco header, not a well-known header).  Which one of tho=
se the IPFIX exporter decides to use for a generic "source" infor=
mation is up to a bunch of logic - for example
 whether the P-Asserted-Identity is trusted, then it should supersede the F=
rom URI; but if you support the Cisco header you may prefer it to identify =
the "source" over the others, or not. 






Or do you actually mean the display-name portion of the above headers?=
 (the part inside the double-quotes would be the display-name)







-hadriel









--_000_FA2A694BADEB490F9A95E336E7007F3Dacmepacketcom_--

From andrewf@plixer.com  Thu Mar 29 11:11:24 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A458E21F8816 for ; Thu, 29 Mar 2012 11:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.29
X-Spam-Level: 
X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.308,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwnbX5HQjNOZ for ; Thu, 29 Mar 2012 11:11:24 -0700 (PDT)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id BE66221F881C for ; Thu, 29 Mar 2012 11:11:23 -0700 (PDT)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Mar 2012 14:11:23 -0400
Message-ID: <4F74A5CB.2010301@plixer.com>
Date: Thu, 29 Mar 2012 14:11:23 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120318 Thunderbird/14.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <7F298ACC76CC154F832B6D02852D169F079F43A7@XMB-RCD-101.cisco.com>
In-Reply-To: <7F298ACC76CC154F832B6D02852D169F079F43A7@XMB-RCD-101.cisco.com>
Content-Type: multipart/alternative; boundary="------------050105000104080606050702"
X-OriginalArrivalTime: 29 Mar 2012 18:11:23.0150 (UTC) FILETIME=[59553AE0:01CD0DD7]
Subject: Re: [IPFIX] Mail regarding draft-ietf-ipfix-protocol-rfc5101bis
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 18:11:24 -0000

This is a multi-part message in MIME format.
--------------050105000104080606050702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Aamer,

Are you referring to to what used to be " 3.4.  Multiple Information 
Elements of the Same Type"?  That text appears to have moved to " 8.  
Template Management".

And to answer your question: " Collecting processes MUST properly handle 
Templates with multiple identical Information Elements."

-Andrew

On 03/29/2012 12:14 PM, Aamer Akhter (aakhter) wrote:
>
> Regarding draft-ietf-ipfix-protocol-rfc5101bis-01:
>
> I might have missed it but does the new specification detail how a 
> collector is to process multiple similar-type information elements? 
> This would be outside the context of RFC6313 (structured data).
>
> For example, should the collector take only the first, the last, or 
> (preferably) record all of the elements?
>
> Regards,
>
> aa
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix



--------------050105000104080606050702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Aamer,

      

      Are you referring to to what used to be "
      
      3.4.  Multiple Information Elements of the Same Type"?  That text
      appears to have moved to "
      
      8.  Template Management".

      

      And to answer your question: "
      
      Collecting processes MUST properly handle Templates with multiple
      identical Information Elements."

      

      -Andrew

      

      On 03/29/2012 12:14 PM, Aamer Akhter (aakhter) wrote:

    

      
      

        
Regarding draft-ietf-ipfix-protocol-rfc5101bis-01: 

        
   

        
I might have missed it but does the new specification detail
          how a collector is to process multiple similar-type
          information elements? This would be outside the context of
          RFC6313 (structured data). 

        
   

        
For example, should the collector take only the first, the
          last, or (preferably) record all of the elements? 

        
   

        
Regards, 

        
aa 

      

      

      

      

      
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

    

  


--------------050105000104080606050702--

From n.brownlee@auckland.ac.nz  Fri Mar 30 02:41:49 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8355F21F894B for ; Fri, 30 Mar 2012 02:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ETqn3IQAGyJ for ; Fri, 30 Mar 2012 02:41:48 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD7921F88A8 for ; Fri, 30 Mar 2012 02:41:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1333100507; x=1364636507; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=C+ECY8nrk6MD+9p6hd9CinNm4Sd8fC4SiZexpkwyorw=; b=njs8S+hudLDOQydRl4D0wwMwVa7e01qi6nDCO8ZzmcdFawdl8KlZvAhX 3Lm0jQce19Jwjzko7xuNF3oArd9BsalLxsynwjx0IJkYQDnwjgYVa84wS +WxiKbHZC79mgHfjnMbrVBN9Br+SuZui8zC0D2DxAwhtBd9EittIEXuCJ s=;
X-IronPort-AV: E=Sophos;i="4.75,343,1330858800"; d="scan'208";a="114469361"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 130.129.18.109 - Outgoing - Outgoing-SSL
Received: from dhcp-126d.meeting.ietf.org (HELO [130.129.18.109]) ([130.129.18.109]) by mx2-int.auckland.ac.nz with ESMTP; 30 Mar 2012 22:41:45 +1300
Message-ID: <4F757FCA.90905@auckland.ac.nz>
Date: Fri, 30 Mar 2012 02:41:30 -0700
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: IPFIX list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] DRAFT IPFIX minutes for Paris meeting
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 09:41:49 -0000

Hi all:

Here are my DRAFT minutes for the meeting - please send corrections,
suggestions for improvements, etc to me.

Cheers, Nevil

Minutes of the IPFIX meeting at IETF 83
About 27 people present
Scribes: Chris Innacio, Paul Aitken & Nevil Brownlee

Juergen opened the meeting, pointing out that
  - IPFIX Export per Stream is now RFC 6526.
  - The revised IPFIX MIB (5815bis) has been approved by IESG,
      this will clear the PSAMP MIB and IPFIX Configuration drafts.
  - Flow Selection Techniques is now in IETF Last Call.

Brian Trammell presented our 5101bis draft.  If we are to progress
the protocol to Internet Standard, we need to test interoperation
of all its 'must implement' features.  In the draft
  - template withdrawal is simplified.  For UDP, problems with this
    need to be fixed; Brian proposes a switch that would allow
    5101bis to interoperate with 5101 implementations.  Our AD
    will check whether that would be acceptable.
  - sections 8-10 have been edited to make them easier to understand.
    Please read these and comment on the list.
  - Security when using SCTP implementations needs more testing.
    This could be done using DTLS over SCTP (as in 5101), or using
    SCTP over DTLS (draft presented in tsvwg).  Brian proposed that
    users will mostly use SCTP in a Data Centre environment, where
    physical security is sufficient; over a wide area the data rates
    needed are low, TLS over TCP would be sufficient.
    We need to discuss this in more detail on the list.

Brian presented our 5102bis draft.
  - IE length limits: Brian proposes we use section 4.2 of our
    MIB Doctors draft, comments on the list please.
  - Allowable semantics for each type: there's an AI for WG to help
    IANA clean that up - it doesn't need to be in 5102bis.
    The chairs will discuss the cleanup with IANA.
  - We will run this draft's WGLC before IETF-84 in Vancouver.

Brian presented our IE Doctors (Guidelines for Information Elements)
draft, he believes it is ready for WGLC.
  - We will start a WGLC for this draft early in May, further
    comments on it before May are welcome.

Brian presented our Mediation Protocol draft, it currently has five
open issues.  There was considerable discussion, particularly of how
a mediator should handle re-ordering of IEs.
  - discussion needs to continue on the list

Brian presented the Aggregation draft.  The chairs reported that we
now know and understand the IPR related to this draft.  Our Area
Directors pointed out that since we now have IPR disclosures for it,
we need to do another WGLC; Nevil will start this next week.

Paul Aitken presented the Data Link Monitoring draft, item 7 in
our current charter. The next version will be published as a -00
WG draft.  Two issues were discussed:
  - Some implementors want to use these IEs; can we simply ask IANA to
    allocate them?  Our ADs pointed out that that reviews may affect
    this draft; we need agreement on them at WGLC.
  - When it's published, 00 draft will need reviews from the WG, we
    will also ask IEEE 802.1q to review it.

Paul Aitken presented the Exporting MIB Objects draft; this is item 5
in our current charter.
  - The draft proposes introducing a new Set ID.  Brian commented
    that in doing so, we should make it a little more general by
    including a Set ID code point (maintained by IANA), with 'MIB
    Object' as its first entry.  Brian will post to the list.
Paul asked "could this be a WG item?"  The chairs response was
"it needs a lot more discussion on the list."

Paul Aitken presented the 'Unobserved Fields' draft, which considers
how IPFIX should report on IE's for which no value is available.
Chris White (Riverbed Technology) agreed that this is definitely
needed.  Discussion will continue on the list.

Paul Aitken presented a few slides on "better IEs for TCP Window
size."  More discussion on the list is encouraged.

Hendrik Scholtz presented his 'VoIP Information elements in IPFIX'
draft.  There was considerable discussion:
  - Could be merged with Aamer Akhter's work with SIP.
  - Useful work, should be done, but IPFIX is not the right place
    to define new metrics - we simply report them!
  - Can be reviewed by PMOL directorate, but needs to be done
    in a current WG
The chairs closed the discussion, leaving it to be continued
on the list.

Andrew Yourtchenko presented his 'Cisco Specific Information Elements
reused in IPFIX' draft.
  - Benoit Claise (our AD) commented that this draft should not clash
    with the Data Link Monitoring draft.
  - Juergen Qittek suggested that this should be integrated into that
    draft.
Discussion will continue on the list.

The meeting finished at 1941.

-- 
---------------------------------------------------------------------
  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


From aakhter@cisco.com  Sat Mar 31 00:16:55 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41E21E802B for ; Sat, 31 Mar 2012 00:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.306
X-Spam-Level: 
X-Spam-Status: No, score=-110.306 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mygWngIlRxpG for ; Sat, 31 Mar 2012 00:16:54 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 597AC21E800F for ; Sat, 31 Mar 2012 00:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6659; q=dns/txt; s=iport; t=1333178214; x=1334387814; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=iDxdO4GwLaumJKOlUl/nGm+KUYJduRDFb2mEncXePaI=; b=FZ46qRwHAM8LjvQuHJ33sitogGGiu8zUJwvh9qA0s2PHQF5V3sZA8m6y LwIhX4hf0Dz+JOk8F2HEtrQXEvf/PPNvnyMEfz9XQLLRsJgvNiS8jbuhD akDhL5Sb0slc7zJIKw8yKRmPvXE+LfDs9oWmfhB/7+kyF17IKlfoRRq8+ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAKuudk+tJV2Y/2dsb2JhbABFgka2N4EHggkBAQEEAQEBDwEJEQM+GwIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodnC5sannoEiweFKmMEiFibUIFogwWBPg
X-IronPort-AV: E=Sophos;i="4.75,347,1330905600"; d="scan'208,217";a="67978113"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 31 Mar 2012 07:16:53 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2V7GrcA023580;  Sat, 31 Mar 2012 07:16:53 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 31 Mar 2012 02:16:53 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0F0E.3F40C327"
Date: Sat, 31 Mar 2012 02:16:48 -0500
Message-ID: <7F298ACC76CC154F832B6D02852D169F079F4917@XMB-RCD-101.cisco.com>
In-Reply-To: <4F74A5CB.2010301@plixer.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Mail regarding draft-ietf-ipfix-protocol-rfc5101bis
thread-index: Ac0N113DbgLVV58WRGKWlR8mWfrZnQBNrGGQ
References: <7F298ACC76CC154F832B6D02852D169F079F43A7@XMB-RCD-101.cisco.com> <4F74A5CB.2010301@plixer.com>
From: "Aamer Akhter (aakhter)" 
To: "Andrew Feren" , 
X-OriginalArrivalTime: 31 Mar 2012 07:16:53.0274 (UTC) FILETIME=[3F7D2FA0:01CD0F0E]
Subject: Re: [IPFIX] Mail regarding draft-ietf-ipfix-protocol-rfc5101bis
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Mar 2012 07:16:55 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD0F0E.3F40C327
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Andrew-this is exactly what I was talking about.=20

=20

=20

From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
Of Andrew Feren
Sent: Thursday, March 29, 2012 2:11 PM
To: ipfix@ietf.org
Subject: Re: [IPFIX] Mail regarding draft-ietf-ipfix-protocol-rfc5101bis

=20

Hi Aamer,

Are you referring to to what used to be " 3.4.  Multiple Information
Elements of the Same Type"?  That text appears to have moved to " 8.
Template Management".

And to answer your question: " Collecting processes MUST properly handle
Templates with multiple identical Information Elements."

-Andrew

On 03/29/2012 12:14 PM, Aamer Akhter (aakhter) wrote:

	Regarding draft-ietf-ipfix-protocol-rfc5101bis-01:=20

	 =20

	I might have missed it but does the new specification detail how
a collector is to process multiple similar-type information elements?
This would be outside the context of RFC6313 (structured data).=20

	 =20

	For example, should the collector take only the first, the last,
or (preferably) record all of the elements?=20

	 =20

	Regards,=20

	aa=20

=09
=09
=09
=09

	_______________________________________________
	IPFIX mailing list
	IPFIX@ietf.org
	https://www.ietf.org/mailman/listinfo/ipfix

=20


------_=_NextPart_001_01CD0F0E.3F40C327
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Thanks Andrew—this is exactly what I was talking about. =

 
 
From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On =
Behalf Of Andrew Feren
Sent: Thursday, March 29, 2012 2:11 =
PM
To: ipfix@ietf.org
Subject: Re: [IPFIX] Mail =
regarding =
draft-ietf-ipfix-protocol-rfc5101bis
 
Hi =
Aamer,

Are you referring to to what used to be " 3.4.  =
Multiple Information Elements of the Same Type"?  That text =
appears to have moved to " 8.  Template =
Management".

And to answer your question: " Collecting =
processes MUST properly handle Templates with multiple identical =
Information Elements."

-Andrew

On 03/29/2012 12:14 =
PM, Aamer Akhter (aakhter) wrote:
Regarding =
draft-ietf-ipfix-protocol-rfc5101bis-01: 
  =

I might have missed it but does the new specification =
detail how a collector is to process multiple similar-type information =
elements? This would be outside the context of RFC6313 (structured =
data). 
  
For example, should =
the collector take only the first, the last, or (preferably) record all =
of the elements? 
  
Regards, =

aa 



_______________________=
________________________
IPFIX mailing =
list
IPFIX@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipfix
 

------_=_NextPart_001_01CD0F0E.3F40C327--