From ipfix-bounces@ietf.org Wed Apr 2 01:09:42 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC653A6B1B; Wed, 2 Apr 2008 01:09:42 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD593A6AF4 for ; Wed, 2 Apr 2008 01:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmPf0FkTtldM for ; Wed, 2 Apr 2008 01:09:38 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 862513A6B1B for ; Wed, 2 Apr 2008 01:09:37 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 10:09:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 10:09:22 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: expanding type and semantics registries (was Re: missing notes on exporting type...) thread-index: AciRHsFrsYiUUBRpRNi72/LEyz/n1ADcM2kQ References: From: To: X-OriginalArrivalTime: 02 Apr 2008 08:09:23.0869 (UTC) FILETIME=[DCB294D0:01C89498] Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1460499357==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1460499357== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89498.DC6D4404" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89498.DC6D4404 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brian, There is not doubt that the datamodel have to be extended in short term. = 'enumerated' is the right example. It is missing in the datamodel and it = is a ground truth storage datatype.=20 In the current approach, the adding of 'enumerated' as an abstract = datatype in the datamodel will require the update of = draft-ietf-ipfix-exporting-type because this draft defines a static = registry in the section "3.1. informationElementDataType". To avoid static pieces in the IPFIX datamodel in the future it is = mandatory to define an IPFIX IE for each abstract data types defined in = the IPFIX datamodel: octetArray =20 unsigned8 =20 unsigned16 =20 unsigned32 =20 unsigned64 =20 signed8 =20 signed16 =20 signed32 =20 signed64 =20 float32 =20 float64 =20 boolean =20 macAddress =20 string =20 dateTimeSeconds =20 dateTimeMilliseconds dateTimeMicroseconds dateTimeNanoseconds=20 ipv4Address =20 ipv6Address =20 The WG has the opportunity to do that with = draft-ietf-ipfix-exporting-type. Regards Emile > > The way the draft-ietf-ipfix-exporting-type defines types prevents > > adding new one in the future without updating the draft. There are > > already potential candidates: Enumerated, email, DNS, URL .... > -----Message d'origine----- > De : Brian Trammell [mailto:bht@cert.org] > Envoy=E9 : vendredi 28 mars 2008 22:57 > =C0 : STEPHAN Emile RD-CORE-LAN > Cc : ipfix@ietf.org > Objet : expanding type and semantics registries (was Re: missing notes = on > exporting type...) >=20 > Emile, >=20 > Ah, yes. Thanks. I remember now. My short, short answer on this was > "no, but..." >=20 > Here's why: >=20 > The data type and semantics registries are taken directly from RFC > 5102. This document doesn't seek to expand the types or semantics, it > only seeks to create formal IANA registries for a list of types > _already_ defined on the standards track. The reason behind creating > those registries is to map the types themselves to numeric codes used > to represent them in the informationElementDataType and > informationElementSemantics IEs. The reason behind declaring their > modification to be subject to a Standards Action as per RFC 2434 is to > ensure that >=20 > Adding a new data type to IPFIX is not simply a matter of sticking a > new name and number into the data type registry -- specific > information on the definition (as in section 3.1 of RFC 5102) and > encoding (as in section 6.1 of RFC 5101) of the data type must be > provided to allow the Exporting Process to properly encode and the > Collecting Process to properly decode and recognize data of that type. > Even if it's just a reference to an external standard (as 5101's > sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), > it's still absolutely necessary to have some document extending the > set of types for IPFIX to ensure interoperability of those new types. > And that's out of scope for _this_ document, which, as chartered, only > provides a _mechanism_ for describing the types already supported. >=20 > That said, you have a very good point. >=20 > There are quite a few types that could be immediately useful; and yes, > additional network-identifiers such as URL, email, and FQDN are > obvious first choices, which can only be implemented as Strings at the > moment. Enumerations are another issue, and can already be partially > implemented using the Reducing Redundancy mechanism. >=20 > My suggestion, however, would be a new document, to be considered for > a future WG charter, to _explicitly_ extend the set of types supported > by IPFIX, and adding those types to the registry created in exporting- > type. >=20 > Cheers, >=20 > Brian >=20 >=20 >=20 > On Mar 28, 2008, at 2:20 PM, wrote: > > Hi Brian, > > > > The way the draft-ietf-ipfix-exporting-type defines types prevents > > adding new one in the future without updating the draft. There are > > already potential candidates: Enumerated, email, DNS, URL .... > > > > Adding these types to the IPFIX datamodel increases the scope of > > usage of IPFIX and interoperability. It permits the usage of > > standard IE for exporting specific information. It permits the > > collector to store this information in an efficient way. It > > encourage enterprises to use standard IE instead of enterprises > > specific ones. > > > > > > Therefore the draft has to define them as IEs and the IANA section > > have to request IANA to add them the IPFIX datamodel registry. > > > > > > Regards > > > > Emile > > > > > > > -----Message d'origine----- > > > > > De : Brian Trammell [mailto:bht@cert.org] > > > > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > > > =C0 : STEPHAN Emile RD-CORE-LAN > > > > > Objet : missing notes on exporting type... > > > > > > > > > > Emile, > > > > > > > > > > As I recall, we had a conversation in Philadelphia about some > > specific > > > > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer for > > > > > your question, and I was going to post a message to the list about > > > > > that... but, I can't seem to find my note on the subject, and it's > > > > > been a rather eventful couple of weeks, and I have consequently > > > > > _completely_ forgotten it. > > > > > > > > > > So. > > > > > > > > > > Would you happen to remember what we were talking about, so we = could > > > > > perhaps start over on the subject? > > > > > > > > > > Thanks, > > > > > > > > > > Brian > > ------_=_NextPart_001_01C89498.DC6D4404 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: expanding type and semantics registries (was Re: missing = notes on exporting type...)

Hi = Brian,

There is not doubt that the datamodel have = to be extended in = short term. 'enumerated' is the right example. It is missing in the datamodel and it is a ground truth storage = datatype.

In = the current approach, = the adding of 'enumerated' as an abstract datatype in the datamodel will = require the update = of draft-ietf-ipfix-exporting-type = because this draft defines a static = registry in the section "3.1.  = informationElementDataType".

To = avoid static pieces in the IPFIX datamodel in the future = it is mandatory = to define an IPFIX = IE for each abstract = data types defined in the IPFIX = datamodel:

    octetArray          =

    unsigned8          = ;

    unsigned16          =

    unsigned32          =

    unsigned64          =

    signed8          &= nbsp; 

    signed16          =  

    signed32          =  

    signed64          =  

    float32          &= nbsp; 

    float64          &= nbsp; 

    boolean          &= nbsp; 

    macAddress          =

    string          &n= bsp;  

    dateTimeSeconds    

    dateTimeMilliseconds

    dateTimeMicroseconds

    dateTimeNanoseconds

    ipv4Address         =

    ipv6Address        

The WG has the = opportunity to do that = with draft-ietf-ipfix-exporting-type.

Regards

Emile

> > The way the draft-ietf-ipfix-exporting-type defines types = prevents

> > adding new one in the future without updating the draft. = There are

> > already potential candidates: Enumerated, email, DNS, URL = ....

> = -----Message = d'origine-----

> = De=A0: Brian Trammell [mailto:bht@cert.org]

> = Envoy=E9=A0: = vendredi 28 mars 2008 22:57

> = =C0=A0: = STEPHAN Emile RD-CORE-LAN

> = Cc=A0: ipfix@ietf.org

> = Objet=A0: expanding type and semantics registries (was Re: = missing notes on

> = exporting type...)

>

> Emile,

>

> Ah, yes. Thanks. I remember now. My short, short = answer on this was

> "no, but..."

>

> Here's why:

>

> The data type and semantics registries are taken = directly from RFC

> 5102. = This document doesn't seek to expand the types or semantics, = it

> only seeks to create formal IANA registries for a = list of types

> _already_ defined on the standards track. The = reason behind creating

> those registries is to map the types = themselves to numeric codes = used

> to represent them in the informationElementDataType = and

> informationElementSemantics IEs. The reason behind = declaring their

> modification to be subject to a Standards Action as = per RFC 2434 is to

> ensure that

>

> Adding a new data type to IPFIX is not simply a = matter of sticking a

> new name and number into the data type registry -- = specific

> information on the definition (as in section 3.1 of = RFC 5102) and

> encoding (as in section 6.1 of RFC 5101) of the = data type must = be

> provided to allow the Exporting Process to properly = encode and the

> Collecting Process to properly decode and recognize = data of that type.

> Even if it's just a reference to an external = standard (as 5101's

> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point = types),

> it's still absolutely necessary to have some = document extending the

> set of types for IPFIX to ensure interoperability = of those new types.

> X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC653A6B1B; Wed, 2 Apr 2008 01:09:42 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD593A6AF4 for ; Wed, 2 Apr 2008 01:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmPf0FkTtldM for ; Wed, 2 Apr 2008 01:09:38 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 862513A6B1B for ; Wed, 2 Apr 2008 01:09:37 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 10:09:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 10:09:22 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: expanding type and semantics registries (was Re: missing notes on exporting type...) thread-index: AciRHsFrsYiUUBRpRNi72/LEyz/n1ADcM2kQ References: From: To: X-OriginalArrivalTime: 02 Apr 2008 08:09:23.0869 (UTC) FILETIME=[DCB294D0:01C89498] Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1460499357==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1460499357== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89498.DC6D4404" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89498.DC6D4404 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brian, There is not doubt that the datamodel have to be extended in short term. = 'enumerated' is the right example. It is missing in the datamodel and it = is a ground truth storage datatype.=20 In the current approach, the adding of 'enumerated' as an abstract = datatype in the datamodel will require the update of = draft-ietf-ipfix-exporting-type because this draft defines a static = registry in the section "3.1. informationElementDataType". To avoid static pieces in the IPFIX datamodel in the future it is = mandatory to define an IPFIX IE for each abstract data types defined in = the IPFIX datamodel: octetArray =20 unsigned8 =20 unsigned16 =20 unsigned32 =20 unsignedONT SIZE=3D2 = FACE=3D"Courier New">And that's out of scope for _this_ document, which, = as chartered, only

> provides = a _mechanism_ for describing the types already = supported.

>

> That said, you have a very good = point.

>

> There are quite a few types that could be = immediately useful; and yes,

> additional network-identifiers such as URL, email, = and FQDN are

> obvious first choices, which can only be implemented as Strings at = the

> moment. Enumerations are another issue, and can = already be partially

> implemented using the Reducing Redundancy = mechanism.

>

> My suggestion, however, would be a new document, to = be considered for

> a future WG charter, to _explicitly_ extend the set = of types supported

> by IPFIX, and adding those types to the registry = created in exporting-

> type.

>

> Cheers,

>

> Brian

>

> The way the draft-ietf-ipfix-exporting-type defines types prevents > > adding new one in the future without updating the draft. There are > > already potential candidates: Enumerated, email, DNS, URL .... > -----Message d'origine----- > De : Brian Trammell [mailto:bht@cert.org] > Envoy=E9 : vendredi 28 mars 2008 22:57 > =C0 : STEPHAN Emile RD-CORE-LAN > Cc : ipfix@ietf.org > Objet : expanding type and semantics registries (was Re: missing notes = on > exporting type...) >=20 > Emile, >=20 > Ah, yes. Thanks. I remember now. My short, short answer on this was > "no, but..." >=20 > Here's why: >=20 > The data type and semantics registries are taken directly from RFC > 5102. This document doesn't seek to expand the types or semantics, it > only seeks to create formal IANA registries for a list of types > _already_ defined on the standards track. The reason behind creating > those registries is to map the types themselves to numeric codes used > to represent them in the informationElementDataType and > informationElementSemantics IEs. The reason behind declaring their > modification to be subject to a Standards Action as per RFC 2434 is to > ensure that >=20 > Adding a new data type to IPFIX is not simply a matter of sticking a > new name and number into the data type registry -- specific > information on the definition (as in section 3.1 of RFC 5102) and > encoding (as in section 6.1 of RFC 5101) of the data type must be > provided to allow the Exporting Process to properly encode and the > Collecting Process to properly decode and recognize data of that type. > Even if it's just a reference to an external standard (as 5101's > sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), > it's still absolutely necessary to have some document extending the > set of types for IPFIX to ensure interoperability of those new types. > And that's out of scope for _this_ document, which, as chartered, only > provides a _mechanism_ for describing the types already supported. >=20 > That said, you have a very good point. >=20 > There are quite a few types that could be immediately useful; and yes, > additional network-identifiers such as URL, email, and FQDN are > obvious first choices, which can only be implemented as Strings at the > moment. Enumerations are another issue, and can already be partially > implemented using the Reducing Redundancy mechanism. >=20 > My suggestion, however, would be a new document, to be considered for > a future WG charter, to _explicitly_ extend the set of types supported > by IPFIX, and adding those types to the registry created in exporting- > type. >=20 > Cheers, >=20 > Brian >=20 >=20 >=20 > On Mar 28, 2008, at 2:20 PM, wrote: > > Hi Brian, > > > > The way the draft-ietf-ipfix-exporting-type defines types prevents > > adding new one in the future without updating the draft. There are > > already potential candidates: Enumerated, email, DNS, URL .... > > > > Adding these types to the IPFIX datamodel increases the scope of > > usage of IPFIX and interoperability. It permits the usage of > > standard IE for exporting specific information. It permits the > > collector to store this information in an efficient way. It > > encourage enterprises to use standard IE instead of enterprises > > specific ones. > > > > > > Therefore the draft has to define them as IEs and the IANA section > > have to request IANA to add them the IPFIX datamodel registry. > > > > > > Regards > > > > Emile > > > > > > > -----Message d'origine----- > > > > > De : Brian Trammell [mailto:bht@cert.org] > > > > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > > > =C0 : STEPHAN Emile RD-CORE-LAN > > > > > Objet : missing notes on exporting type... > > > > > > > > > > Emile, > > > > > > > > > > As I recall, we had a conversation in Philadelphia about some > > specific > > > > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer for > > > > > your question, and I was going to post a message to the list about > > > > > that... but, I can't seem to find my note on the subject, and it's > > > > > been a rather eventful couple of weeks, and I have consequently > > > > > _completely_ forgotten it. > > > > > > > > > > So. > > > > > > > > > > Would you happen to remember what we were talking about, so we = could > > > > > perhaps start over on the subject? > > > > > > > > > > Thanks, > > > > > > > > > > Brian > > ------_=_NextPart_001_01C89498.DC6D4404 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: expanding type and semantics registries (was Re: missing = notes on exporting type...)

Hi = Brian,

There is not doubt that the datamodel have = to be extended in = short term. 'enumerated' is the right example. It is missing in the datamodel and it is a ground truth storage = datatype.

In = the current approach, = the adding of 'enumerated' as an abstract datatype in the datamodel will = require the update = of draft-ietf-ipfix-exporting-type = because this draft defines a static = registry in the section "3.1.  = informationElementDataType".

To = avoid static pieces in the IPFIX datamodel in the future = it is mandatory = to define an IPFIX = IE for each abstract = data types defined in the IPFIX = datamodel:

    octetArray          =

    unsigned8          = ;

    unsigned16          =

    unsigned32          =

    unsigned64          =

    signed8          &= nbsp; 

    signed16          =  

    signed32          =  

    signed64          =  

    float32          &= nbsp; 

    float64          &= nbsp; 

    boolean          &= nbsp; 

    macAddress          =

    string          &n= bsp;  

    dateTimeSeconds    

    dateTimeMilliseconds

    dateTimeMicroseconds

    dateTimeNanoseconds

    ipv4Address         =

    ipv6Address        

The WG has the = opportunity to do that = with draft-ietf-ipfix-exporting-type.

Regards

Emile

> > The way the draft-ietf-ipfix-exporting-type defines types = prevents

> > adding new one in the future without updating the draft. = There are

> > already potential candidates: Enumerated, email, DNS, URL = ....

> = -----Message = d'origine-----

> = De=A0: Brian Trammell [mailto:bht@cert.org]

> = Envoy=E9=A0: = vendredi 28 mars 2008 22:57

> = =C0=A0: = STEPHAN Emile RD-CORE-LAN

> = Cc=A0: ipfix@ietf.org

> = Objet=A0: expanding type and semantics registries (was Re: = missing notes on

> = exporting type...)

>

> Emile,

>

> Ah, yes. Thanks. I remember now. My short, short = answer on this was

> "no, but..."

>

> Here's why:

>

> The data type and semantics registries are taken = directly from RFC

> 5102. = This document doesn't seek to expand the types or semantics, = it

> only seeks to create formal IANA registries for a = list of types

> _already_ defined on the standards track. The = reason behind creating

> those registries is to map the typN LANG=3D"en-us">>

>

> On Mar 28, 2008, at 2:20 PM, = <emile.stephan@orange-ftgroup.com> wrote:

> > Hi Brian,

> >

> > The way the draft-ietf-ipfix-exporting-type = defines types prevents

> > adding new one in the future without updating = the draft. There are

> > already potential candidates: Enumerated, = email, DNS, URL ....

> >

> > Adding these types to the IPFIX datamodel = increases the scope = of

> > usage of IPFIX and interoperability. It = permits the usage of

> > standard IE for exporting specific = information. It permits the

> > collector to store this information in an = efficient way. It

> > encourage enterprises to use = standard IE instead of = enterprises

> > specific ones.

> >

> >

> > Therefore tes = themselves to numeric codes = used

> to represent them in the informationElementDataType = and

> informationElementSemantics IEs. The reason behind = declaring their

> modification to be subject to a Standards Action as = per RFC 2434 is to

> ensure that

>

> Adding a new data type to IPFIX is not simply a = matter of sticking a

> new name and number into the data type registry -- = specific

> information on the definition (as in section 3.1 of = RFC 5102) and

> encoding (as in section 6.1 of RFC 5101) of the = data type must = be

> provided to allow the Exporting Process to properly = encode and the

> Collecting Process to properly decode and recognize = data of that type.

> Even if it's just a reference to an external = standard (as 5101's

> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point = types),

> it's still absolutely necessary to have some = document extending the

> set of types for IPFIX to ensure interoperability = of those new types.

>

> > have to request IANA to add them the IPFIX = datamodel registry.

> >

> >

> > Regards

> >

> > Emile

> >

> >

> > > -----Message = d'origine-----

> >

> > > De : Brian Trammell [mailto:bht@cert.org]

> >

> > > Envoy=E9 : vendredi 28 mars 2008 = 02:11

> >

> > > =C0 : STEPHAN Emile = RD-CORE-LAN

> >

> > > Objet : missing notes on exporting = type...

> >

And that's out of scope for _this_ document, which, = as chartered, only

> provides = a _mechanism_ for describing the types already = supported.

>

> That said, you have a very good = point.

>

> There are quite a few types that could be = immediately useful; and yes,

> additional network-identifiers such as URL, email, = and FQDN are

> obvious first choices, which can only be implemented as Strings at = the

> moment. Enumerations are another issue, and can = already be partially

> implemented using the Reducing Redundancy = mechanism.

>

> My suggestion, however, would be a new document, to = be considered for

> a future WG charter, to _explicitly_ extend the set = of types supported

> by IPFIX, and adding those types to the registry = created in exporting-

> type.

>

> Cheers,

>

> Brian

>

> > >

> >

> > > Emile,

> >

> > >

> >

> > > As I recall, we had a conversation in = Philadelphia about = some

> > specific

> >

> > > aspect of = draft-ietf-ipfix-exporting-type, and I had an answer = for

> >

> > > your question, and I was going to post a = message to the list about

> >

> > > that... but, I can't seem to find my note = on the subject, and it's

> >

> > > been a rather eventful couple of weeks, and I have = consequently

> >

> > > _completely_ forgotten =LANG=3D"en-us">>

>

> On Mar 28, 2008, at 2:20 PM, = <emile.stephan@orange-ftgroup.com> wrote:

> > Hi Brian,

> >

> > The way the draft-ietf-ipfix-exporting-type = defines types prevents

> > adding new one in the future without updating = the draft. There are

> > already potential candidates: Enumerated, = email, DNS, URL ....

> >

> > Adding these types to the IPFIX datamodel = increases the scope = of

> > usage of IPFIX and interoperability. It = permits the usage of

> > standard IE for exporting specific = information. It permits the

> > collector to store this information in an = efficient way. It

> > encourage enterprises to use = standard IE instead of = enterprises

> > specific ones.

> >

> >

> > Therefore the it.

> >

> > >

> >

> > > So.

> >

> > >

> >

> > > Would you happen to remember what we were = talking about, so we could

> >

> > > perhaps start over on the = subject?

> >

> > >

> >

> > > Thanks,

> >

> > >

> >

> > > Brian

> >

------_=_NextPart_001_01C89498.DC6D4404-- --===============1460499357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1460499357==-- draft has to define them as IEs = and the IANA section

> > have to request IANA to add them the IPFIX = datamodel registry.

> >

> >

> > Regards

> >

> > Emile

> >

> >

> > > -----Message = d'origine-----

> >

> > > De : Brian Trammell [mailto:bht@cert.org]

> >

> > > Envoy=E9 : vendredi 28 mars 2008 = 02:11

> >

> > > =C0 : STEPHAN Emile = RD-CORE-LAN

> >

> > > Objet : missing notes on exporting = type...

> >

> > >

> >

> > > Emile,

> >

> > >

> >

> > > As I recall, we had a conversation in = Philadelphia about = some

> > specific

> >

> > > aspect of = draft-ietf-ipfix-exporting-type, and I had an answer = for

> >

> > > your question, and I was going to post a = message to the list about

> >

> > > that... but, I can't seem to find my note = on the subject, and it's

> >

> > > been a rather eventful couple of weeks, and I have = consequently

> >

> > > _completely_ forgotten = it.

> >

> > >

> >

> > > So.

> >

> > >

> >

> > > Would you happen to remember what we were = talking about, so we could

> >

> > > perhaps start over on the = subject?

> >

> > >

> >

> > > Thanks,

> >

> > >

> >

> > > Brian

> >

------_=_NextPart_001_01C89498.DC6D4404-- --===============1460499357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1460499357==-- From hekmagnaridersvez@magnariders.com Wed Apr 2 06:02:01 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2232E3A6A1B; Wed, 2 Apr 2008 06:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.995 X-Spam-Level: **** X-Spam-Status: No, score=4.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hUKnGn6hzTT; Wed, 2 Apr 2008 06:02:00 -0700 (PDT) Received: from dxb-b138587.alshamil.net.ae (dxb-b138587.alshamil.net.ae [86.98.88.233]) by core3.amsl.com (Postfix) with ESMTP id D256B28C4EB; Wed, 2 Apr 2008 05:59:52 -0700 (PDT) Received: from [86.98.88.233] by mail.domainnameservers.net; Wed, 2 Apr 2008 04:59:54 -0800 Date: Wed, 2 Apr 2008 04:59:54 -0800 From: "Selma Denton" X-Mailer: The Bat! (v2.11) Educational Reply-To: hekmagnaridersvez@magnariders.com X-Priority: 3 (Normal) Message-ID: <513892957.08868425477326@magnariders.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------33AE90901D33A7C4" ------------33AE90901D33A7C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our purpose is to render low price PC and Macintosh lawful soft and computer solutions for anyone's budget. Whether you are a corporate client, an owner of small enterprise, or go shopping for your home PC, we suppose we'll assist you. SEE WHAT WE GOT TO OFFER! http://shelbysodenkq945.blogspot.com ------------33AE90901D33A7C4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our purpose is to render low price PC and Macintosh lawful soft and computer solutions for anyone's budget.
Whether you are a corporate client, an owner of small enterprise,
or go shopping for your home PC, we suppose we'll assist you.
SEE WHAT WE GOT TO OFFER!
http://shelbysodenkq945.blogspot.com
------------33AE90901D33A7C4-- From ipfix-bounces@ietf.org Thu Apr 3 07:11:25 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8CA28C659; Thu, 3 Apr 2008 07:11:25 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062043A6BCC for ; Thu, 3 Apr 2008 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUum6xlIiVbL for ; Thu, 3 Apr 2008 07:11:21 -0700 (PDT) Received: from gatekeeper.hitachi-eu.com (gatekeeper.hitachi-eu.com [194.36.128.25]) by core3.amsl.com (Postfix) with ESMTP id B00D63A6B94 for ; Thu, 3 Apr 2008 07:11:17 -0700 (PDT) X-ASG-Debug-ID: 1207231878-74aa01000000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi Received: from mhd-mta-int.hitachi-eu.com (localhost [127.0.0.1]) by gatekeeper.hitachi-eu.com (Spam Firewall) with ESMTP id 5996C1DB990 for ; Thu, 3 Apr 2008 15:11:18 +0100 (BST) Received: from mhd-mta-int.hitachi-eu.com ([193.39.225.234]) by gatekeeper.hitachi-eu.com with ESMTP id JqP1tCMBGdI109f3 for ; Thu, 03 Apr 2008 15:11:18 +0100 (BST) X-ASG-Whitelist: Client Received: from MHDEXC99.adhel.hitachi-eu.com (Not Verified[193.39.227.52]) by mhd-mta-int.hitachi-eu.com with MailMarshal (v6, 2, 1, 3252) id ; Thu, 03 Apr 2008 14:11:17 +0000 Received: from mhdexcb.adhel.hitachi-eu.com ([193.39.227.47]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:11:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) Date: Thu, 3 Apr 2008 15:10:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) Thread-Index: AciVlHB9aVD6xzkRTbizvmZsvboNJw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 03 Apr 2008 14:11:17.0311 (UTC) FILETIME=[9554A4F0:01C89594] X-Barracuda-Connect: UNKNOWN[193.39.225.234] X-Barracuda-Start-Time: 1207231878 X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164907097==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1164907097== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89594.9566D74F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89594.9566D74F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emile, > There is not doubt that the datamodel have to be extended in short term= .=20 > 'enumerated' is the right example. It is missing in the datamodel and i= t=20 > is a ground truth storage datatype. > > In the current approach, the adding of 'enumerated' as an abstract=20 > datatype in the datamodel will require the update of=20 > draft-ietf-ipfix-exporting-type because this draft defines a static=20 > registry in the section "3.1. informationElementDataType". >=20 maybe the data model will have to be extended, but this would be an infor= mation model extension (i.e. an update of RFC5102) and I don't think it b= elongs logically to a method description for exporting information model = information on the wire.=20 Of course changes in the information model are likely to affect this docu= ment too... > To avoid static pieces in the IPFIX datamodel in the future it is=20 > mandatory to define an IPFIX IE for each abstract data types defined in= =20 > the IPFIX datamodel: >=20 > octetArray =20 > unsigned8 =20 > unsigned16 =20 > unsigned32 =20 > unsigned64 =20 > signed8 =20 > signed16 =20 > signed32 =20 > signed64 =20 > float32 =20 > float64 =20 > boolean =20 > macAddress =20 > string =20 > dateTimeSeconds =20 > dateTimeMilliseconds > dateTimeMicroseconds > dateTimeNanoseconds > ipv4Address =20 > ipv6Address =20 >=20 > The WG has the opportunity to do that with draft-ietf-ipfix-exporting-t= ype. >=20 I understand your concern, but I think that this is out of scope for this= =20document. If the working group wants to add this flexibility I suggest= =20opening a separate thread on this to discuss how this issue should be = addressed. thanks, Elisa > Regards >=20 > Emile >=20 >> > The way the draft-ietf-ipfix-exporting-type defines types prevents >=20 >> > adding new one in the future without updating the draft. There are >=20 >> > already potential candidates: Enumerated, email, DNS, URL .... >=20 >> -----Message d'origine----- >=20 >> De : Brian Trammell [mailto:bht@cert.org] >=20 >> Envoy=E9 : vendredi 28 mars 2008 22:57 >=20 >> =C0 : STEPHAN Emile RD-CORE-LAN >=20 >> Cc : ipfix@ietf.org >=20 >> Objet : expanding type and semantics registries (was Re: missing note= s on >=20 >> exporting type...) >=20 >> >=20 >> Emile, >=20 >> >=20 >> Ah, yes. Thanks. I remember now. My short, short answer on this was >=20 >> "no, but..." >=20 >> >=20 >> Here's why: >=20 >> >=20 >> The data type and semantics registries are taken directly from RFC >=20 >> 5102. This document doesn't seek to expand the types or semantics, it= >=20 >> only seeks to create formal IANA registries for a list of types >=20 >> _already_ defined on the standards track. The reason behind creating >=20 >> those registries is to map the types themselves to numeric codes used= >=20 >> to represent them in the informationElementDataType and >=20 >> informationElementSemantics IEs. The reason behind declaring their >=20 >> modification to be subject to a Standards Action as per RFC 2434 is t= o >=20 >> ensure that >=20 >> >=20 >> Adding a new data type to IPFIX is not simply a matter of sticking a >=20 >> new name and number into the data type registry -- specific >=20 >> information on the definition (as in section 3.1 of RFC 5102) and >=20 >> encoding (as in section 6.1 of RFC 5101) of the data type must be >=20 >> provided to allow the Exporting Process to properly encode and the >=20 >> Collecting Process to properly decode and recognize data of that type= . >=20 >> Even if it's just a reference to an external standard (as 5101's >=20 >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), >=20 >> it's still absolutely necessary to have some document extending the >=20 >> set of types for IPFIX to ensure interoperability of those new types.= >=20 >> And that's out of scope for _this_ document, which, as chartered, onl= y >=20 >> provides a _mechanism_ for describing the types already supported. >=20 >> >=20 >> That said, you have a very good point. >=20 >> >=20 >> There are quite a few types that could be immediately useful; and yes= , >=20 >> additional network-identifiers such as URL, email, and FQDN are >=20 >> obvious first choices, which can only be implemented as Strings at th= e >=20 >> moment. Enumerations are another issue, and can already be partially >=20 >> implemented using the Reducing Redundancy mechanism. >=20 >> >=20 >> My suggestion, however, would be a new document, to be considered for= >=20 >> a future WG charter, to _explicitly_ extend the set of types supporte= d >=20 >> by IPFIX, and adding those types to the registry created in exporting= - >=20 >> type. >=20 >> >=20 >> Cheers, >=20 >> >=20 >> Brian >=20 >> >=20 >> >=20 >> >=20 >> On Mar 28, 2008, at 2:20 PM, wrote= : >=20 >> > Hi Brian, >=20 >> > >=20 >> > The way the draft-ietf-ipfix-exporting-type defines types prevents >=20 >> > adding new one in the future without updating the draft. There are >=20 >> > already potential candidates: Enumerated, email, DNS, URL .... >=20 >> > >=20 >> > Adding these types to the IPFIX datamodel increases the scope of >=20 >> > usage of IPFIX and interoperability. It permits the usage of >=20 >> > standard IE for exporting specific information. It permits the >=20 >> > collector to store this information in an efficient way. It >=20 >> > encourage enterprises to use standard IE instead of enterprises >=20 >> > specific ones. >=20 >> > >=20 >> > >=20 >> > Therefore the draft has to define them as IEs and the IANA section >=20 >> > have to request IANA to add them the IPFIX datamodel registry. >=20 >> > >=20 >> > >=20 >> > Regards >=20 >> > >=20 >> > Emile >=20 >> > >=20 >> > >=20 >> > > -----Message d'origine----- >=20 >> > >=20 >> > > De : Brian Trammell [mailto:bht@cert.org] >=20 >> > >=20 >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 >=20 >> > >=20 >> > > =C0 : STEPHAN Emile RD-CORE-LAN >=20 >> > >=20 >> > > Objet : missing notes on exporting type... >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Emile, >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > As I recall, we had a conversation in Philadelphia about some >=20 >> > specific >=20 >> > >=20 >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer fo= r >=20 >> > >=20 >> > > your question, and I was going to post a message to the list abou= t >=20 >> > >=20 >> > > that... but, I can't seem to find my note on the subject, and it'= s >=20 >> > >=20 >> > > been a rather eventful couple of weeks, and I have consequently >=20 >> > >=20 >> > > _completely_ forgotten it. >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > So. >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Would you happen to remember what we were talking about, so we co= uld >=20 >> > >=20 >> > > perhaps start over on the subject? >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Thanks, >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Brian *************************************************************************= *************************=20 E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are in= tended solely for the use=20 of the individual or entity to which they are addressed. Access to this e= -mail by anyone else is=20 unauthorised. If you are not the intended recipient, any disclosure, copy= ing, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-m= ail messages are not=20 necessarily secure. Hitachi does not accept responsibility for any change= s made to this message=20 after it was sent.=20 Hitachi checks outgoing e-mail messages for the presence of computer viru= ses.=20 *************************************************************************= ************************* ------_=_NextPart_001_01C89594.9566D74F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] expanding type and semantics registries (was Re: missi= ng notes on exporting type...)

Emile,

> There is not doubt that the datamodel have to be extended in short t= erm.
> 'enumerated' is the right example. It is missing in the datamodel an= d it
> is a ground truth storage datatype.
>
> In the current approach, the adding of 'enumerated' as an abstract > datatype in the datamodel will require the update of
> draft-ietf-ipfix-exporting-type because this draft defines a static<= BR> > registry in the section "3.1.  informationElementDataType&= quot;.
>

maybe the data model will have to be extended, but this would be an infor= mation model extension (i.e. an update of RFC5102) and I don't think it b= elongs logically to a method description for exporting information model = information on the wire.
Of course changes in the information model are likely to affect this docu= ment too...


> To avoid static pieces in the IPFIX datamodel in the future it is > mandatory to define an IPFIX IE for each abstract data types defined= =20in
> the IPFIX datamodel:
>
>       octetArray   &nbs= p;    
>       unsigned8    = ;     
>       unsigned16   &nbs= p;    
>       unsigned32   &nbs= p;    
>       unsigned64   &nbs= p;    
>       signed8    &= nbsp;      
>       signed16    =       
>       signed32    =       
>       signed64    =       
>       float32    &= nbsp;      
>       float64    &= nbsp;      
>       boolean    &= nbsp;      
>       macAddress   &nbs= p;    
>       string    &n= bsp;       
>       dateTimeSeconds   = ;
>       dateTimeMilliseconds
>       dateTimeMicroseconds
>       dateTimeNanoseconds
>       ipv4Address   &nb= sp;   
>       ipv6Address   &nb= sp;   
>
> The WG has the opportunity to do that with draft-ietf-ipfix-exportin= g-type.
>

I understand your concern, but I think that this is out of scope for this= =20document. If the working group wants to add this flexibility I suggest= =20opening a separate thread on this to discuss how this issue should be = addressed.

thanks,
Elisa

> Regards
>
> Emile
>
>>  > The way the draft-ietf-ipfix-exporting-type defines t= ypes prevents
>
>>  > adding new one in the future without updating the dra= ft. There are
>
>>  > already potential candidates: Enumerated, email, DNS,= =20URL ....
>
>>  -----Message d'origine-----
>
>>  De : Brian Trammell [mailt= o:bht@cert.org]
>
>>  Envoy=E9 : vendredi 28 mars 2008 22:57
>
>>  =C0 : STEPHAN Emile RD-CORE-LAN
>
>>  Cc : ipfix@ietf.org
>
>>  Objet : expanding type and semantics registries (was Re: m= issing notes on
>
>>  exporting type...)
>
>>
>
>>  Emile,
>
>>
>
>>  Ah, yes. Thanks. I remember now. My short, short answer on= =20this was
>
>>  "no, but..."
>
>>
>
>>  Here's why:
>
>>
>
>>  The data type and semantics registries are taken directly = from RFC
>
>>  5102. This document doesn't seek to expand the types or se= mantics, it
>
>>  only seeks to create formal IANA registries for a list of = types
>
>>  _already_ defined on the standards track. The reason behin= d creating
>
>>  those registries is to map the types themselves to numeric= =20codes used
>
>>  to represent them in the informationElementDataType and >
>>  informationElementSemantics IEs. The reason behind declari= ng their
>
>>  modification to be subject to a Standards Action as per RF= C 2434 is to
>
>>  ensure that
>
>>
>
>>  Adding a new data type to IPFIX is not simply a matter of = sticking a
>
>>  new name and number into the data type registry -- specifi= c
>
>>  information on the definition (as in section 3.1 of RFC 51= 02) and
>
>>  encoding (as in section 6.1 of RFC 5101) of the data type = must be
>
>>  provided to allow the Exporting Process to properly encode= =20and the
>
>>  Collecting Process to properly decode and recognize data o= f that type.
>
>>  Even if it's just a reference to an external standard (as = 5101's
>
>>  sections 6.1.3. and 6.1.4. do to IEEE 754 for floating poi= nt types),
>
>>  it's still absolutely necessary to have some document exte= nding the
>
>>  set of types for IPFIX to ensure interoperability of those= =20new types.
>
>>  And that's out of scope for _this_ document, which, as cha= rtered, only
>
>>  provides a _mechanism_ for describing the types already su= pported.
>
>>
>
>>  That said, you have a very good point.
>
>>
>
>>  There are quite a few types that could be immediately usef= ul; and yes,
>
>>  additional network-identifiers such as URL, email, and FQD= N are
>
>>  obvious first choices, which can only be implemented as St= rings at the
>
>>  moment. Enumerations are another issue, and can already be= =20partially
>
>>  implemented using the Reducing Redundancy mechanism.
>
>>
>
>>  My suggestion, however, would be a new document, to be con= sidered for
>
>>  a future WG charter, to _explicitly_ extend the set of typ= es supported
>
>>  by IPFIX, and adding those types to the registry created i= n exporting-
>
>>  type.
>
>>
>
>>  Cheers,
>
>>
>
>>  Brian
>
>>
>
>>
>
>>
>
>>  On Mar 28, 2008, at 2:20 PM, <emile.stephan@orange-ftgr= oup.com> wrote:
>
>>  > Hi Brian,
>
>>  >
>
>>  > The way the draft-ietf-ipfix-exporting-type defines t= ypes prevents
>
>>  > adding new one in the future without updating the dra= ft. There are
>
>>  > already potential candidates: Enumerated, email, DNS,= =20URL ....
>
>>  >
>
>>  > Adding these types to the IPFIX datamodel increases t= he scope of
>
>>  > usage of IPFIX and interoperability. It permits the u= sage of
>
>>  > standard IE for exporting specific information. It pe= rmits the
>
>>  > collector to store this information in an efficient w= ay. It
>
>>  > encourage enterprises to use standard IE instead of e= nterprises
>
>>  > specific ones.
>
>>  >
>
>>  >
>
>>  > Therefore the draft has to define them as IEs and the= =20IANA section
>
>>  > have to request IANA to add them the IPFIX datamodel = registry.
>
>>  >
>
>>  >
>
>>  > Regards
>
>>  >
>
>>  > Emile
>
>>  >
>
>>  >
>
>>  > > -----Message d'origine-----
>
>>  >
>
>>  > > De : Brian Trammell [mailto:bht@cert.org]
>
>>  >
>
>>  > > Envoy=E9 : vendredi 28 mars 2008 02:11
>
>>  >
>
>>  > > =C0 : STEPHAN Emile RD-CORE-LAN
>
>>  >
>
>>  > > Objet : missing notes on exporting type...
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Emile,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > As I recall, we had a conversation in Philadelph= ia about some
>
>>  > specific
>
>>  >
>
>>  > > aspect of draft-ietf-ipfix-exporting-type, and I= =20had an answer for
>
>>  >
>
>>  > > your question, and I was going to post a message= =20to the list about
>
>>  >
>
>>  > > that... but, I can't seem to find my note on the= =20subject, and it's
>
>>  >
>
>>  > > been a rather eventful couple of weeks, and I ha= ve consequently
>
>>  >
>
>>  > > _completely_ forgotten it.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > So.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Would you happen to remember what we were talkin= g about, so we could
>
>>  >
>
>>  > > perhaps start over on the subject?
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Thanks,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Brian

************= *************************************************************************= *************
E-mail=20 Confidentiality Notice and Disclaimer.

This e-mail and any files transmitted with it are confiden= tial and=20 are intended solely for the use of the individual or entity to which they= =20are=20 addressed. Access to this e-mail by anyone else is unauthorised. If you a= re not=20 the intended recipient, any disclosure, copying, distribution or any acti= on=20 taken or omitted to be taken in reliance on it, is prohibited.
E-mail= =20 messages are not necessarily secure.
Hitachi does not accept responsi= bility=20 for any changes made to this message after it was sent.
Hitachi checks= =20 outgoing e-mail messages for the presence of computer viruses.=20
*********************************************************************= *****************************=20

------_=_NextPart_001_01C89594.9566D74F-- --===============1164907097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1164907097==-- From ipfix-bounces@ietf.org Thu Apr 3 07:11:25 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8CA28C659; Thu, 3 Apr 2008 07:11:25 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062043A6BCC for ; Thu, 3 Apr 2008 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUum6xlIiVbL for ; Thu, 3 Apr 2008 07:11:21 -0700 (PDT) Received: from gatekeeper.hitachi-eu.com (gatekeeper.hitachi-eu.com [194.36.128.25]) by core3.amsl.com (Postfix) with ESMTP id B00D63A6B94 for ; Thu, 3 Apr 2008 07:11:17 -0700 (PDT) X-ASG-Debug-ID: 1207231878-74aa01000000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi Received: from mhd-mta-int.hitachi-eu.com (localhost [127.0.0.1]) by gatekeeper.hitachi-eu.com (Spam Firewall) with ESMTP id 5996C1DB990 for ; Thu, 3 Apr 2008 15:11:18 +0100 (BST) Received: from mhd-mta-int.hitachi-eu.com ([193.39.225.234]) by gatekeeper.hitachi-eu.com with ESMTP id JqP1tCMBGdI109f3 for ; Thu, 03 Apr 2008 15:11:18 +0100 (BST) X-ASG-Whitelist: Client Received: from MHDEXC99.adhel.hitachi-eu.com (Not Verified[193.39.227.52]) by mhd-mta-int.hitachi-eu.com with MailMarshal (v6, 2, 1, 3252) id ; Thu, 03 Apr 2008 14:11:17 +0000 Received: from mhdexcb.adhel.hitachi-eu.com ([193.39.227.47]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:11:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) Date: Thu, 3 Apr 2008 15:10:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) Thread-Index: AciVlHB9aVD6xzkRTbizvmZsvboNJw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 03 Apr 2008 14:11:17.0311 (UTC) FILETIME=[9554A4F0:01C89594] X-Barracuda-Connect: UNKNOWN[193.39.225.234] X-Barracuda-Start-Time: 1207231878 X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164907097==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1164907097== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89594.9566D74F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89594.9566D74F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emile, > There is not doubt that the datamodel have to be extended in short term= .=20 > 'enumerated' is the right example. It is missing in the datamodel and i= t=20 > is a ground truth storage datatype. > > In the current approach, the adding of 'enumerated' as an abstract=20 > datatype in the datamodel will require the update of=20 > draft-ietf-ipfix-exporting-type because this draft defines a static=20 > registry in the section "3.1. informationElementDataType". >=20 maybe the data model will have to be extended, but this would be an infor= mation model extension (i.e. an update of RFC5102) and I don't think it b= elongs logically to a method description for exporting information model = information on the wire.=20 Of course changes in the information model are likely to affect this docu= ment too... > To avoid static pieces in the IPFIX datamodel in the future it is=20 > mandatory to define an IPFIX IE for each abstract data types defined in= =20 > the IPFIX datamodel: >=20 > octetArray =20 > unsigned8 =20 > unsigned16 =20 > unsigned32 =20 > unsigned64 =20 > signed8 =20 > signed16 =20 > signed32 =20 > signed64 =20 > float32 =20 > float64 =20 > boolean =20 > macAddress =20 > string =20 > dateTimeSeconds =20 > dateTimeMilliseconds > dateTimeMicroseconds > dateTimeNanoseconds > ipv4Address =20 > ipv6Address =20 >=20 > The WG has the opportunity to do that with draft-ietf-ipfix-exporting-t= ype. >=20 I understand your concern, but I think that this is out of scope for this= =20document. If the working group wants to add this flexibility I suggest= =20opening a separate thread on this to discuss how this issue should be = addressed. thanks, Elisa > Regards >=20 > Emile >=20 >> > The way the draft-ietf-ipfix-exporting-type defines types prevents >=20 >> > adding new one in the future without updating the draft. There are >=20 >> > already potential candidates: Enumerated, email, DNS, URL .... >=20 >> -----Message d'origine----- >=20 >> De : Brian Trammell [mailto:bht@cert.org] >=20 >> Envoy=E9 : vendredi 28 mars 2008 22:57 >=20 >> =C0 : STEPHAN Emile RD-CORE-LAN >=20 >> Cc : ipfix@ietf.org >=20 >> Objet : expanding type and semantics registries (was Re: missing note= s on >=20 >> exporting type...) >=20 >> >=20 >> Emile, >=20 >> >=20 >> Ah, yes. Thanks. I remember now. My short, short answer on this was >=20 >> "no, but..." >=20 >> >=20 >> Here's why: >=20 >> >=20 >> The data type and semantics registries are taken directly from RFC >=20 >> 5102. This document doesn't seek to expand the types or semantics, it= >=20 >> only seeks to create formal IANA registries for a list of types >=20 >> _already_ defined on the standards track. The reason behind creating >=20 >> those registries is to map the types themselves to numeric codes used= >=20 >> to represent them in the informationElementDataType and >=20 >> informationElementSemantics IEs. The reason behind declaring their >=20 >> modification to be subject to a Standards Action as per RFC 2434 is t= o >=20 >> ensure that >=20 >> >=20 >> Adding a new data type to IPFIX is not simply a matter of sticking a >=20 >> new name and number into the data type registry -- specific >=20 >> information on the definition (as in section 3.1 of RFC 5102) and >=20 >> encoding (as in section 6.1 of RFC 5101) of the data type must be >=20 >> provided to allow the Exporting Process to properly encode and the >=20 >> Collecting Process to properly decode and recognize data of that type= . >=20 >> Even if it's just a reference to an external standard (as 5101's >=20 >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), >=20 >> it's still absolutely necessary to have some document extending the >=20 >> set of types for IPFIX to ensure interoperability of those new types.= >=20 >> And that's out of scope for _this_ document, which, as chartered, onl= y >=20 >> provides a _mechanism_ for describing the types already supported. >=20 >> >=20 >> That said, you have a very good point. >=20 >> >=20 >> There are quite a few types that could be immediately useful; and yes= , >=20 >> additional network-identifiers such as URL, email, and FQDN are >=20 >> obvious first choices, which can only be implemented as Strings at th= e >=20 >> moment. Enumerations are another issue, and can already be partially >=20 >> implemented using the Reducing Redundancy mechanism. >=20 >> >=20 >> My suggestion, however, would be a new document, to be considered for= >=20 >> a future WG charter, to _explicitly_ extend the set of types supporte= d >=20 >> by IPFIX, and adding those types to the registry created in exporting= - >=20 >> type. >=20 >> >=20 >> Cheers, >=20 >> >=20 >> Brian >=20 >> >=20 >> >=20 >> >=20 >> On Mar 28, 2008, at 2:20 PM, wrote= : >=20 >> > Hi Brian, >=20 >> > >=20 >> > The way the draft-ietf-ipfix-exporting-type defines types prevents >=20 >> > adding new one in the future without updating the draft. There are >=20 >> > already potential candidates: Enumerated, email, DNS, URL .... >=20 >> > >=20 >> > Adding these types to the IPFIX datamodel increases the scope of >=20 >> > usage of IPFIX and interoperability. It permits the usage of >=20 >> > standard IE for exporting specific information. It permits the >=20 >> > collector to store this information in an efficient way. It >=20 >> > encourage enterprises to use standard IE instead of enterprises >=20 >> > specific ones. >=20 >> > >=20 >> > >=20 >> > Therefore the draft has to define them as IEs and the IANA section >=20 >> > have to request IANA to add them the IPFIX datamodel registry. >=20 >> > >=20 >> > >=20 >> > Regards >=20 >> > >=20 >> > Emile >=20 >> > >=20 >> > >=20 >> > > -----Message d'origine----- >=20 >> > >=20 >> > > De : Brian Trammell [mailto:bht@cert.org] >=20 >> > >=20 >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 >=20 >> > >=20 >> > > =C0 : STEPHAN Emile RD-CORE-LAN >=20 >> > >=20 >> > > Objet : missing notes on exporting type... >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Emile, >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > As I recall, we had a conversation in Philadelphia about some >=20 >> > specific >=20 >> > >=20 >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer fo= r >=20 >> > >=20 >> > > your question, and I was going to post a message to the list abou= t >=20 >> > >=20 >> > > that... but, I can't seem to find my note on the subject, and it'= s >=20 >> > >=20 >> > > been a rather eventful couple of weeks, and I have consequently >=20 >> > >=20 >> > > _completely_ forgotten it. >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > So. >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Would you happen to remember what we were talking about, so we co= uld >=20 >> > >=20 >> > > perhaps start over on the subject? >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Thanks, >=20 >> > >=20 >> > > >=20 >> > >=20 >> > > Brian *************************************************************************= *************************=20 E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are in= tended solely for the use=20 of the individual or entity to which they are addressed. Access to this e= -mail by anyone else is=20 unauthorised. If you are not the intended recipient, any disclosure, copy= ing, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-m= ail messages are not=20 necessarily secure. Hitachi does not accept responsibility for any change= s made to this message=20 after it was sent.=20 Hitachi checks outgoing e-mail messages for the presence of computer viru= ses.=20 *************************************************************************= ************************* ------_=_NextPart_001_01C89594.9566D74F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] expanding type and semantics registries (was Re: missi= ng notes on exporting type...)

Emile,

> There is not doubt that the datamodel have to be extended in short t= erm.
> 'enumerated' is the right example. It is missing in the datamodel an= d it
> is a ground truth storage datatype.
>
> In the current approach, the adding of 'enumerated' as an abstract > datatype in the datamodel will require the update of
> draft-ietf-ipfix-exporting-type because this draft defines a static<= BR> > registry in the section "3.1.  informationElementDataType&= quot;.
>

maybe the data model will have to be extended, but this would be an infor= mation model extension (i.e. an update of RFC5102) and I don't think it b= elongs logically to a method description for exporting information model = information on the wire.
Of course changes in the information model are likely to affect this docu= ment too...


> To avoid static pieces in the IPFIX datamodel in the future it is > mandatory to define an IPFIX IE for each abstract data types defined= =20in
> the IPFIX datamodel:
>
>       octetArray   &nbs= p;    
>       unsigned8    = ;     
>       unsigned16   &nbs= p;    
>       unsigned32   &nbs= p;    
>       unsigned64   &nbs= p;    
>       signed8    &= nbsp;      
>       signed16    =       
>       signed32    =       
>       signed64    =       
>       float32    &= nbsp;      
>       float64    &= nbsp;      
>       boolean    &= nbsp;      
>       macAddress   &nbs= p;    
>       string    &n= bsp;       
>       dateTimeSeconds   = ;
>       dateTimeMilliseconds
>       dateTimeMicroseconds
>       dateTimeNanoseconds
>       ipv4Address   &nb= sp;   
>       ipv6Address   &nb= sp;   
>
> The WG has the opportunity to do that with draft-ietf-ipfix-exportin= g-type.
>

I understand your concern, but I think that this is out of scope for this= =20document. If the working group wants to add this flexibility I suggest= =20opening a separate thread on this to discuss how this issue should be = addressed.

thanks,
Elisa

> Regards
>
> Emile
>
>>  > The way the draft-ietf-ipfix-exporting-type defines t= ypes prevents
>
>>  > adding new one in the future without updating the dra= ft. There are
>
>>  > already potential candidates: Enumerated, email, DNS,= =20URL ....
>
>>  -----Message d'origine-----
>
>>  De : Brian Trammell [mailt= o:bht@cert.org]
>
>>  Envoy=E9 : vendredi 28 mars 2008 22:57
>
>>  =C0 : STEPHAN Emile RD-CORE-LAN
>
>>  Cc : ipfix@ietf.org
>
>>  Objet : expanding type and semantics registries (was Re: m= issing notes on
>
>>  exporting type...)
>
>>
>
>>  Emile,
>
>>
>
>>  Ah, yes. Thanks. I remember now. My short, short answer on= =20this was
>
>>  "no, but..."
>
>>
>
>>  Here's why:
>
>>
>
>>  The data type and semantics registries are taken directly = from RFC
>
>>  5102. This document doesn't seek to expand the types or se= mantics, it
>
>>  only seeks to create formal IANA registries for a list of = types
>
>>  _already_ defined on the standards track. The reason behin= d creating
>
>>  those registries is to map the types themselves to numeric= =20codes used
>
>>  to represent them in the informationElementDataType and >
>>  informationElementSemantics IEs. The reason behind declari= ng their
>
>>  modification to be subject to a Standards Action as per RF= C 2434 is to
>
>>  ensure that
>
>>
>
>>  Adding a new data type to IPFIX is not simply a matter of = sticking a
>
>>  new name and number into the data type registry -- specifi= c
>
>>  information on the definition (as in section 3.1 of RFC 51= 02) and
>
>>  encoding (as in section 6.1 of RFC 5101) of the data type = must be
>
>>  provided to allow the Exporting Process to properly encode= =20and the
>
>>  Collecting Process to properly decode and recognize data o= f that type.
>
>>  Even if it's just a reference to an external standard (as = 5101's
>
>>  sections 6.1.3. and 6.1.4. do to IEEE 754 for floating poi= nt types),
>
>>  it's still absolutely necessary to have some document exte= nding the
>
>>  set of types for IPFIX to ensure interoperability of those= =20new types.
>
>>  And that's out of scope for _this_ document, which, as cha= rtered, only
>
>>  provides a _mechanism_ for describing the types already su= pported.
>
>>
>
>>  That said, you have a very good point.
>
>>
>
>>  There are quite a few types that could be immediately usef= ul; and yes,
>
>>  additional network-identifiers such as URL, email, and FQD= N are
>
>>  obvious first choices, which can only be implemented as St= rings at the
>
>>  moment. Enumerations are another issue, and can already be= =20partially
>
>>  implemented using the Reducing Redundancy mechanism.
>
>>
>
>>  My suggestion, however, would be a new document, to be con= sidered for
>
>>  a future WG charter, to _explicitly_ extend the set of typ= es supported
>
>>  by IPFIX, and adding those types to the registry created i= n exporting-
>
>>  type.
>
>>
>
>>  Cheers,
>
>>
>
>>  Brian
>
>>
>
>>
>
>>
>
>>  On Mar 28, 2008, at 2:20 PM, <emile.stephan@orange-ftgr= oup.com> wrote:
>
>>  > Hi Brian,
>
>>  >
>
>>  > The way the draft-ietf-ipfix-exporting-type defines t= ypes prevents
>
>>  > adding new one in the future without updating the dra= ft. There are
>
>>  > already potential candidates: Enumerated, email, DNS,= =20URL ....
>
>>  >
>
>>  > Adding these types to the IPFIX datamodel increases t= he scope of
>
>>  > usage of IPFIX and interoperability. It permits the u= sage of
>
>>  > standard IE for exporting specific information. It pe= rmits the
>
>>  > collector to store this information in an efficient w= ay. It
>
>>  > encourage enterprises to use standard IE instead of e= nterprises
>
>>  > specific ones.
>
>>  >
>
>>  >
>
>>  > Therefore the draft has to define them as IEs and the= =20IANA section
>
>>  > have to request IANA to add them the IPFIX datamodel = registry.
>
>>  >
>
>>  >
>
>>  > Regards
>
>>  >
>
>>  > Emile
>
>>  >
>
>>  >
>
>>  > > -----Message d'origine-----
>
>>  >
>
>>  > > De : Brian Trammell [mailto:bht@cert.org]
>
>>  >
>
>>  > > Envoy=E9 : vendredi 28 mars 2008 02:11
>
>>  >
>
>>  > > =C0 : STEPHAN Emile RD-CORE-LAN
>
>>  >
>
>>  > > Objet : missing notes on exporting type...
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Emile,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > As I recall, we had a conversation in Philadelph= ia about some
>
>>  > specific
>
>>  >
>
>>  > > aspect of draft-ietf-ipfix-exporting-type, and I= =20had an answer for
>
>>  >
>
>>  > > your question, and I was going to post a message= =20to the list about
>
>>  >
>
>>  > > that... but, I can't seem to find my note on the= =20subject, and it's
>
>>  >
>
>>  > > been a rather eventful couple of weeks, and I ha= ve consequently
>
>>  >
>
>>  > > _completely_ forgotten it.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > So.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Would you happen to remember what we were talkin= g about, so we could
>
>>  >
>
>>  > > perhaps start over on the subject?
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Thanks,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Brian

************= *************************************************************************= *************
E-mail=20 Confidentiality Notice and Disclaimer.

This e-mail and any files transmitted with it are confiden= tial and=20 are intended solely for the use of the individual or entity to which they= =20are=20 addressed. Access to this e-mail by anyone else is unauthorised. If you a= re not=20 the intended recipient, any disclosure, copying, distribution or any acti= on=20 taken or omitted to be taken in reliance on it, is prohibited.
E-mail= =20 messages are not necessarily secure.
Hitachi does not accept responsi= bility=20 for any changes made to this message after it was sent.
Hitachi checks= =20 outgoing e-mail messages for the presence of computer viruses.=20
*********************************************************************= *****************************=20

------_=_NextPart_001_01C89594.9566D74F-- --===============1164907097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1164907097==-- From ipfix-bounces@ietf.org Thu Apr 3 14:37:50 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C503A6B87; Thu, 3 Apr 2008 14:37:50 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008393A6893 for ; Thu, 3 Apr 2008 14:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rJFMhDc02P7 for ; Thu, 3 Apr 2008 14:37:47 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id 7585B3A686D for ; Thu, 3 Apr 2008 14:37:47 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m33Lbltw023057 for ; Thu, 3 Apr 2008 17:37:49 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m33LbZJv023025 for ; Thu, 3 Apr 2008 17:37:35 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m33LbZXs023018; Thu, 03 Apr 2008 17:37:35 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-17.remote.cert.org [10.25.4.17]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m33LbZvf013895; Thu, 3 Apr 2008 17:37:35 -0400 Message-Id: <8BF37A9A-BA7F-4D6B-9C47-517E16956CCC@cert.org> From: Brian Trammell To: "Boschi, Elisa" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 17:37:34 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org, emile.stephan@orange-ftgroup.com Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Elisa, Emile, all, Replies inline. On Apr 3, 2008, at 10:10 AM, Boschi, Elisa wrote: > Emile, > > > There is not doubt that the datamodel have to be extended in short = > term. > > 'enumerated' is the right example. It is missing in the datamodel = > and it > > is a ground truth storage datatype. > > > > In the current approach, the adding of 'enumerated' as an abstract > > datatype in the datamodel will require the update of > > draft-ietf-ipfix-exporting-type because this draft defines a static > > registry in the section "3.1. informationElementDataType". > > > Emile, it seems we're all talking past each other on representations = of enumerated types, because I don't quite get what you mean here. You seem to have a specific mechanism in mind for this. = Could you describe it in more detail? > maybe the data model will have to be extended, but this would be an = > information model extension (i.e. an update of RFC5102) and I don't = > think it belongs logically to a method description for exporting = > information model information on the wire. > Agreed. Not only that, but adding new types is, as previously noted, = outside the item of the working group charter pertaining to this = document. > > Of course changes in the information model are likely to affect this = > document too... > > Absolutely, via the IANA registry this document creates. Changes to = the information model that add data types to the protocol will also = add them to the registry, assigning them a number, which can then be = represented in informationElementDataType. > > To avoid static pieces in the IPFIX datamodel in the future it is > > mandatory to define an IPFIX IE for each abstract data types = > defined in > > the IPFIX datamodel: > > > > > > > The WG has the opportunity to do that with draft-ietf-ipfix- = > exporting-type. > > > > I understand your concern, but I think that this is out of scope for = > this document. If the working group wants to add this flexibility I = > suggest opening a separate thread on this to discuss how this issue = > should be addressed. > Agreed, it's certainly not in scope, and again, doing such a thing is = outside our charter for this document. I must admit I'm still not = _precisely_ clear what defining these information elements gets us = aside from the equivalent to another, different method for doing = enterprise-specific information elements (with the benefit of = typedness, which exporting-type achieves through an alternate = mechanism) -- you can at least have the raw data type (as with = exporting-type) but get no other display hints (name, units...) or = semantic processing information. Again, Also, I don't think it actually requires another document per = se; the IANA registry for information elements can be amended subject = only to Expert Review. Cheers, Brian > > thanks, > Elisa > > > Regards > > > > Emile > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> -----Message d'origine----- > > > >> De : Brian Trammell [mailto:bht@cert.org] > > > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > > > >> =C0 : STEPHAN Emile RD-CORE-LAN > > > >> Cc : ipfix@ietf.org > > > >> Objet : expanding type and semantics registries (was Re: missing = > notes on > > > >> exporting type...) > > > >> > > > >> Emile, > > > >> > > > >> Ah, yes. Thanks. I remember now. My short, short answer on this = > was > > > >> "no, but..." > > > >> > > > >> Here's why: > > > >> > > > >> The data type and semantics registries are taken directly from RFC > > > >> 5102. This document doesn't seek to expand the types or = > semantics, it > > > >> only seeks to create formal IANA registries for a list of types > > > >> _already_ defined on the standards track. The reason behind = > creating > > > >> those registries is to map the types themselves to numeric codes = > used > > > >> to represent them in the informationElementDataType and > > > >> informationElementSemantics IEs. The reason behind declaring their > > > >> modification to be subject to a Standards Action as per RFC 2434 = > is to > > > >> ensure that > > > >> > > > >> Adding a new data type to IPFIX is not simply a matter of = > sticking a > > > >> new name and number into the data type registry -- specific > > > >> information on the definition (as in section 3.1 of RFC 5102) and > > > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > > > >> provided to allow the Exporting Process to properly encode and the > > > >> Collecting Process to properly decode and recognize data of that = > type. > > > >> Even if it's just a reference to an external standard (as 5101's > > > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point = > types), > > > >> it's still absolutely necessary to have some document extending = > the > > > >> set of types for IPFIX to ensure interoperability of those new = > types. > > > >> And that's out of scope for _this_ document, which, as = > chartered, only > > > >> provides a _mechanism_ for describing the types already supported. > > > >> > > > >> That said, you have a very good point. > > > >> > > > >> There are quite a few types that could be immediately useful; = > and yes, > > > >> additional network-identifiers such as URL, email, and FQDN are > > > >> obvious first choices, which can only be implemented as Strings = > at the > > > >> moment. Enumerations are another issue, and can already be = > partially > > > >> implemented using the Reducing Redundancy mechanism. > > > >> > > > >> My suggestion, however, would be a new document, to be = > considered for > > > >> a future WG charter, to _explicitly_ extend the set of types = > supported > > > >> by IPFIX, and adding those types to the registry created in = > exporting- > > > >> type. > > > >> > > > >> Cheers, > > > >> > > > >> Brian > > > >> > > > >> > > > >> > > > >> On Mar 28, 2008, at 2:20 PM, = > wrote: > > > >> > Hi Brian, > > > >> > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> > > > > >> > Adding these types to the IPFIX datamodel increases the scope of > > > >> > usage of IPFIX and interoperability. It permits the usage of > > > >> > standard IE for exporting specific information. It permits the > > > >> > collector to store this information in an efficient way. It > > > >> > encourage enterprises to use standard IE instead of enterprises > > > >> > specific ones. > > > >> > > > > >> > > > > >> > Therefore the draft has to define them as IEs and the IANA = > section > > > >> > have to request IANA to add them the IPFIX datamodel registry. > > > >> > > > > >> > > > > >> > Regards > > > >> > > > > >> > Emile > > > >> > > > > >> > > > > >> > > -----Message d'origine----- > > > >> > > > > >> > > De : Brian Trammell [mailto:bht@cert.org] > > > >> > > > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > >> > > > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > > > >> > > > > >> > > Objet : missing notes on exporting type... > > > >> > > > > >> > > > > > >> > > > > >> > > Emile, > > > >> > > > > >> > > > > > >> > > > > >> > > As I recall, we had a conversation in Philadelphia about some > > > >> > specific > > > >> > > > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an = > answer for > > > >> > > > > >> > > your question, and I was going to post a message to the list = > about > > > >> > > > > >> > > that... but, I can't seem to find my note on the subject, = > and it's > > > >> > > > > >> > > been a rather eventful couple of weeks, and I have = > consequently > > > >> > > > > >> > > _completely_ forgotten it. > > > >> > > > > >> > > > > > >> > > > > >> > > So. > > > >> > > > > >> > > > > > >> > > > > >> > > Would you happen to remember what we were talking about, so = > we could > > > >> > > > > >> > > perhaps start over on the subject? > > > >> > > > > >> > > > > > >> > > > > >> > > Thanks, > > > >> > > > > >> > > > > > >> > > > > >> > > Brian > > > > *************************************************************************= ************************* > E-mail Confidentiality Notice and Disclaimer. > > This e-mail and any files transmitted with it are confidential and = > are intended solely for the use of the individual or entity to which = > they are addressed. Access to this e-mail by anyone else is = > unauthorised. If you are not the intended recipient, any disclosure, = > copying, distribution or any action taken or omitted to be taken in = > reliance on it, is prohibited. > E-mail messages are not necessarily secure. > Hitachi does not accept responsibility for any changes made to this = > message after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer = > viruses. > *************************************************************************= ************************* > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Apr 3 14:37:50 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C503A6B87; Thu, 3 Apr 2008 14:37:50 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008393A6893 for ; Thu, 3 Apr 2008 14:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rJFMhDc02P7 for ; Thu, 3 Apr 2008 14:37:47 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id 7585B3A686D for ; Thu, 3 Apr 2008 14:37:47 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m33Lbltw023057 for ; Thu, 3 Apr 2008 17:37:49 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m33LbZJv023025 for ; Thu, 3 Apr 2008 17:37:35 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m33LbZXs023018; Thu, 03 Apr 2008 17:37:35 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-17.remote.cert.org [10.25.4.17]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m33LbZvf013895; Thu, 3 Apr 2008 17:37:35 -0400 Message-Id: <8BF37A9A-BA7F-4D6B-9C47-517E16956CCC@cert.org> From: Brian Trammell To: "Boschi, Elisa" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 17:37:34 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org, emile.stephan@orange-ftgroup.com Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Elisa, Emile, all, Replies inline. On Apr 3, 2008, at 10:10 AM, Boschi, Elisa wrote: > Emile, > > > There is not doubt that the datamodel have to be extended in short = > term. > > 'enumerated' is the right example. It is missing in the datamodel = > and it > > is a ground truth storage datatype. > > > > In the current approach, the adding of 'enumerated' as an abstract > > datatype in the datamodel will require the update of > > draft-ietf-ipfix-exporting-type because this draft defines a static > > registry in the section "3.1. informationElementDataType". > > > Emile, it seems we're all talking past each other on representations = of enumerated types, because I don't quite get what you mean here. You seem to have a specific mechanism in mind for this. = Could you describe it in more detail? > maybe the data model will have to be extended, but this would be an = > information model extension (i.e. an update of RFC5102) and I don't = > think it belongs logically to a method description for exporting = > information model information on the wire. > Agreed. Not only that, but adding new types is, as previously noted, = outside the item of the working group charter pertaining to this = document. > > Of course changes in the information model are likely to affect this = > document too... > > Absolutely, via the IANA registry this document creates. Changes to = the information model that add data types to the protocol will also = add them to the registry, assigning them a number, which can then be = represented in informationElementDataType. > > To avoid static pieces in the IPFIX datamodel in the future it is > > mandatory to define an IPFIX IE for each abstract data types = > defined in > > the IPFIX datamodel: > > > > > > > The WG has the opportunity to do that with draft-ietf-ipfix- = > exporting-type. > > > > I understand your concern, but I think that this is out of scope for = > this document. If the working group wants to add this flexibility I = > suggest opening a separate thread on this to discuss how this issue = > should be addressed. > Agreed, it's certainly not in scope, and again, doing such a thing is = outside our charter for this document. I must admit I'm still not = _precisely_ clear what defining these information elements gets us = aside from the equivalent to another, different method for doing = enterprise-specific information elements (with the benefit of = typedness, which exporting-type achieves through an alternate = mechanism) -- you can at least have the raw data type (as with = exporting-type) but get no other display hints (name, units...) or = semantic processing information. Again, Also, I don't think it actually requires another document per = se; the IANA registry for information elements can be amended subject = only to Expert Review. Cheers, Brian > > thanks, > Elisa > > > Regards > > > > Emile > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> -----Message d'origine----- > > > >> De : Brian Trammell [mailto:bht@cert.org] > > > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > > > >> =C0 : STEPHAN Emile RD-CORE-LAN > > > >> Cc : ipfix@ietf.org > > > >> Objet : expanding type and semantics registries (was Re: missing = > notes on > > > >> exporting type...) > > > >> > > > >> Emile, > > > >> > > > >> Ah, yes. Thanks. I remember now. My short, short answer on this = > was > > > >> "no, but..." > > > >> > > > >> Here's why: > > > >> > > > >> The data type and semantics registries are taken directly from RFC > > > >> 5102. This document doesn't seek to expand the types or = > semantics, it > > > >> only seeks to create formal IANA registries for a list of types > > > >> _already_ defined on the standards track. The reason behind = > creating > > > >> those registries is to map the types themselves to numeric codes = > used > > > >> to represent them in the informationElementDataType and > > > >> informationElementSemantics IEs. The reason behind declaring their > > > >> modification to be subject to a Standards Action as per RFC 2434 = > is to > > > >> ensure that > > > >> > > > >> Adding a new data type to IPFIX is not simply a matter of = > sticking a > > > >> new name and number into the data type registry -- specific > > > >> information on the definition (as in section 3.1 of RFC 5102) and > > > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > > > >> provided to allow the Exporting Process to properly encode and the > > > >> Collecting Process to properly decode and recognize data of that = > type. > > > >> Even if it's just a reference to an external standard (as 5101's > > > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point = > types), > > > >> it's still absolutely necessary to have some document extending = > the > > > >> set of types for IPFIX to ensure interoperability of those new = > types. > > > >> And that's out of scope for _this_ document, which, as = > chartered, only > > > >> provides a _mechanism_ for describing the types already supported. > > > >> > > > >> That said, you have a very good point. > > > >> > > > >> There are quite a few types that could be immediately useful; = > and yes, > > > >> additional network-identifiers such as URL, email, and FQDN are > > > >> obvious first choices, which can only be implemented as Strings = > at the > > > >> moment. Enumerations are another issue, and can already be = > partially > > > >> implemented using the Reducing Redundancy mechanism. > > > >> > > > >> My suggestion, however, would be a new document, to be = > considered for > > > >> a future WG charter, to _explicitly_ extend the set of types = > supported > > > >> by IPFIX, and adding those types to the registry created in = > exporting- > > > >> type. > > > >> > > > >> Cheers, > > > >> > > > >> Brian > > > >> > > > >> > > > >> > > > >> On Mar 28, 2008, at 2:20 PM, = > wrote: > > > >> > Hi Brian, > > > >> > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> > > > > >> > Adding these types to the IPFIX datamodel increases the scope of > > > >> > usage of IPFIX and interoperability. It permits the usage of > > > >> > standard IE for exporting specific information. It permits the > > > >> > collector to store this information in an efficient way. It > > > >> > encourage enterprises to use standard IE instead of enterprises > > > >> > specific ones. > > > >> > > > > >> > > > > >> > Therefore the draft has to define them as IEs and the IANA = > section > > > >> > have to request IANA to add them the IPFIX datamodel registry. > > > >> > > > > >> > > > > >> > Regards > > > >> > > > > >> > Emile > > > >> > > > > >> > > > > >> > > -----Message d'origine----- > > > >> > > > > >> > > De : Brian Trammell [mailto:bht@cert.org] > > > >> > > > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > >> > > > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > > > >> > > > > >> > > Objet : missing notes on exporting type... > > > >> > > > > >> > > > > > >> > > > > >> > > Emile, > > > >> > > > > >> > > > > > >> > > > > >> > > As I recall, we had a conversation in Philadelphia about some > > > >> > specific > > > >> > > > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an = > answer for > > > >> > > > > >> > > your question, and I was going to post a message to the list = > about > > > >> > > > > >> > > that... but, I can't seem to find my note on the subject, = > and it's > > > >> > > > > >> > > been a rather eventful couple of weeks, and I have = > consequently > > > >> > > > > >> > > _completely_ forgotten it. > > > >> > > > > >> > > > > > >> > > > > >> > > So. > > > >> > > > > >> > > > > > >> > > > > >> > > Would you happen to remember what we were talking about, so = > we could > > > >> > > > > >> > > perhaps start over on the subject? > > > >> > > > > >> > > > > > >> > > > > >> > > Thanks, > > > >> > > > > >> > > > > > >> > > > > >> > > Brian > > > > *************************************************************************= ************************* > E-mail Confidentiality Notice and Disclaimer. > > This e-mail and any files transmitted with it are confidential and = > are intended solely for the use of the individual or entity to which = > they are addressed. Access to this e-mail by anyone else is = > unauthorised. If you are not the intended recipient, any disclosure, = > copying, distribution or any action taken or omitted to be taken in = > reliance on it, is prohibited. > E-mail messages are not necessarily secure. > Hitachi does not accept responsibility for any changes made to this = > message after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer = > viruses. > *************************************************************************= ************************* > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From jyxnanettebarattahel@nanettebaratta.com Sun Apr 6 23:21:11 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3833A6BA2; Sun, 6 Apr 2008 23:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwGAlW2s4FMA; Sun, 6 Apr 2008 23:21:10 -0700 (PDT) Received: from [116.71.243.214] (unknown [116.71.243.214]) by core3.amsl.com (Postfix) with ESMTP id 30C023A6BAE; Sun, 6 Apr 2008 23:21:09 -0700 (PDT) Received: from [116.71.243.214] by eforward4.name-services.com; Mon, 7 Apr 2008 11:21:21 +0500 Date: Mon, 7 Apr 2008 11:21:21 +0500 From: "Sheryl Hoyt" X-Mailer: The Bat! (v2.00.5) Personal Reply-To: jyxnanettebarattahel@nanettebaratta.com X-Priority: 3 (Normal) Message-ID: <276381876.00023547464370@nanettebaratta.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------86E6E6E6E67291C" ------------86E6E6E6E67291C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our main purpose is to guarantee PC and Mac lawful software and computer solutions of low cost for anyone. Whether you're a corporate customer, a small enterprise proprietor, or shopping for your home personal computer, we believe we'll assist you. CHECK WHAT WE HAVE TO OFFER! http://frankiesubletteps539.googlepages.com ------------86E6E6E6E67291C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our main purpose is to guarantee PC and Mac lawful software and computer solutions of low cost for anyone.
Whether you're a corporate customer, a small enterprise proprietor,
or shopping for your home personal computer, we believe we'll assist you.
CHECK WHAT WE HAVE TO OFFER!
http://frankiesubletteps539.googlepages.com
------------86E6E6E6E67291C-- From negoneshotfirearmskap@oneshotfirearms.com Fri Apr 11 00:08:25 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E3828C11D; Fri, 11 Apr 2008 00:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.131 X-Spam-Level: *** X-Spam-Status: No, score=3.131 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9wYYfIattk5; Fri, 11 Apr 2008 00:08:20 -0700 (PDT) Received: from host115-214-static.46-85-b.business.telecomitalia.it (host115-214-static.46-85-b.business.telecomitalia.it [85.46.214.115]) by core3.amsl.com (Postfix) with ESMTP id 484653A6E34; Fri, 11 Apr 2008 00:08:02 -0700 (PDT) Received: from [85.46.214.115] by oneshotfirearms.com; Fri, 11 Apr 2008 08:08:42 +0100 Date: Fri, 11 Apr 2008 08:08:42 +0100 From: "Rosalind Bowles" X-Mailer: The Bat! (v2.00) Educational Reply-To: negoneshotfirearmskap@oneshotfirearms.com X-Priority: 3 (Normal) Message-ID: <138193221.06221903751090@oneshotfirearms.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------86E67215AF21C705" ------------86E67215AF21C705 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our goal is to assure low price PC and Mac lawful soft and computer solutions any could afford. Whether you are a corporate purchaser, a small enterprise possessor, or go shopping for your own home PC, we suppose we can assist you. CHECK WHAT WE HAVE TO OFFER! http://earnestinermsf689.googlepages.com ------------86E67215AF21C705 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our goal is to assure low price PC and Mac lawful soft and computer solutions any could afford.
Whether you are a corporate purchaser, a small enterprise possessor,
or go shopping for your own home PC, we suppose we can assist you.
CHECK WHAT WE HAVE TO OFFER!
http://earnestinermsf689.googlepages.com
------------86E67215AF21C705-- From ipfix-bounces@ietf.org Mon Apr 14 07:03:20 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE0C28C2EC; Mon, 14 Apr 2008 07:03:20 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC5C28C2EC for ; Mon, 14 Apr 2008 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbrFB23LUlNt for ; Mon, 14 Apr 2008 07:03:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 55C2C28C29D for ; Mon, 14 Apr 2008 07:03:16 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 16:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 16:03:38 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) thread-index: AciVlHB9aVD6xzkRTbizvmZsvboNJwImfjuA References: From: To: X-OriginalArrivalTime: 14 Apr 2008 14:03:42.0286 (UTC) FILETIME=[58A896E0:01C89E38] Cc: Elisa.Boschi@Hitachi-eu.com, ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0637436622==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0637436622== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89E38.57F11C21" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89E38.57F11C21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan =20 Sorry for de delay. =20 Elisa said: > maybe the data model will have to be extended, but this would be an = information model extension (i.e. an update of RFC5102) and I don't = think it belongs=20 > logically to a method description for exporting information model = information on the wire. > Of course changes in the information model are likely to affect this = document too... =20 To make it short: We all agree that, without change, the RFC resulting of = draft-ietf-ipfix-exporting-type will have to be updated each time a new = datatype is defined. =20 My understanding of the current practice inside IETF is that numbering = must be registered by IANA when the datamodel allows the definition of = new datatypes in the future. So, if my view is correct, the numbering of = the datatypes of the IPFIX datamodel (RFC5102) made in = draft-ietf-ipfix-exporting-type has to be registered by IANA.=20 =20 =20 Regards Emile =20 =20 ________________________________ De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com]=20 Envoy=E9 : jeudi 3 avril 2008 16:10 =C0 : STEPHAN Emile RD-CORE-LAN Cc : ipfix@ietf.org; bht@cert.org Objet : Re: [IPFIX] expanding type and semantics registries (was Re: = missing notes on exporting type...) =20 Emile, > There is not doubt that the datamodel have to be extended in short = term. > 'enumerated' is the right example. It is missing in the datamodel and = it > is a ground truth storage datatype. > > In the current approach, the adding of 'enumerated' as an abstract > datatype in the datamodel will require the update of > draft-ietf-ipfix-exporting-type because this draft defines a static > registry in the section "3.1. informationElementDataType". > maybe the data model will have to be extended, but this would be an = information model extension (i.e. an update of RFC5102) and I don't = think it belongs logically to a method description for exporting = information model information on the wire. Of course changes in the information model are likely to affect this = document too... > To avoid static pieces in the IPFIX datamodel in the future it is > mandatory to define an IPFIX IE for each abstract data types defined = in > the IPFIX datamodel: > > octetArray =20 > unsigned8 =20 > unsigned16 =20 > unsigned32 =20 > unsigned64 =20 > signed8 =20 > signed16 =20 > signed32 =20 > signed64 =20 > float32 =20 > float64 =20 > boolean =20 > macAddress =20 > string =20 > dateTimeSeconds =20 > dateTimeMilliseconds > dateTimeMicroseconds > dateTimeNanoseconds > ipv4Address =20 > ipv6Address =20 > > The WG has the opportunity to do that with = draft-ietf-ipfix-exporting-type. > I understand your concern, but I think that this is out of scope for = this document. If the working group wants to add this flexibility I = suggest opening a separate thread on this to discuss how this issue = should be addressed. thanks, Elisa > Regards > > Emile > >> > The way the draft-ietf-ipfix-exporting-type defines types prevents > >> > adding new one in the future without updating the draft. There are > >> > already potential candidates: Enumerated, email, DNS, URL .... > >> -----Message d'origine----- > >> De : Brian Trammell [mailto:bht@cert.org] > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > >> =C0 : STEPHAN Emile RD-CORE-LAN > >> Cc : ipfix@ietf.org > >> Objet : expanding type and semantics registries (was Re: missing = notes on > >> exporting type...) > >> > >> Emile, > >> > >> Ah, yes. Thanks. I remember now. My short, short answer on this was > >> "no, but..." > >> > >> Here's why: > >> > >> The data type and semantics registries are taken directly from RFC > >> 5102. This document doesn't seek to expand the types or semantics, = it > >> only seeks to create formal IANA registries for a list of types > >> _already_ defined on the standards track. The reason behind creating > >> those registries is to map the types themselves to numeric codes = used > >> to represent them in the informationElementDataType and > >> informationElementSemantics IEs. The reason behind declaring their > >> modification to be subject to a Standards Action as per RFC 2434 is = to > >> ensure that > >> > >> Adding a new data type to IPFIX is not simply a matter of sticking a > >> new name and number into the data type registry -- specific > >> information on the definition (as in section 3.1 of RFC 5102) and > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > >> provided to allow the Exporting Process to properly encode and the > >> Collecting Process to properly decode and recognize data of that = type. > >> Even if it's just a reference to an external standard (as 5101's > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), > >> it's still absolutely necessary to have some document extending the > >> set of types for IPFIX to ensure interoperability of those new = types. > >> And that's out of scope for _this_ document, which, as chartered, = only > >> provides a _mechanism_ for describing the types already supported. > >> > >> That said, you have a very good point. > >> > >> There are quite a few types that could be immediately useful; and = yes, > >> additional network-identifiers such as URL, email, and FQDN are > >> obvious first choices, which can only be implemented as Strings at = the > >> moment. Enumerations are another issue, and can already be partially > >> implemented using the Reducing Redundancy mechanism. > >> > >> My suggestion, however, would be a new document, to be considered = for > >> a future WG charter, to _explicitly_ extend the set of types = supported > >> by IPFIX, and adding those types to the registry created in = exporting- > >> type. > >> > >> Cheers, > >> > >> Brian > >> > >> > >> > >> On Mar 28, 2008, at 2:20 PM, = wrote: > >> > Hi Brian, > >> > > >> > The way the draft-ietf-ipfix-exporting-type defines types prevents > >> > adding new one in the future without updating the draft. There are > >> > already potential candidates: Enumerated, email, DNS, URL .... > >> > > >> > Adding these types to the IPFIX datamodel increases the scope of > >> > usage of IPFIX and interoperability. It permits the usage of > >> > standard IE for exporting specific information. It permits the > >> > collector to store this information in an efficient way. It > >> > encourage enterprises to use standard IE instead of enterprises > >> > specific ones. > >> > > >> > > >> > Therefore the draft has to define them as IEs and the IANA section > >> > have to request IANA to add them the IPFIX datamodel registry. > >> > > >> > > >> > Regards > >> > > >> > Emile > >> > > >> > > >> > > -----Message d'origine----- > >> > > >> > > De : Brian Trammell [mailto:bht@cert.org] > >> > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > >> > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > >> > > >> > > Objet : missing notes on exporting type... > >> > > >> > > > >> > > >> > > Emile, > >> > > >> > > > >> > > >> > > As I recall, we had a conversation in Philadelphia about some > >> > specific > >> > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer = for > >> > > >> > > your question, and I was going to post a message to the list = about > >> > > >> > > that... but, I can't seem to find my note on the subject, and = it's > >> > > >> > > been a rather eventful couple of weeks, and I have consequently > >> > > >> > > _completely_ forgotten it. > >> > > >> > > > >> > > >> > > So. > >> > > >> > > > >> > > >> > > Would you happen to remember what we were talking about, so we = could > >> > > >> > > perhaps start over on the subject? > >> > > >> > > > >> > > >> > > Thanks, > >> > > >> > > > >> > > >> > > Brian *************************************************************************= ************************* E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are = intended solely for the use of the individual or entity to which they = are addressed. Access to this e-mail by anyone else is unauthorised. If = you are not the intended recipient, any disclosure, copying, = distribution or any action taken or omitted to be taken in reliance on = it, is prohibited.=20 E-mail messages are not necessarily secure.=20 Hitachi does not accept responsibility for any changes made to this = message after it was sent. Hitachi checks outgoing e-mail messages for the presence of computer = viruses.=20 *************************************************************************= *************************=20 ------_=_NextPart_001_01C89E38.57F11C21 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] expanding type and semantics registries (was Re: = missing notes on exporting type...)

Hi = Dan

 

Sorry for de = delay.

 

Elisa = said:


> maybe the data model will have to be = extended, but this would be an information model extension (i.e. an update of = RFC5102) and I don't think it belongs

> logically to a method description for exporting information model information on = the wire.
> Of course changes in the information model are likely to affect = this document too...
=A0=A0=A0=A0=A0

To make it = short:

We all agree that, = without change, the RFC resulting of draft-ietf-ipfix-exporting-type will have to be updated each time a new datatype is defined.

 

My understanding of = the current practice inside IETF is that numbering must be registered by = IANA when the datamodel allows the definition of new = datatypes in the future. So, if my view is = correct, the numbering of the datatypes of the IPFIX = datamodel (RFC5102) made in draft-ietf-ipfix-exporting-type has to be registered by IANA.

 

 

Regards

Emile

 

 

De : = Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com]
Envoy=E9 : jeudi 3 = avril 2008 16:10
=C0 : = STEPHAN Emile RD-CORE-LAN
Cc : ipfix@ietf.org; bht@cert.org
Objet : Re: [IPFIX] = expanding type and semantics registries (was Re: missing notes on exporting = type...)

 

Emile,

> There is not doubt that the datamodel have to be extended in short = term.
> 'enumerated' is the right example. It is missing in the datamodel = and it
> is a ground truth storage datatype.
>
> In the current approach, the adding of 'enumerated' as an = abstract
> datatype in the datamodel will require the update of
> draft-ietf-ipfix-exporting-type because this draft defines a = static
> registry in the section "3.1.  = informationElementDataType".
>

maybe the data model will have to be extended, but this would be an = information model extension (i.e. an update of RFC5102) and I don't think it belongs logically to a method description for exporting information model = information on the wire.
Of course changes in the information model are likely to affect this = document too...


> To avoid static pieces in the IPFIX datamodel in the future it = is
> mandatory to define an IPFIX IE for each abstract data types = defined in
> the IPFIX datamodel:
>
>       = octetArray        
>       unsigned8         
>       unsigned16        
>       unsigned32        
>       unsigned64        
>       signed8           =
>       signed16          
>       signed32          
>       signed64          
>       float32           =
>       float64           =
>       boolean           =
>       macAddress        
>       string           &= nbsp;
>       = dateTimeSeconds   
>       dateTimeMilliseconds
>       dateTimeMicroseconds
>       dateTimeNanoseconds
>       ipv4Address       
>       = ipv6Address       
>
> The WG has the opportunity to do that with draft-ietf-ipfix-exporting-type.
>

I understand your concern, but I think that this is out of scope for = this document. If the working group wants to add this flexibility I suggest = opening a separate thread on this to discuss how this issue should be = addressed.

thanks,
Elisa

> Regards
>
> Emile
>
>>  > The way the draft-ietf-ipfix-exporting-type defines = types prevents
>
>>  > adding new one in the future without updating the = draft. There are
>
>>  > already potential candidates: Enumerated, email, = DNS, URL ....
>
>>  -----Message d'origine-----
>
>>  De : Brian Trammell [mailto:bht@cert.org]
>
>>  Envoy=E9 : vendredi 28 mars 2008 22:57
>
>>  =C0 : STEPHAN Emile = RD-CORE-LAN
>
>>  Cc : ipfix@ietf.org
>
>>  Objet : expanding type and semantics registries (was Re: = missing notes on
>
>>  exporting type...)
>
>>
>
>>  Emile,
>
>>
>
>>  Ah, yes. Thanks. I remember now. My short, short answer = on this was
>
>>  "no, but..."
>
>>
>
>>  Here's why:
>
>>
>
>>  The data type and semantics registries are taken directly = from RFC
>
>>  5102. This document doesn't seek to expand the types or semantics, it
>
>>  only seeks to create formal IANA registries for a list of = types
>
>>  _already_ defined on the standards track. The reason = behind creating
>
>>  those registries is to map the types themselves to = numeric codes used
>
>>  to represent them in the informationElementDataType = and
>
>>  informationElementSemantics IEs. The reason behind = declaring their
>
>>  modification to be subject to a Standards Action as per = RFC 2434 is to
>
>>  ensure that
>
>>
>
>>  Adding a new data type to IPFIX is not simply a matter of sticking a
>
>>  new name and number into the data type registry -- = specific
>
>>  information on the definition (as in section 3.1 of RFC = 5102) and
>
>>  encoding (as in section 6.1 of RFC 5101) of the data type = must be
>
>>  provided to allow the Exporting Process to properly = encode and the
>
>>  Collecting Process to properly decode and recognize data = of that type.
>
>>  Even if it's just a reference to an external standard (as = 5101's
>
>>  sections 6.1.3. and 6.1.4. do to IEEE 754 for floating = point types),
>
>>  it's still absolutely necessary to have some document = extending the
>
>>  set of types for IPFIX to ensure interoperability of = those new types.
>
>>  And that's out of scope for _this_ document, which, as chartered, only
>
>>  provides a _mechanism_ for describing the types already supported.
>
>>
>
>>  That said, you have a very good point.
>
>>
>
>>  There are quite a few types that could be immediately = useful; and yes,
>
>>  additional network-identifiers such as URL, email, and = FQDN are
>
>>  obvious first choices, which can only be implemented as = Strings at the
>
>>  moment. Enumerations are another issue, and can already = be partially
>
>>  implemented using the Reducing Redundancy mechanism.
>
>>
>
>>  My suggestion, however, would be a new document, to be considered for
>
>>  a future WG charter, to _explicitly_ extend the set of = types supported
>
>>  by IPFIX, and adding those types to the registry created = in exporting-
>
>>  type.
>
>>
>
>>  Cheers,
>
>>
>
>>  Brian
>
>>
>
>>
>
>>
>
>>  On Mar 28, 2008, at 2:20 PM, <emile.stephan@orange-ftgroup.com> wrote:
>
>>  > Hi Brian,
>
>>  >
>
>>  > The way the draft-ietf-ipfix-exporting-type defines = types prevents
>
>>  > adding new one in the future without updating the = draft. There are
>
>>  > already potential candidates: Enumerated, email, = DNS, URL ....
>
>>  >
>
>>  > Adding these types to the IPFIX datamodel increases = the scope of
>
>>  > usage of IPFIX and interoperability. It permits the = usage of
>
>>  > standard IE for exporting specific information. It = permits the
>
>>  > collector to store this information in an efficient = way. It
>
>>  > encourage enterprises to use standard IE instead of enterprises
>
>>  > specific ones.
>
>>  >
>
>>  >
>
>>  > Therefore the draft has to define them as IEs and = the IANA section
>
>>  > have to request IANA to add them the IPFIX datamodel registry.
>
>>  >
>
>>  >
>
>>  > Regards
>
>>  >
>
>>  > Emile
>
>>  >
>
>>  >
>
>>  > > -----Message d'origine-----
>
>>  >
>
>>  > > De : Brian Trammell [mailto:bht@cert.org]
>
>>  >
>
>>  > > Envoy=E9 : vendredi 28 mars 2008 02:11
>
>>  >
>
>>  > > =C0 : STEPHAN Emile RD-CORE-LAN
>
>>  >
>
>>  > > Objet : missing notes on exporting type...
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Emile,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > As I recall, we had a conversation in = Philadelphia about some
>
>>  > specific
>
>>  >
>
>>  > > aspect of draft-ietf-ipfix-exporting-type, and = I had an answer for
>
>>  >
>
>>  > > your question, and I was going to post a = message to the list about
>
>>  >
>
>>  > > that... but, I can't seem to find my note on = the subject, and it's
>
>>  >
>
>>  > > been a rather eventful couple of weeks, and I = have consequently
>
>>  >
>
>>  > > _completely_ forgotten it.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > So.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Would you happen to remember what we were = talking about, so we could
>
>>  >
>
>>  > > perhaps start over on the subject?
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Thanks,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Brian


****************************= ********************************************************************** E-mail Confidentiality Notice and Disclaimer. =

This e-mail and any files transmitted with = it are confidential and are intended solely for the use of the individual or = entity to which they are addressed. Access to this e-mail by anyone else is = unauthorised. If you are not the intended recipient, any disclosure, copying, = distribution or any action taken or omitted to be taken in reliance on it, is = prohibited.
E-mail messages are not necessarily secure.
Hitachi does not accept responsibility for any changes made to this = message after it was sent.
Hitachi checks outgoing e-mail messages for the presence of computer = viruses.
*************************************************************************= *************************

------_=_NextPart_001_01C89E38.57F11C21-- --===============0637436622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0637436622==-- From ipfix-bounces@ietf.org Mon Apr 14 07:03:20 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE0C28C2EC; Mon, 14 Apr 2008 07:03:20 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC5C28C2EC for ; Mon, 14 Apr 2008 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbrFB23LUlNt for ; Mon, 14 Apr 2008 07:03:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 55C2C28C29D for ; Mon, 14 Apr 2008 07:03:16 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 16:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 16:03:38 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) thread-index: AciVlHB9aVD6xzkRTbizvmZsvboNJwImfjuA References: From: To: X-OriginalArrivalTime: 14 Apr 2008 14:03:42.0286 (UTC) FILETIME=[58A896E0:01C89E38] Cc: Elisa.Boschi@Hitachi-eu.com, ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0637436622==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0637436622== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89E38.57F11C21" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89E38.57F11C21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan =20 Sorry for de delay. =20 Elisa said: > maybe the data model will have to be extended, but this would be an = information model extension (i.e. an update of RFC5102) and I don't = think it belongs=20 > logically to a method description for exporting information model = information on the wire. > Of course changes in the information model are likely to affect this = document too... =20 To make it short: We all agree that, without change, the RFC resulting of = draft-ietf-ipfix-exporting-type will have to be updated each time a new = datatype is defined. =20 My understanding of the current practice inside IETF is that numbering = must be registered by IANA when the datamodel allows the definition of = new datatypes in the future. So, if my view is correct, the numbering of = the datatypes of the IPFIX datamodel (RFC5102) made in = draft-ietf-ipfix-exporting-type has to be registered by IANA.=20 =20 =20 Regards Emile =20 =20 ________________________________ De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com]=20 Envoy=E9 : jeudi 3 avril 2008 16:10 =C0 : STEPHAN Emile RD-CORE-LAN Cc : ipfix@ietf.org; bht@cert.org Objet : Re: [IPFIX] expanding type and semantics registries (was Re: = missing notes on exporting type...) =20 Emile, > There is not doubt that the datamodel have to be extended in short = term. > 'enumerated' is the right example. It is missing in the datamodel and = it > is a ground truth storage datatype. > > In the current approach, the adding of 'enumerated' as an abstract > datatype in the datamodel will require the update of > draft-ietf-ipfix-exporting-type because this draft defines a static > registry in the section "3.1. informationElementDataType". > maybe the data model will have to be extended, but this would be an = information model extension (i.e. an update of RFC5102) and I don't = think it belongs logically to a method description for exporting = information model information on the wire. Of course changes in the information model are likely to affect this = document too... > To avoid static pieces in the IPFIX datamodel in the future it is > mandatory to define an IPFIX IE for each abstract data types defined = in > the IPFIX datamodel: > > octetArray =20 > unsigned8 =20 > unsigned16 =20 > unsigned32 =20 > unsigned64 =20 > signed8 =20 > signed16 =20 > signed32 =20 > signed64 =20 > float32 =20 > float64 =20 > boolean =20 > macAddress =20 > string =20 > dateTimeSeconds =20 > dateTimeMilliseconds > dateTimeMicroseconds > dateTimeNanoseconds > ipv4Address =20 > ipv6Address =20 > > The WG has the opportunity to do that with = draft-ietf-ipfix-exporting-type. > I understand your concern, but I think that this is out of scope for = this document. If the working group wants to add this flexibility I = suggest opening a separate thread on this to discuss how this issue = should be addressed. thanks, Elisa > Regards > > Emile > >> > The way the draft-ietf-ipfix-exporting-type defines types prevents > >> > adding new one in the future without updating the draft. There are > >> > already potential candidates: Enumerated, email, DNS, URL .... > >> -----Message d'origine----- > >> De : Brian Trammell [mailto:bht@cert.org] > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > >> =C0 : STEPHAN Emile RD-CORE-LAN > >> Cc : ipfix@ietf.org > >> Objet : expanding type and semantics registries (was Re: missing = notes on > >> exporting type...) > >> > >> Emile, > >> > >> Ah, yes. Thanks. I remember now. My short, short answer on this was > >> "no, but..." > >> > >> Here's why: > >> > >> The data type and semantics registries are taken directly from RFC > >> 5102. This document doesn't seek to expand the types or semantics, = it > >> only seeks to create formal IANA registries for a list of types > >> _already_ defined on the standards track. The reason behind creating > >> those registries is to map the types themselves to numeric codes = used > >> to represent them in the informationElementDataType and > >> informationElementSemantics IEs. The reason behind declaring their > >> modification to be subject to a Standards Action as per RFC 2434 is = to > >> ensure that > >> > >> Adding a new data type to IPFIX is not simply a matter of sticking a > >> new name and number into the data type registry -- specific > >> information on the definition (as in section 3.1 of RFC 5102) and > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > >> provided to allow the Exporting Process to properly encode and the > >> Collecting Process to properly decode and recognize data of that = type. > >> Even if it's just a reference to an external standard (as 5101's > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types), > >> it's still absolutely necessary to have some document extending the > >> set of types for IPFIX to ensure interoperability of those new = types. > >> And that's out of scope for _this_ document, which, as chartered, = only > >> provides a _mechanism_ for describing the types already supported. > >> > >> That said, you have a very good point. > >> > >> There are quite a few types that could be immediately useful; and = yes, > >> additional network-identifiers such as URL, email, and FQDN are > >> obvious first choices, which can only be implemented as Strings at = the > >> moment. Enumerations are another issue, and can already be partially > >> implemented using the Reducing Redundancy mechanism. > >> > >> My suggestion, however, would be a new document, to be considered = for > >> a future WG charter, to _explicitly_ extend the set of types = supported > >> by IPFIX, and adding those types to the registry created in = exporting- > >> type. > >> > >> Cheers, > >> > >> Brian > >> > >> > >> > >> On Mar 28, 2008, at 2:20 PM, = wrote: > >> > Hi Brian, > >> > > >> > The way the draft-ietf-ipfix-exporting-type defines types prevents > >> > adding new one in the future without updating the draft. There are > >> > already potential candidates: Enumerated, email, DNS, URL .... > >> > > >> > Adding these types to the IPFIX datamodel increases the scope of > >> > usage of IPFIX and interoperability. It permits the usage of > >> > standard IE for exporting specific information. It permits the > >> > collector to store this information in an efficient way. It > >> > encourage enterprises to use standard IE instead of enterprises > >> > specific ones. > >> > > >> > > >> > Therefore the draft has to define them as IEs and the IANA section > >> > have to request IANA to add them the IPFIX datamodel registry. > >> > > >> > > >> > Regards > >> > > >> > Emile > >> > > >> > > >> > > -----Message d'origine----- > >> > > >> > > De : Brian Trammell [mailto:bht@cert.org] > >> > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > >> > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > >> > > >> > > Objet : missing notes on exporting type... > >> > > >> > > > >> > > >> > > Emile, > >> > > >> > > > >> > > >> > > As I recall, we had a conversation in Philadelphia about some > >> > specific > >> > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an answer = for > >> > > >> > > your question, and I was going to post a message to the list = about > >> > > >> > > that... but, I can't seem to find my note on the subject, and = it's > >> > > >> > > been a rather eventful couple of weeks, and I have consequently > >> > > >> > > _completely_ forgotten it. > >> > > >> > > > >> > > >> > > So. > >> > > >> > > > >> > > >> > > Would you happen to remember what we were talking about, so we = could > >> > > >> > > perhaps start over on the subject? > >> > > >> > > > >> > > >> > > Thanks, > >> > > >> > > > >> > > >> > > Brian *************************************************************************= ************************* E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are = intended solely for the use of the individual or entity to which they = are addressed. Access to this e-mail by anyone else is unauthorised. If = you are not the intended recipient, any disclosure, copying, = distribution or any action taken or omitted to be taken in reliance on = it, is prohibited.=20 E-mail messages are not necessarily secure.=20 Hitachi does not accept responsibility for any changes made to this = message after it was sent. Hitachi checks outgoing e-mail messages for the presence of computer = viruses.=20 *************************************************************************= *************************=20 ------_=_NextPart_001_01C89E38.57F11C21 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] expanding type and semantics registries (was Re: = missing notes on exporting type...)

Hi = Dan

 

Sorry for de = delay.

 

Elisa = said:


> maybe the data model will have to be = extended, but this would be an information model extension (i.e. an update of = RFC5102) and I don't think it belongs

> logically to a method description for exporting information model information on = the wire.
> Of course changes in the information model are likely to affect = this document too...
=A0=A0=A0=A0=A0

To make it = short:

We all agree that, = without change, the RFC resulting of draft-ietf-ipfix-exporting-type will have to be updated each time a new datatype is defined.

 

My understanding of = the current practice inside IETF is that numbering must be registered by = IANA when the datamodel allows the definition of new = datatypes in the future. So, if my view is = correct, the numbering of the datatypes of the IPFIX = datamodel (RFC5102) made in draft-ietf-ipfix-exporting-type has to be registered by IANA.

 

 

Regards

Emile

 

 

De : = Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com]
Envoy=E9 : jeudi 3 = avril 2008 16:10
=C0 : = STEPHAN Emile RD-CORE-LAN
Cc : ipfix@ietf.org; bht@cert.org
Objet : Re: [IPFIX] = expanding type and semantics registries (was Re: missing notes on exporting = type...)

 

Emile,

> There is not doubt that the datamodel have to be extended in short = term.
> 'enumerated' is the right example. It is missing in the datamodel = and it
> is a ground truth storage datatype.
>
> In the current approach, the adding of 'enumerated' as an = abstract
> datatype in the datamodel will require the update of
> draft-ietf-ipfix-exporting-type because this draft defines a = static
> registry in the section "3.1.  = informationElementDataType".
>

maybe the data model will have to be extended, but this would be an = information model extension (i.e. an update of RFC5102) and I don't think it belongs logically to a method description for exporting information model = information on the wire.
Of course changes in the information model are likely to affect this = document too...


> To avoid static pieces in the IPFIX datamodel in the future it = is
> mandatory to define an IPFIX IE for each abstract data types = defined in
> the IPFIX datamodel:
>
>       = octetArray        
>       unsigned8         
>       unsigned16        
>       unsigned32        
>       unsigned64        
>       signed8           =
>       signed16          
>       signed32          
>       signed64          
>       float32           =
>       float64           =
>       boolean           =
>       macAddress        
>       string           &= nbsp;
>       = dateTimeSeconds   
>       dateTimeMilliseconds
>       dateTimeMicroseconds
>       dateTimeNanoseconds
>       ipv4Address       
>       = ipv6Address       
>
> The WG has the opportunity to do that with draft-ietf-ipfix-exporting-type.
>

I understand your concern, but I think that this is out of scope for = this document. If the working group wants to add this flexibility I suggest = opening a separate thread on this to discuss how this issue should be = addressed.

thanks,
Elisa

> Regards
>
> Emile
>
>>  > The way the draft-ietf-ipfix-exporting-type defines = types prevents
>
>>  > adding new one in the future without updating the = draft. There are
>
>>  > already potential candidates: Enumerated, email, = DNS, URL ....
>
>>  -----Message d'origine-----
>
>>  De : Brian Trammell [mailto:bht@cert.org]
>
>>  Envoy=E9 : vendredi 28 mars 2008 22:57
>
>>  =C0 : STEPHAN Emile = RD-CORE-LAN
>
>>  Cc : ipfix@ietf.org
>
>>  Objet : expanding type and semantics registries (was Re: = missing notes on
>
>>  exporting type...)
>
>>
>
>>  Emile,
>
>>
>
>>  Ah, yes. Thanks. I remember now. My short, short answer = on this was
>
>>  "no, but..."
>
>>
>
>>  Here's why:
>
>>
>
>>  The data type and semantics registries are taken directly = from RFC
>
>>  5102. This document doesn't seek to expand the types or semantics, it
>
>>  only seeks to create formal IANA registries for a list of = types
>
>>  _already_ defined on the standards track. The reason = behind creating
>
>>  those registries is to map the types themselves to = numeric codes used
>
>>  to represent them in the informationElementDataType = and
>
>>  informationElementSemantics IEs. The reason behind = declaring their
>
>>  modification to be subject to a Standards Action as per = RFC 2434 is to
>
>>  ensure that
>
>>
>
>>  Adding a new data type to IPFIX is not simply a matter of sticking a
>
>>  new name and number into the data type registry -- = specific
>
>>  information on the definition (as in section 3.1 of RFC = 5102) and
>
>>  encoding (as in section 6.1 of RFC 5101) of the data type = must be
>
>>  provided to allow the Exporting Process to properly = encode and the
>
>>  Collecting Process to properly decode and recognize data = of that type.
>
>>  Even if it's just a reference to an external standard (as = 5101's
>
>>  sections 6.1.3. and 6.1.4. do to IEEE 754 for floating = point types),
>
>>  it's still absolutely necessary to have some document = extending the
>
>>  set of types for IPFIX to ensure interoperability of = those new types.
>
>>  And that's out of scope for _this_ document, which, as chartered, only
>
>>  provides a _mechanism_ for describing the types already supported.
>
>>
>
>>  That said, you have a very good point.
>
>>
>
>>  There are quite a few types that could be immediately = useful; and yes,
>
>>  additional network-identifiers such as URL, email, and = FQDN are
>
>>  obvious first choices, which can only be implemented as = Strings at the
>
>>  moment. Enumerations are another issue, and can already = be partially
>
>>  implemented using the Reducing Redundancy mechanism.
>
>>
>
>>  My suggestion, however, would be a new document, to be considered for
>
>>  a future WG charter, to _explicitly_ extend the set of = types supported
>
>>  by IPFIX, and adding those types to the registry created = in exporting-
>
>>  type.
>
>>
>
>>  Cheers,
>
>>
>
>>  Brian
>
>>
>
>>
>
>>
>
>>  On Mar 28, 2008, at 2:20 PM, <emile.stephan@orange-ftgroup.com> wrote:
>
>>  > Hi Brian,
>
>>  >
>
>>  > The way the draft-ietf-ipfix-exporting-type defines = types prevents
>
>>  > adding new one in the future without updating the = draft. There are
>
>>  > already potential candidates: Enumerated, email, = DNS, URL ....
>
>>  >
>
>>  > Adding these types to the IPFIX datamodel increases = the scope of
>
>>  > usage of IPFIX and interoperability. It permits the = usage of
>
>>  > standard IE for exporting specific information. It = permits the
>
>>  > collector to store this information in an efficient = way. It
>
>>  > encourage enterprises to use standard IE instead of enterprises
>
>>  > specific ones.
>
>>  >
>
>>  >
>
>>  > Therefore the draft has to define them as IEs and = the IANA section
>
>>  > have to request IANA to add them the IPFIX datamodel registry.
>
>>  >
>
>>  >
>
>>  > Regards
>
>>  >
>
>>  > Emile
>
>>  >
>
>>  >
>
>>  > > -----Message d'origine-----
>
>>  >
>
>>  > > De : Brian Trammell [mailto:bht@cert.org]
>
>>  >
>
>>  > > Envoy=E9 : vendredi 28 mars 2008 02:11
>
>>  >
>
>>  > > =C0 : STEPHAN Emile RD-CORE-LAN
>
>>  >
>
>>  > > Objet : missing notes on exporting type...
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Emile,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > As I recall, we had a conversation in = Philadelphia about some
>
>>  > specific
>
>>  >
>
>>  > > aspect of draft-ietf-ipfix-exporting-type, and = I had an answer for
>
>>  >
>
>>  > > your question, and I was going to post a = message to the list about
>
>>  >
>
>>  > > that... but, I can't seem to find my note on = the subject, and it's
>
>>  >
>
>>  > > been a rather eventful couple of weeks, and I = have consequently
>
>>  >
>
>>  > > _completely_ forgotten it.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > So.
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Would you happen to remember what we were = talking about, so we could
>
>>  >
>
>>  > > perhaps start over on the subject?
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Thanks,
>
>>  >
>
>>  > >
>
>>  >
>
>>  > > Brian


****************************= ********************************************************************** E-mail Confidentiality Notice and Disclaimer. =

This e-mail and any files transmitted with = it are confidential and are intended solely for the use of the individual or = entity to which they are addressed. Access to this e-mail by anyone else is = unauthorised. If you are not the intended recipient, any disclosure, copying, = distribution or any action taken or omitted to be taken in reliance on it, is = prohibited.
E-mail messages are not necessarily secure.
Hitachi does not accept responsibility for any changes made to this = message after it was sent.
Hitachi checks outgoing e-mail messages for the presence of computer = viruses.
*************************************************************************= *************************

------_=_NextPart_001_01C89E38.57F11C21-- --===============0637436622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0637436622==-- From ipfix-bounces@ietf.org Mon Apr 14 11:44:48 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EC33A6C9F; Mon, 14 Apr 2008 11:44:48 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79A83A6CB0 for ; Mon, 14 Apr 2008 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdC0mc2r1ONl for ; Mon, 14 Apr 2008 11:44:46 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id 3EBF63A6C9F for ; Mon, 14 Apr 2008 11:44:46 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m3EIjBRw020294 for ; Mon, 14 Apr 2008 14:45:15 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m3EIhffC020072 for ; Mon, 14 Apr 2008 14:43:41 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m3EIhfUc020068; Mon, 14 Apr 2008 14:43:41 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m3EIhfNv029952; Mon, 14 Apr 2008 14:43:41 -0400 Message-Id: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> From: Brian Trammell To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 14:43:40 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: Elisa.Boschi@Hitachi-eu.com, ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Emile and all, Replies inline. Regards, Brian On Apr 14, 2008, at 10:03 AM, wrote: > Hi Dan > > Sorry for de delay. > > Elisa said: > > > maybe the data model will have to be extended, but this would be = > an information model extension (i.e. an update of RFC5102) and I = > don't think it belongs > > logically to a method description for exporting information model = > information on the wire. > > Of course changes in the information model are likely to affect = > this document too... > > To make it short: > We all agree that, without change, the RFC resulting of draft-ietf- = > ipfix-exporting-type will have to be updated each time a new = > datatype is defined. No. This is not the case. The exporting-type RFC will not need to be = updated whFrom ipfix-bounces@ietf.org Mon Apr 14 11:44:48 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EC33A6C9F; Mon, 14 Apr 2008 11:44:48 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79A83A6CB0 for ; Mon, 14 Apr 2008 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdC0mc2r1ONl for ; Mon, 14 Apr 2008 11:44:46 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id 3EBF63A6C9F for ; Mon, 14 Apr 2008 11:44:46 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m3EIjBRw020294 for ; Mon, 14 Apr 2008 14:45:15 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m3EIhffC020072 for ; Mon, 14 Apr 2008 14:43:41 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m3EIhfUc020068; Mon, 14 Apr 2008 14:43:41 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m3EIhfNv029952; Mon, 14 Apr 2008 14:43:41 -0400 Message-Id: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> From: Brian Trammell To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 14:43:40 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: Elisa.Boschi@Hitachi-eu.com, ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Emile and all, Replies inline. Regards, Brian On Apr 14, 2008, at 10:03 AM, wrote: > Hi Dan > > Sorry for de delay. > > Elisa said: > > > maybe the data model will have to be extended, but this would be = > an information model extension (i.e. an update of RFC5102) and I = > don't think it belongs > > logically to a method description for exporting information model = > information on the wire. > > Of course changes in the information model are likely to affect = > this document too... > > To make it short: > We all agree that, without change, the RFC resulting of draft-ietf- = > ipfix-exporting-type will have to be updated each time a new = > datatype is defined. No. This is not the case. The exporting-type RFC will not need to be = updated whenen data types are added to the protocol. The exporting-type = draft says nothing about the data types available in IPFIX (that's the = job of RFCs 5101/5102). It simply creates an IANA registry and = populates it with the data types and semantics already defined within = the protocol. It creates this registry solely so that datatypes can be = mapped to numbers for the representation of type information inline. > My understanding of the current practice inside IETF is that = > numbering must be registered by IANA when the datamodel allows the = > definition of new datatypes in the future. So, if my view is = > correct, the numbering of the datatypes of the IPFIX datamodel = > (RFC5102) made in draft-ietf-ipfix-exporting-type has to be = > registered by IANA. Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of = exporting-type. Note that, as the data type and semantics registries are defined to be = updated by an RFC 2434 Standards Action only, an additional RFC _will_ = be necessary to add data types to the IPFIX protocol, but this RFC = need not update the exporting-type RFC; nothing about new data types = will change how metainformation about those types will be represented = inline. We selected Standards Action from RFC 2434 as the update policy for = the created registries after discussion at one of the working group = meetings (Vancouver, I think, but I may be remembering incorrectly), = because there are potentially serious interoperability concerns raised = by adding new datatypes to the protocol, specifically in how = information of the new types is to be encoded on the wire. > Regards > Emile > > > De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] > Envoy=E9 : jeudi 3 avril 2008 16:10 > =C0 : STEPHAN Emile RD-CORE-LAN > Cc : ipfix@ietf.org; bht@cert.org > Objet : Re: [IPFIX] expanding type and semantics registries (was Re: = > missing notes on exporting type...) > > Emile, > > > There is not doubt that the datamodel have to be extended in short = > term. > > 'enumerated' is the right example. It is missing in the datamodel = > and it > > is a ground truth storage datatype. > > > > In the current approach, the adding of 'enumerated' as an abstract > > datatype in the datamodel will require the update of > > draft-ietf-ipfix-exporting-type because this draft defines a static > > registry in the section "3.1. informationElementDataType". > > > > maybe the data model will have to be extended, but this would be an = > information model extension (i.e. an update of RFC5102) and I don't = > think it belongs logically to a method description for exporting = > information model information on the wire. > Of course changes in the information model are likely to affect this = > document too... > > > > To avoid static pieces in the IPFIX datamodel in the future it is > > mandatory to define an IPFIX IE for each abstract data types = > defined in > > the IPFIX datamodel: > > > > octetArray > > unsigned8 > > unsigned16 > > unsigned32 > > unsigned64 > > signed8 > > signed16 > > signed32 > > signed64 > > float32 > > float64 > > boolean > > macAddress > > string > > dateTimeSeconds > > dateTimeMilliseconds > > dateTimeMicroseconds > > dateTimeNanoseconds > > ipv4Address > > ipv6Address > > > > The WG has the opportunity to do that with draft-ietf-ipfix- = > exporting-type. > > > > I understand your concern, but I think that this is out of scope for = > this document. If the working group wants to add this flexibility I = > suggest opening a separate thread on this to discuss how this issue = > should be addressed. > > thanks, > Elisa > > > Regards > > > > Emile > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> -----Mess data types are added to the protocol. The exporting-type = draft says nothing about the data types available in IPFIX (that's the = job of RFCs 5101/5102). It simply creates an IANA registry and = populates it with the data types and semantics already defined within = the protocol. It creates this registry solely so that datatypes can be = mapped to numbers for the representation of type information inline. > My understanding of the current practice inside IETF is that = > numbering must be registered by IANA when the datamodel allows the = > definition of new datatypes in the future. So, if my view is = > correct, the numbering of the datatypes of the IPFIX datamodel = > (RFC5102) made in draft-ietf-ipfix-exporting-type has to be = > registered by IANA. Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of = exporting-type. Note that, as the data type and semantics registries are defined to be = updated by an RFC 2434 Standards Action only, an additional RFC _will_ = be necessary to add data types to the IPFIX protocol, but this RFC = need not update the exporting-type RFC; nothing about new data types = will change how metainformation about those types will be represented = inline. We selected Standards Action from RFC 2434 as the update policy for = the created registries after discussion at one of the working group = meetings (Vancouver, I think, but I may be remembering incorrectly), = because there are potentially serious interoperability concerns raised = by adding new datatypes to the protocol, specifically in how = information of the new types is to be encoded on the wire. > Regards > Emile > > > De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] > Envoy=E9 : jeudi 3 avril 2008 16:10 > =C0 : STEPHAN Emile RD-CORE-LAN > Cc : ipfix@ietf.org; bht@cert.org > Objet : Re: [IPFIX] expanding type and semantics registries (was Re: = > missing notes on exporting type...) > > Emile, > > > There is not doubt that the datamodel have to be extended in short = > term. > > 'enumerated' is the right example. It is missing in the datamodel = > and it > > is a ground truth storage datatype. > > > > In the current approach, the adding of 'enumerated' as an abstract > > datatype in the datamodel will require the update of > > draft-ietf-ipfix-exporting-type because this draft defines a static > > registry in the section "3.1. informationElementDataType". > > > > maybe the data model will have to be extended, but this would be an = > information model extension (i.e. an update of RFC5102) and I don't = > think it belongs logically to a method description for exporting = > information model information on the wire. > Of course changes in the information model are likely to affect this = > document too... > > > > To avoid static pieces in the IPFIX datamodel in the future it is > > mandatory to define an IPFIX IE for each abstract data types = > defined in > > the IPFIX datamodel: > > > > octetArray > > unsigned8 > > unsigned16 > > unsigned32 > > unsigned64 > > signed8 > > signed16 > > signed32 > > signed64 > > float32 > > float64 > > boolean > > macAddress > > string > > dateTimeSeconds > > dateTimeMilliseconds > > dateTimeMicroseconds > > dateTimeNanoseconds > > ipv4Address > > ipv6Address > > > > The WG has the opportunity to do that with draft-ietf-ipfix- = > exporting-type. > > > > I understand your concern, but I think that this is out of scope for = > this document. If the working group wants to add this flexibility I = > suggest opening a separate thread on this to discuss how this issue = > should be addressed. > > thanks, > Elisa > > > Regards > > > > Emile > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> -----Messagage d'origine----- > > > >> De : Brian Trammell [mailto:bht@cert.org] > > > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > > > >> =C0 : STEPHAN Emile RD-CORE-LAN > > > >> Cc : ipfix@ietf.org > > > >> Objet : expanding type and semantics registries (was Re: missing = > notes on > > > >> exporting type...) > > > >> > > > >> Emile, > > > >> > > > >> Ah, yes. Thanks. I remember now. My short, short answer on this = > was > > > >> "no, but..." > > > >> > > > >> Here's why: > > > >> > > > >> The data type and semantics registries are taken directly from RFC > > > >> 5102. This document doesn't seek to expand the types or = > semantics, it > > > >> only seeks to create formal IANA registries for a list of types > > > >> _already_ defined on the standards track. The reason behind = > creating > > > >> those registries is to map the types themselves to numeric codes = > used > > > >> to represent them in the informationElementDataType and > > > >> informationElementSemantics IEs. The reason behind declaring their > > > >> modification to be subject to a Standards Action as per RFC 2434 = > is to > > > >> ensure that > > > >> > > > >> Adding a new data type to IPFIX is not simply a matter of = > sticking a > > > >> new name and number into the data type registry -- specific > > > >> information on the definition (as in section 3.1 of RFC 5102) and > > > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > > > >> provided to allow the Exporting Process to properly encode and the > > > >> Collecting Process to properly decode and recognize data of that = > type. > > > >> Even if it's just a reference to an external standard (as 5101's > > > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point = > types), > > > >> it's still absolutely necessary to have some document extending = > the > > > >> set of types for IPFIX to ensure interoperability of those new = > types. > > > >> And that's out of scope for _this_ document, which, as = > chartered, only > > > >> provides a _mechanism_ for describing the types already supported. > > > >> > > > >> That said, you have a very good point. > > > >> > > > >> There are quite a few types that could be immediately useful; = > and yes, > > > >> additional network-identifiers such as URL, email, and FQDN are > > > >> obvious first choices, which can only be implemented as Strings = > at the > > > >> moment. Enumerations are another issue, and can already be = > partially > > > >> implemented using the Reducing Redundancy mechanism. > > > >> > > > >> My suggestion, however, would be a new document, to be = > considered for > > > >> a future WG charter, to _explicitly_ extend the set of types = > supported > > > >> by IPFIX, and adding those types to the registry created in = > exporting- > > > >> type. > > > >> > > > >> Cheers, > > > >> > > > >> Brian > > > >> > > > >> > > > >> > > > >> On Mar 28, 2008, at 2:20 PM, = > wrote: > > > >> > Hi Brian, > > > >> > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> > > > > >> > Adding these types to the IPFIX datamodel increases the scope of > > > >> > usage of IPFIX and interoperability. It permits the usage of > > > >> > standard IE for exporting specific information. It permits the > > > >> > collector to store this information in an efficient way. It > > > >> > encourage enterprises to use standard IE instead of enterprises > > > >> > specific ones. > > > >> > > > > >> > > > > >> > Therefore the draft has to define them as IEs and the IANA = > section > > > >> > have to request IANA to add them the IPFIX datamodel registry. > > > >> > > > > >> > > > > >> > Regards > > > >> > > > > >> > Emile > > > >> > > > > >> > > > > >> > > -----Message d'origine----- > > > >> > > > > >> > > De : Brian Trae d'origine----- > > > >> De : Brian Trammell [mailto:bht@cert.org] > > > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > > > >> =C0 : STEPHAN Emile RD-CORE-LAN > > > >> Cc : ipfix@ietf.org > > > >> Objet : expanding type and semantics registries (was Re: missing = > notes on > > > >> exporting type...) > > > >> > > > >> Emile, > > > >> > > > >> Ah, yes. Thanks. I remember now. My short, short answer on this = > was > > > >> "no, but..." > > > >> > > > >> Here's why: > > > >> > > > >> The data type and semantics registries are taken directly from RFC > > > >> 5102. This document doesn't seek to expand the types or = > semantics, it > > > >> only seeks to create formal IANA registries for a list of types > > > >> _already_ defined on the standards track. The reason behind = > creating > > > >> those registries is to map the types themselves to numeric codes = > used > > > >> to represent them in the informationElementDataType and > > > >> informationElementSemantics IEs. The reason behind declaring their > > > >> modification to be subject to a Standards Action as per RFC 2434 = > is to > > > >> ensure that > > > >> > > > >> Adding a new data type to IPFIX is not simply a matter of = > sticking a > > > >> new name and number into the data type registry -- specific > > > >> information on the definition (as in section 3.1 of RFC 5102) and > > > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > > > >> provided to allow the Exporting Process to properly encode and the > > > >> Collecting Process to properly decode and recognize data of that = > type. > > > >> Even if it's just a reference to an external standard (as 5101's > > > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point = > types), > > > >> it's still absolutely necessary to have some document extending = > the > > > >> set of types for IPFIX to ensure interoperability of those new = > types. > > > >> And that's out of scope for _this_ document, which, as = > chartered, only > > > >> provides a _mechanism_ for describing the types already supported. > > > >> > > > >> That said, you have a very good point. > > > >> > > > >> There are quite a few types that could be immediately useful; = > and yes, > > > >> additional network-identifiers such as URL, email, and FQDN are > > > >> obvious first choices, which can only be implemented as Strings = > at the > > > >> moment. Enumerations are another issue, and can already be = > partially > > > >> implemented using the Reducing Redundancy mechanism. > > > >> > > > >> My suggestion, however, would be a new document, to be = > considered for > > > >> a future WG charter, to _explicitly_ extend the set of types = > supported > > > >> by IPFIX, and adding those types to the registry created in = > exporting- > > > >> type. > > > >> > > > >> Cheers, > > > >> > > > >> Brian > > > >> > > > >> > > > >> > > > >> On Mar 28, 2008, at 2:20 PM, = > wrote: > > > >> > Hi Brian, > > > >> > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types = > prevents > > > >> > adding new one in the future without updating the draft. There = > are > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > >> > > > > >> > Adding these types to the IPFIX datamodel increases the scope of > > > >> > usage of IPFIX and interoperability. It permits the usage of > > > >> > standard IE for exporting specific information. It permits the > > > >> > collector to store this information in an efficient way. It > > > >> > encourage enterprises to use standard IE instead of enterprises > > > >> > specific ones. > > > >> > > > > >> > > > > >> > Therefore the draft has to define them as IEs and the IANA = > section > > > >> > have to request IANA to add them the IPFIX datamodel registry. > > > >> > > > > >> > > > > >> > Regards > > > >> > > > > >> > Emile > > > >> > > > > >> > > > > >> > > -----Message d'origine----- > > > >> > > > > >> > > De : Brian Trammmmell [mailto:bht@cert.org] > > > >> > > > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > >> > > > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > > > >> > > > > >> > > Objet : missing notes on exporting type... > > > >> > > > > >> > > > > > >> > > > > >> > > Emile, > > > >> > > > > >> > > > > > >> > > > > >> > > As I recall, we had a conversation in Philadelphia about some > > > >> > specific > > > >> > > > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an = > answer for > > > >> > > > > >> > > your question, and I was going to post a message to the list = > about > > > >> > > > > >> > > that... but, I can't seem to find my note on the subject, = > and it's > > > >> > > > > >> > > been a rather eventful couple of weeks, and I have = > consequently > > > >> > > > > >> > > _completely_ forgotten it. > > > >> > > > > >> > > > > > >> > > > > >> > > So. > > > >> > > > > >> > > > > > >> > > > > >> > > Would you happen to remember what we were talking about, so = > we could > > > >> > > > > >> > > perhaps start over on the subject? > > > >> > > > > >> > > > > > >> > > > > >> > > Thanks, > > > >> > > > > >> > > > > > >> > > > > >> > > Brian > > > > *************************************************************************= ************************* > E-mail Confidentiality Notice and Disclaimer. > > This e-mail and any files transmitted with it are confidential and = > are intended solely for the use of the individual or entity to which = > they are addressed. Access to this e-mail by anyone else is = > unauthorised. If you are not the intended recipient, any disclosure, = > copying, distribution or any action taken or omitted to be taken in = > reliance on it, is prohibited. > E-mail messages are not necessarily secure. > Hitachi does not accept responsibility for any changes made to this = > message after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer = > viruses. > *************************************************************************= ************************* > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ell [mailto:bht@cert.org] > > > >> > > > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > >> > > > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > > > >> > > > > >> > > Objet : missing notes on exporting type... > > > >> > > > > >> > > > > > >> > > > > >> > > Emile, > > > >> > > > > >> > > > > > >> > > > > >> > > As I recall, we had a conversation in Philadelphia about some > > > >> > specific > > > >> > > > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an = > answer for > > > >> > > > > >> > > your question, and I was going to post a message to the list = > about > > > >> > > > > >> > > that... but, I can't seem to find my note on the subject, = > and it's > > > >> > > > > >> > > been a rather eventful couple of weeks, and I have = > consequently > > > >> > > > > >> > > _completely_ forgotten it. > > > >> > > > > >> > > > > > >> > > > > >> > > So. > > > >> > > > > >> > > > > > >> > > > > >> > > Would you happen to remember what we were talking about, so = > we could > > > >> > > > > >> > > perhaps start over on the subject? > > > >> > > > > >> > > > > > >> > > > > >> > > Thanks, > > > >> > > > > >> > > > > > >> > > > > >> > > Brian > > > > *************************************************************************= ************************* > E-mail Confidentiality Notice and Disclaimer. > > This e-mail and any files transmitted with it are confidential and = > are intended solely for the use of the individual or entity to which = > they are addressed. Access to this e-mail by anyone else is = > unauthorised. If you are not the intended recipient, any disclosure, = > copying, distribution or any action taken or omitted to be taken in = > reliance on it, is prohibited. > E-mail messages are not necessarily secure. > Hitachi does not accept responsibility for any changes made to this = > message after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer = > viruses. > *************************************************************************= ************************* > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Apr 16 02:00:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518B128C2B3; Wed, 16 Apr 2008 02:00:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BE62E28C157; Wed, 16 Apr 2008 02:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080416090001.BE62E28C157@core3.amsl.com> Date: Wed, 16 Apr 2008 02:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-testing-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart 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 IP Flow Information eXport (IPFIX) Testing Author(s) : C. Schmoll, et al. Filename : draft-ietf-ipfix-testing-05.txt Pages : 38 Date : 2008-04-16 This document presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-testing-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-testing-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-16014642.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Wed Apr 16 02:00:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518B128C2B3; Wed, 16 Apr 2008 02:00:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BE62E28C157; Wed, 16 Apr 2008 02:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080416090001.BE62E28C157@core3.amsl.com> Date: Wed, 16 Apr 2008 02:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-testing-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart 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 IP Flow Information eXport (IPFIX) Testing Author(s) : C. Schmoll, et al. Filename : draft-ietf-ipfix-testing-05.txt Pages : 38 Date : 2008-04-16 This document presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-testing-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-testing-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-16014642.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Wed Apr 16 07:42:16 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CAA3A681B; Wed, 16 Apr 2008 07:42:16 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176233A681B for ; Wed, 16 Apr 2008 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQYsNrNXwx4d for ; Wed, 16 Apr 2008 07:42:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 004CD3A63CB for ; Wed, 16 Apr 2008 07:42:09 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 16:42:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 16:42:35 +0200 Message-ID: In-Reply-To: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) thread-index: AcieX7AU5XrjM8vLTIGxQOu4ovDVmwBYj5fQ References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> From: To: X-OriginalArrivalTime: 16 Apr 2008 14:42:36.0627 (UTC) FILETIME=[1CDC4230:01C89FD0] Cc: Elisa.Boschi@Hitachi-eu.com, ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Brain, Thanks for the explanation. This framework limit's is reached when an enter= prise has to export the type of an IE which abstract data type is not defin= ed in the datamodel of the RFC5102. So the registry of the section 3 must n= ot be limited to the exiting abstract data types. It must include any exist= ing database datatypes to reach, at least, the initial goal of storing effi= ciently any proprietary IEs. = Otherwise, for sure, enterprises will 'complete' the table of section 3.1 w= ith their own abstract datatypes and tags. Then collectors will have to get= these values (using their cristal ball) and to hardcode these values in a = multidimensional table, then, later, the IPFIX WG will have to specify some= solution to export proprietary abstract data types... So, with real respect to the work done and to its need, this draft does not= encourage the usage of standard IEs and the migration towards standard IEs= . = It should. Abstract data type IEs are really required in option templates t= o describe abstract contexts not relFrom ipfix-bounces@ietf.org Wed Apr 16 07:42:16 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CAA3A681B; Wed, 16 Apr 2008 07:42:16 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176233A681B for ; Wed, 16 Apr 2008 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQYsNrNXwx4d for ; Wed, 16 Apr 2008 07:42:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 004CD3A63CB for ; Wed, 16 Apr 2008 07:42:09 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 16:42:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 16:42:35 +0200 Message-ID: In-Reply-To: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) thread-index: AcieX7AU5XrjM8vLTIGxQOu4ovDVmwBYj5fQ References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> From: To: X-OriginalArrivalTime: 16 Apr 2008 14:42:36.0627 (UTC) FILETIME=[1CDC4230:01C89FD0] Cc: Elisa.Boschi@Hitachi-eu.com, ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Brain, Thanks for the explanation. This framework limit's is reached when an enter= prise has to export the type of an IE which abstract data type is not defin= ed in the datamodel of the RFC5102. So the registry of the section 3 must n= ot be limited to the exiting abstract data types. It must include any exist= ing database datatypes to reach, at least, the initial goal of storing effi= ciently any proprietary IEs. = Otherwise, for sure, enterprises will 'complete' the table of section 3.1 w= ith their own abstract datatypes and tags. Then collectors will have to get= these values (using their cristal ball) and to hardcode these values in a = multidimensional table, then, later, the IPFIX WG will have to specify some= solution to export proprietary abstract data types... So, with real respect to the work done and to its need, this draft does not= encourage the usage of standard IEs and the migration towards standard IEs= . = It should. Abstract data type IEs are really required in option templates t= o describe abstract contexts not rated per essence to a flow nor to the d= irection of a flow. This is an urgently needed to limit reasonably the numb= er of proprietary IEs. Regards Emile > -----Message d'origine----- > De=A0: Brian Trammell [mailto:bht@cert.org] > Envoy=E9=A0: lundi 14 avril 2008 20:44 > =C0=A0: STEPHAN Emile RD-CORE-LAN > Cc=A0: dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi-eu.com > Objet=A0: Re: [IPFIX] expanding type and semantics registries (was Re: > missing notes on exporting type...) > = > Emile and all, > = > Replies inline. > = > Regards, > = > Brian > = > On Apr 14, 2008, at 10:03 AM, > > wrote: > > Hi Dan > > > > Sorry for de delay. > > > > Elisa said: > > > > > maybe the data model will have to be extended, but this would be > > an information model extension (i.e. an update of RFC5102) and I > > don't think it belongs > > > logically to a method description for exporting information model > > information on the wire. > > > Of course changes in the information model are likely to affect > > this document too... > > > > To make it short: > > We all agree that, without change, the RFC resulting of draft-ietf- > > ipfix-exporting-type will have to be updated each time a new > > datatype is defined. > = > No. This is not the case. The exporting-type RFC will not need to be > updated when data types are added to the protocol. The exporting-type > draft says nothing about the data types available in IPFIX (that's the > job of RFCs 5101/5102). It simply creates an IANA registry and > populates it with the data types and semantics already defined within > the protocol. It creates this registry solely so that datatypes can be > mapped to numbers for the representation of type information inline. > = > > My understanding of the current practice inside IETF is that > > numbering must be registered by IANA when the datamodel allows the > > definition of new datatypes in the future. So, if my view is > > correct, the numbering of the datatypes of the IPFIX datamodel > > (RFC5102) made in draft-ietf-ipfix-exporting-type has to be > > registered by IANA. > = > Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of > exporting-type. > = > Note that, as the data type and semantics registries are defined to be > updated by an RFC 2434 Standards Action only, an additional RFC _will_ > be necessary to add data types to the IPFIX protocol, but this RFC > need not update the exporting-type RFC; nothing about new data types > will change how metainformation about those types will be represented > inline. > = > We selected Standards Action from RFC 2434 as the update policy for > the created registries after discussion at one of the working group > meetings (Vancouver, I think, but I may be remembering incorrectly), > because there are potentially serious interoperability concerns raised > by adding new datatypes to the protocol, specifically in how > information of the new types is to be encoded on the wire. > = > > Regards > > Emile > > > > > > De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] > > Envoy=E9 : jeudi 3 avril 2008 16:10 > > =C0 : STEPHAN Emile RD-CORE-LAN > > Cc : ipfix@ietf.org; bht@cert.org > > Objet : Re: [IPFIX] expanding type and semantics registries (was Re: > > missing notes on exporting type...) > > > > Emile, > > > > > There is not doubt that the datamodel have to be extended in short > > term. > > > 'enumerated' is the right example. It is missing in the datamodel > > and it > > > is a ground truth storage datatype. > > > > > > In the current approach, the adding of 'enumerated' as an abstract > > > datatype in the datamodel will require the update of > > > draft-ietf-ipfix-exporting-type because this draft defines a static > > > registry in the section "3.1. informationElementDataType". > > > > > > > maybe the data model will have to be extended, but this would be an > > information model extension (i.e. an update of RFC5102) and I don't > > think it belongs logically to a method description for exporting > > information model information on the wire. > > Of course changes in the information model are likely to affect this > > document too... > > > > > > > To avoid static pieces in the IPFIX datamodel in the future it is > > > mandatory to define an IPFIX IE for each abstract data types > > defined in > > > the IPFIX datamodel: > > > > > > octetArray > > > unsigned8 > > > unsigned16 > > > unsigned32 > > > unsigned64 > > > signed8 > > > signed16 > > > signed32 > > > signed64 > > > float32 > > > float64 > > > boolean > > > macAddress > > > string > > > dateTimeSeconds > > > dateTimeMilliseconds > > > dateTimeMicroseconds > > > dateTimeNanoseconds > > > ipv4Address > > > ipv6Address > > > > > > The WG has the opportunity to do that with draft-ietf-ipfix- > > exporting-type. > > > > > > > I understand your concern, but I think that this is out of scope for > > this document. If the working group wants to add this flexibility I > > suggest opening a separate thread on this to discuss how this issue > > should be addressed. > > > > thanks, > > Elisa > > > > > Regards > > > > > > Emile > > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types > > prevents > > > > > >> > adding new one in the future without updating the draft. There > > are > > > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > > > >> -----Message d'origine----- > > > > > >> De : Brian Trammell [mailto:bht@cert.org] > > > > > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > > > > > >> =C0 : STEPHAN Emile RD-CORE-LAN > > > > > >> Cc : ipfix@ietf.org > > > > > >> Objet : expanding type and semantics registries (was Re: missing > > notes on > > > > > >> exporting type...) > > > > > >> > > > > > >> Emile, > > > > > >> > > > > > >> Ah, yes. Thanks. I remember now. My short, short answer on this > > was > > > > > >> "no, but..." > > > > > >> > > > > > >> Here's why: > > > > > >> > > > > > >> The data type and semantics registries are taken directly from RFC > > > > > >> 5102. This document doesn't seek to expand the types or > > semantics, it > > > > > >> only seeks to create formal IANA registries for a list of types > > > > > >> _already_ defined on the standards track. The reason behind > > creating > > > > > >> those registries is to map the types themselves to numeric codes > > used > > > > > >> to represent them in the informationElementDataType and > > > > > >> informationElementSemantics IEs. The reason behind declaring their > > > > > >> modification to be subject to a Standards Action as per RFC 2434 > > is to > > > > > >> ensure that > > > > > >> > > > > > >> Adding a new data type to IPFIX is not simply a matter of > > sticking a > > > > > >> new name and number into the data type registry -- specific > > > > > >> information on the definition (as in section 3.1 of RFC 5102) and > > > > > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > > > > > >> provided to allow the Exporting Process to properly encode and the > > > > > >> Collecting Process to properly decode and recognize data of that > > type. > > > > > >> Even if it's just a reference to an external standard (as 5101's > > > > > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point > > types), > > > > > >> it's still absolutely necessary to have some document extending > > the > > > > > >> set of types for IPFIX to ensure interoperability of those new > > types. > > > > > >> And that's out of scope for _this_ document, which, as > > chartered, only > > > > > >> provides a _mechanism_ for describing the types already supported. > > > > > >> > > > > > >> That said, you have a very good point. > > > > > >> > > > > > >> There are quite a few types that could be immediately useful; > > and yes, > > > > > >> additional network-identifiers such as URL, email, and FQDN are > > > > > >> obvious first choices, which can only be implemented as Strings > > at the > > > > > >> moment. Enumelated per essence to a flow nor to the d= irection of a flow. This is an urgently needed to limit reasonably the numb= er of proprietary IEs. Regards Emile > -----Message d'origine----- > De=A0: Brian Trammell [mailto:bht@cert.org] > Envoy=E9=A0: lundi 14 avril 2008 20:44 > =C0=A0: STEPHAN Emile RD-CORE-LAN > Cc=A0: dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi-eu.com > Objet=A0: Re: [IPFIX] expanding type and semantics registries (was Re: > missing notes on exporting type...) > = > Emile and all, > = > Replies inline. > = > Regards, > = > Brian > = > On Apr 14, 2008, at 10:03 AM, > > wrote: > > Hi Dan > > > > Sorry for de delay. > > > > Elisa said: > > > > > maybe the data model will have to be extended, but this would be > > an information model extension (i.e. an update of RFC5102) and I > > don't think it belongs > > > logically to a method description for exporting information model > > information on the wire. > > > Of course changes in the information model are likely to affect > > this document too... > > > > To make it short: > > We all agree that, without change, the RFC resulting of draft-ietf- > > ipfix-exporting-type will have to be updated each time a new > > datatype is defined. > = > No. This is not the case. The exporting-type RFC will not need to be > updated when data types are added to the protocol. The exporting-type > draft says nothing about the data types available in IPFIX (that's the > job of RFCs 5101/5102). It simply creates an IANA registry and > populates it with the data types and semantics already defined within > the protocol. It creates this registry solely so that datatypes can be > mapped to numbers for the representation of type information inline. > = > > My understanding of the current practice inside IETF is that > > numbering must be registered by IANA when the datamodel allows the > > definition of new datatypes in the future. So, if my view is > > correct, the numbering of the datatypes of the IPFIX datamodel > > (RFC5102) made in draft-ietf-ipfix-exporting-type has to be > > registered by IANA. > = > Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of > exporting-type. > = > Note that, as the data type and semantics registries are defined to be > updated by an RFC 2434 Standards Action only, an additional RFC _will_ > be necessary to add data types to the IPFIX protocol, but this RFC > need not update the exporting-type RFC; nothing about new data types > will change how metainformation about those types will be represented > inline. > = > We selected Standards Action from RFC 2434 as the update policy for > the created registries after discussion at one of the working group > meetings (Vancouver, I think, but I may be remembering incorrectly), > because there are potentially serious interoperability concerns raised > by adding new datatypes to the protocol, specifically in how > information of the new types is to be encoded on the wire. > = > > Regards > > Emile > > > > > > De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] > > Envoy=E9 : jeudi 3 avril 2008 16:10 > > =C0 : STEPHAN Emile RD-CORE-LAN > > Cc : ipfix@ietf.org; bht@cert.org > > Objet : Re: [IPFIX] expanding type and semantics registries (was Re: > > missing notes on exporting type...) > > > > Emile, > > > > > There is not doubt that the datamodel have to be extended in short > > term. > > > 'enumerated' is the right example. It is missing in the datamodel > > and it > > > is a ground truth storage datatype. > > > > > > In the current approach, the adding of 'enumerated' as an abstract > > > datatype in the datamodel will require the update of > > > draft-ietf-ipfix-exporting-type because this draft defines a static > > > registry in the section "3.1. informationElementDataType". > > > > > > > maybe the data model will have to be extended, but this would be an > > information model extension (i.e. an update of RFC5102) and I don't > > think it belongs logically to a method description for exporting >erations are another issue, and can already be > > partially > > > > > >> implemented using the Reducing Redundancy mechanism. > > > > > >> > > > > > >> My suggestion, however, would be a new document, to be > > considered for > > > > > >> a future WG charter, to _explicitly_ extend the set of types > > supported > > > > > >> by IPFIX, and adding those types to the registry created in > > exporting- > > > > > >> type. > > > > > >> > > > > > >> Cheers, > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Mar 28, 2008, at 2:20 PM, > > wrote: > > > > > >> > Hi Brian, > > > > > >> > > > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types > > prevents > > > > > >> > adding new one in the future without updating the draft. There > > are > > > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > > > >> > > > > > > >> > Adding these types to the IPFIX datamodel increases the scope of > > > > > >> > usage of IPFIX and interoperability. It permits the usage of > > > > > >> > standard IE for exporting specific information. It permits the > > > > > >> > collector to store this information in an efficient way. It > > > > > >> > encourage enterprises to use standard IE instead of enterprises > > > > > >> > specific ones. > > > > > >> > > > > > > >> > > > > > > >> > Therefore the draft has to define them as IEs and the IANA > > section > > > > > >> > have to request IANA to add them the IPFIX datamodel registry. > > > > > >> > > > > > > >> > > > > > > >> > Regards > > > > > >> > > > > > > >> > Emile > > > > > >> > > > > > > >> > > > > > > >> > > -----Message d'origine----- > > > > > >> > > > > > > >> > > De : Brian Trammell [mailto:bht@cert.org] > > > > > >> > > > > > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > > > >> > > > > > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > > > > > >> > > > > > > >> > > Objet : missing notes on exporting type... > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Emile, > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > As I recall, we had a conversation in Philadelphia about some > > > > > >> > specific > > > > > >> > > > > > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an > > answer for > > > > > >> > > > > > > >> > > your question, and I was going to post a message to the list > > about > > > > > >> > > > > > > >> > > that... but, I can't seem to find my note on the subject, > > and it's > > > > > >> > > > > > > >> > > been a rather eventful couple of weeks, and I have > > consequently > > > > > >> > > > > > > >> > > _completely_ forgotten it. > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > So. > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Would you happen to remember what we were talking about, so > > we could > > > > > >> > > > > > > >> > > perhaps start over on the subject? > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Thanks, > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Brian > > > > > > > > > ************************************************************************** > ************************ > > E-mail Confidentiality Notice and Disclaimer. > > > > This e-mail and any files transmitted with it are confidential and > > are intended solely for the use of the individual or entity to which > > they are addressed. Access to this e-mail by anyone else is > > unauthorised. If you are not the intended recipient, any disclosure, > > copying, distribution or any action taken or omitted to be taken in > > reliance on it, is prohibited. > > E-mail messages are not necessarily secure. > > Hitachi does not accept responsibility for any changes made to this > > message after it was sent. > > Hitachi checks outgoing e-mail messages for the presence of computer > > viruses. > > > ************************************************************************** > ************************ > > ________________________ > information model information on the wire. > > Of course changes in the information model are likely to affect this > > document too... > > > > > > > To avoid static pieces in the IPFIX datamodel in the future it is > > > mandatory to define an IPFIX IE for each abstract data types > > defined in > > > the IPFIX datamodel: > > > > > > octetArray > > > unsigned8 > > > unsigned16 > > > unsigned32 > > > unsigned64 > > > signed8 > > > signed16 > > > signed32 > > > signed64 > > > float32 > > > float64 > > > boolean > > > macAddress > > > string > > > dateTimeSeconds > > > dateTimeMilliseconds > > > dateTimeMicroseconds > > > dateTimeNanoseconds > > > ipv4Address > > > ipv6Address > > > > > > The WG has the opportunity to do that with draft-ietf-ipfix- > > exporting-type. > > > > > > > I understand your concern, but I think that this is out of scope for > > this document. If the working group wants to add this flexibility I > > suggest opening a separate thread on this to discuss how this issue > > should be addressed. > > > > thanks, > > Elisa > > > > > Regards > > > > > > Emile > > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types > > prevents > > > > > >> > adding new one in the future without updating the draft. There > > are > > > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > > > >> -----Message d'origine----- > > > > > >> De : Brian Trammell [mailto:bht@cert.org] > > > > > >> Envoy=E9 : vendredi 28 mars 2008 22:57 > > > > > >> =C0 : STEPHAN Emile RD-CORE-LAN > > > > > >> Cc : ipfix@ietf.org > > > > > >> Objet : expanding type and semantics registries (was Re: missing > > notes on > > > > > >> exporting type...) > > > > > >> > > > > > >> Emile, > > > > > >> > > > > > >> Ah, yes. Thanks. I remember now. My short, short answer on this > > was > > > > > >> "no, but..." > > > > > >> > > > > > >> Here's why: > > > > > >> > > > > > >> The data type and semantics registries are taken directly from RFC > > > > > >> 5102. This document doesn't seek to expand the types or > > semantics, it > > > > > >> only seeks to create formal IANA registries for a list of types > > > > > >> _already_ defined on the standards track. The reason behind > > creating > > > > > >> those registries is to map the types themselves to numeric codes > > used > > > > > >> to represent them in the informationElementDataType and > > > > > >> informationElementSemantics IEs. The reason behind declaring their > > > > > >> modification to be subject to a Standards Action as per RFC 2434 > > is to > > > > > >> ensure that > > > > > >> > > > > > >> Adding a new data type to IPFIX is not simply a matter of > > sticking a > > > > > >> new name and number into the data type registry -- specific > > > > > >> information on the definition (as in section 3.1 of RFC 5102) and > > > > > >> encoding (as in section 6.1 of RFC 5101) of the data type must be > > > > > >> provided to allow the Exporting Process to properly encode and the > > > > > >> Collecting Process to properly decode and recognize data of that > > type. > > > > > >> Even if it's just a reference to an external standard (as 5101's > > > > > >> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point > > types), > > > > > >> it's still absolutely necessary to have some document extending > > the > > > > > >> set of types for IPFIX to ensure interoperability of those new > > types. > > > > > >> And that's out of scope for _this_ document, which, as > > chartered, only > > > > > >> provides a _mechanism_ for describing the types already supported. > > > > > >> > > > > > >> That said, you have a very good point. > > > > > >> > > > > > >> There are quite a few types that could be immediately useful; > > and yes, > > > > > >> additional network-identifiers such as URL, email, and FQDN are > > > > > >> obvious first choices, which can only be implemented as Strings > > at the > > > > > >> moment. En_______________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix umerations are another issue, and can already be > > partially > > > > > >> implemented using the Reducing Redundancy mechanism. > > > > > >> > > > > > >> My suggestion, however, would be a new document, to be > > considered for > > > > > >> a future WG charter, to _explicitly_ extend the set of types > > supported > > > > > >> by IPFIX, and adding those types to the registry created in > > exporting- > > > > > >> type. > > > > > >> > > > > > >> Cheers, > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Mar 28, 2008, at 2:20 PM, > > wrote: > > > > > >> > Hi Brian, > > > > > >> > > > > > > >> > The way the draft-ietf-ipfix-exporting-type defines types > > prevents > > > > > >> > adding new one in the future without updating the draft. There > > are > > > > > >> > already potential candidates: Enumerated, email, DNS, URL .... > > > > > >> > > > > > > >> > Adding these types to the IPFIX datamodel increases the scope of > > > > > >> > usage of IPFIX and interoperability. It permits the usage of > > > > > >> > standard IE for exporting specific information. It permits the > > > > > >> > collector to store this information in an efficient way. It > > > > > >> > encourage enterprises to use standard IE instead of enterprises > > > > > >> > specific ones. > > > > > >> > > > > > > >> > > > > > > >> > Therefore the draft has to define them as IEs and the IANA > > section > > > > > >> > have to request IANA to add them the IPFIX datamodel registry. > > > > > >> > > > > > > >> > > > > > > >> > Regards > > > > > >> > > > > > > >> > Emile > > > > > >> > > > > > > >> > > > > > > >> > > -----Message d'origine----- > > > > > >> > > > > > > >> > > De : Brian Trammell [mailto:bht@cert.org] > > > > > >> > > > > > > >> > > Envoy=E9 : vendredi 28 mars 2008 02:11 > > > > > >> > > > > > > >> > > =C0 : STEPHAN Emile RD-CORE-LAN > > > > > >> > > > > > > >> > > Objet : missing notes on exporting type... > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Emile, > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > As I recall, we had a conversation in Philadelphia about some > > > > > >> > specific > > > > > >> > > > > > > >> > > aspect of draft-ietf-ipfix-exporting-type, and I had an > > answer for > > > > > >> > > > > > > >> > > your question, and I was going to post a message to the list > > about > > > > > >> > > > > > > >> > > that... but, I can't seem to find my note on the subject, > > and it's > > > > > >> > > > > > > >> > > been a rather eventful couple of weeks, and I have > > consequently > > > > > >> > > > > > > >> > > _completely_ forgotten it. > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > So. > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Would you happen to remember what we were talking about, so > > we could > > > > > >> > > > > > > >> > > perhaps start over on the subject? > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Thanks, > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > > Brian > > > > > > > > > ************************************************************************** > ************************ > > E-mail Confidentiality Notice and Disclaimer. > > > > This e-mail and any files transmitted with it are confidential and > > are intended solely for the use of the individual or entity to which > > they are addressed. Access to this e-mail by anyone else is > > unauthorised. If you are not the intended recipient, any disclosure, > > copying, distribution or any action taken or omitted to be taken in > > reliance on it, is prohibited. > > E-mail messages are not necessarily secure. > > Hitachi does not accept responsibility for any changes made to this > > message after it was sent. > > Hitachi checks outgoing e-mail messages for the presence of computer > > viruses. > > > ************************************************************************** > ************************ > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Apr 16 12:15:36 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C776C3A6C66; Wed, 16 Apr 2008 12:15:36 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39643A68AB for ; Wed, 16 Apr 2008 12:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTwP9osfMPms for ; Wed, 16 Apr 2008 12:15:33 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id D65B53A6982 for ; Wed, 16 Apr 2008 12:15:03 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m3GJFZAg025022 for ; Wed, 16 Apr 2008 15:15:37 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m3GJEPQp024907 for ; Wed, 16 Apr 2008 15:14:25 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m3GJEPki024900; Wed, 16 Apr 2008 15:14:25 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-17.remote.cert.org [10.25.4.17]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m3GJEPLk015133; Wed, 16 Apr 2008 15:14:25 -0400 Message-Id: <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> From: Brian Trammell To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 15:14:24 -0400 References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> X-Mailer: Apple Mail (2.919.2) Cc: Elisa Boschi , ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Emile, Replies inline... On Apr 16, 2008, at 10:42 AM, wrote: > > > Hi Brain, > > Thanks for the explanation. This framework limit's is reached when = > an enterprise has to export the type of an IE which abstract data = > type is not defined in the datamodel of the RFC5102. So the registry = > of the section 3 must not be limited to the exiting abstract data = > types. It must include any existing database datatypes to reach, at = > least, the initial goal of storing efficiently any proprietary IEs. > > Otherwise, for sure, enterprises will 'complete' the table of = > section 3.1 with their own abstract datatypes and tags. Then = > collectors will have to get these values (using their cristal ball) = > and to hardcode these values in a multidimensional table, then, = > later, the IPFIX WG will have to specify some solution to export = > proprietary abstract data types... Enterprises can't "complete" the data type table without a standards = action -- this is the point of restricting additions to that registry = as exporting-type does currently. Without this, the best an enterprise = can do for a new data type encoding is to represent it as an octet- = array -- which is precisely as good as it can do without exporting- = type. So, no loss here. That said, I think we have different ideas as to what comprises a = "data type". The core data types supported by 5101/5102 are the basic primitive = scalar types supported by most reasonably modern programming = languages, plus specific subtypes of ordered octet arrays or special = integer encodings corresponding to packet header (link-layer and = network address) field types and collection infrastructure (timestamp) = field types. It is unclear which scalar primitives we're missing. You pointed out email addresses, FQDNs, and URIs as candidates for new = abstract data types. All are already representable by Strings, and are = all restricted subtypes of String. These make sense at first glance; = however, on further reflection such would add a new error condition at = the IPFIX Collecting Process side that would require protocol changes. All the presently supported data types, save String, have the property = that any sequence of bytes within the IE has a single valid decoding. = This is trivially true for integer, address, and datetime types; IEEE = 754 states that all byte sequences are either numbers or valid NaNs = (with the caveat that positive and negative zero may require special = handling, but this is to be handled at a layer above IPFIX.) Strings = are encoded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while = all byte sequences are not necessarily legal UTF-8, there are accepted = methods for decoding or ignoring these illegal sequences (though these = may themselves have security implications; see RFC 2279 section 6). We = probably should have addressed this a bit more carefully in RFC 5101, = but it's pretty clear that clarifying erroneous UTF-8 string decoding = in exporting-type is _way_ out of scope. This is not the case for URIs, or email addresses, or FQDNs. These = "data types" are essentially encodings (UTF8 Strings) with a contract = to keep the content conformant to some syntax. No other IPFIX data = type has this property. Illegal UTF-8 sequences are corner cases; = legal UTF-8 sequences that are not legal URIs comprise the majority of = UTF-8 code space. What is a Collecting Process to do with such non- = conformant byte sequences? What additional information does such a = contract provide to the Collecting Process? (Note that it is _precisely_ data type encoding complications such as = this one that led us to restrict additions to the data type registry = to standards actions.) So, which scalar primitives are we missing? Structured abstract data types and collection types are another story, = but they'll require protocol changes and new template mechanisms, so = they're also way, way out of scope for exporting-type. > So, with real respect to the work done and to its need, this draft = > does not encourage the usage of standard IEs and the migration = > towards standard IEs. I disagree. The mechanism here encourages standardization and = transition of provisional enterprise-specific information elements to = the degree possible without changing the protocol or the nature of the = information model itself. > It should. Abstract data type IEs are really required in option = > templates to describe abstract contexts not related per essence to a = > flow nor to the direction of a flow. This is an urgently needed to = > limit reasonably the number of proprietary IEs. No particular disagreement here (though this proposal still seems to = me to be an alternate, typed, unlabeled enterprise-specific IE = mechanism with potentially serious multiple-IE interpretation issues, = and I'm still not 100% clear what you want them for). But once more, = this is _not_ in scope for a draft which specifies a only a mechanism = for inline type information encoding. It's also not something you need = an RFC for; the IE registry is appendable subject only to expert (at = this point, Nevil) review. Regards, Brian > Regards > Emile >> -----Message d'origine----- >> De : Brian Trammell [mailto:bht@cert.org] >> Envoy=E9 : lundi 14 avril 2008 20:44 >> =C0 : STEPHAN Emile RD-CORE-LAN >> Cc : dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi-eu.com >> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >> missing notes on exporting type...) >> >> Emile and all, >> >> Replies inline. >> >> Regards, >> >> Brian >> >> On Apr 14, 2008, at 10:03 AM, >> >> wrote: >>> Hi Dan >>> >>> Sorry for de delay. >>> >>> Elisa said: >>> >>>> maybe the data model will have to be extended, but this would be >>> an information model extension (i.e. an update of RFC5102) and I >>> don't think it belongs >>>> logically to a method description for exporting information model >>> information on the wire. >>>> Of course changes in the information model are likely to affect >>> this document too... >>> >>> To make it short: >>> We all agree that, without change, the RFC resulting of draft-ietf- >>> ipfix-exporting-type will have to be updated each time a new >>> datatype is defined. >> >> No. This is not the case. The exporting-type RFC will not need to be >> updated when data types are added to the protocol. The exporting-type >> draft says nothing about the data types available in IPFIX (that's = >> the >> job of RFCs 5101/5102). It simply creates an IANA registry and >> populates it with the data types and semantics already defined within >> the protocol. It creates this registry solely so that datatypes can = >> be >> mapped to numbers for the representation of type information inline. >> >>> My understanding of the current practice inside IETF is that >>> numbering must be registered by IANA when the datamodel allows the >>> definition of new datatypes in the future. So, if my view is >>> correct, the numbering of the datatypes of the IPFIX datamodel >>> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be >>> registered by IANA. >> >> Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of >> exporting-type. >> >> Note that, as the data type and semantics registries are defined to = >> be >> updated by an RFC 2434 Standards Action only, an additional RFC = >> _will_ >> be necessary to add data types to the IPFIX protocol, but this RFC >> need not update the exporting-type RFC; nothing about new data types >> will change how metainformation about those types will be represented >> inline. >> >> We selected Standards Action from RFC 2434 as the update policy for >> the created registries after discussion at one of the working group >> meetings (Vancouver, I think, but I may be remembering incorrectly), >> because there are potentially serious interoperability concerns = >> raised >> by adding new datatypes to the protocol, specifically in how >> information of the new types is to be encoded on the wire. >> >>> Regards >>> Emile >>> >>> >>> De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] >>> Envoy=E9 : jeudi 3 avril 2008 16:10 >>> =C0 : STEPHAN Emile RD-CORE-LAN >>> Cc : ipfix@ietf.org; bht@cert.org >>> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >>> missing notes on exporting type...) >>> >>> Emile, >>> >>>> There is not doubt that the datamodel have to be extended in short >>> term. >>>> 'enumerated' is the right example. It is missing in the datamodel >>> and it >>>> is a ground truth storage datatype. >>>> >>>> In the current approach, the adding of 'enumerated' as an abstract >>>> datatype in the datamodel will require the update of >>>> draft-ietf-ipfix-exporting-type because this draft defines a static >>>> registry in the section "3.1. informationElementDataType". >>>> >>> >>> maybe the data model will have to be extended, but this would be an >>> information model extension (i.e. an update of RFC5102) and I don't >>> think it belongs logically to a method description for exporting >>> information model information on the wire. >>> Of course changes in the information model are likely to affect this >>> document too... >>> >>> >>>> To avoid static pieces in the IPFIX datamodel in the future it is >>>> mandatory to define an IPFIX IE for each abstract data types >>> defined in >>>> the IPFIX datamodel: >>>> >>>> octetArray >>>> unsigned8 >>>> unsigned16 >>>> unsigned32 >>>> unsigned64 >>>> signed8 >>>> signed16 >>>> signed32 >>>> signed64 >>>> float32 >>>> float64 >>>> boolean >>>> macAddress >>>> string >>>> dateTimeSeconds >>>> dateTimeMilliseconds >>>> dateTimeMicroseconds >>>> dateTimeNanoseconds >>>> ipv4Address >>>> ipv6Address >>>> >>>> The WG has the opportunity to do that with draft-ietf-ipfix- >>> exporting-type. >>>> >>> >>> I understand your concern, but I think that this is out of scope for >>> this document. If the working group wants to add this flexibility I >>> suggest opening a separate thread on this to discuss how this issue >>> should be addressed. >>> >>> thanks, >>> Elisa >>> >>>> Regards >>>> >>>> Emile >>>> >>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>> prevents >>>> >>>>>> adding new one in the future without updating the draft. There >>> are >>>> >>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>> >>>>> -----Message d'origine----- >>>> >>>>> De : Brian Trammell [mailto:bht@cert.org] >>>> >>>>> Envoy=E9 : vendredi 28 mars 2008 22:57 >>>> >>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> >>>>> Cc : ipfix@ietf.org >>>> >>>>> Objet : expanding type and semantics registries (was Re: missing >>> notes on >>>> >>>>> exporting type...) >>>> >>>>> >>>> >>>>> Emile, >>>> >>>>> >>>> >>>>> Ah, yes. Thanks. I remember now. My short, short answer on this >>> was >>>> >>>>> "no, but..." >>>> >>>>> >>>> >>>>> Here's why: >>>> >>>>> >>>> >>>>> The data type and semantics registries are taken directly from RFC >>>> >>>>> 5102. This document doesn't seek to expand the types or >>> semantics, it >>>> >>>>> only seeks to create formal IANA registries for a list of types >>>> >>>>> _already_ defined on the standards track. The reason behind >>> creating >>>> >>>>> those registries is to map the types themselves to numeric codes >>> used >>>> >>>>> to represent them in the informationElementDataType and >>>> >>>>> informationElementSemantics IEs. The reason behind declaring their >>>> >>>>> modification to be subject to a Standards Action as per RFC 2434 >>> is to >>>> >>>>> ensure that >>>> >>>>> >>>> >>>>> Adding a new data type to IPFIX is not simply a matter of >>> sticking a >>>> >>>>> new name and number into the data type registry -- specific >>>> >>>>> information on the definition (as in section 3.1 of RFC 5102) and >>>> >>>>> encoding (as in section 6.1 of RFC 5101) of the data type must be >>>> >>>>> provided to allow the Exporting Process to properly encode and the >>>> >>>>> Collecting Process to properly decode and recognize data of that >>> type. >>>> >>>>> Even if it's just a reference to an external standard (as 5101's >>>> >>>>> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point >>> types), >>>> >>>>> it's still absolutely necessary to have some document extending >>> the >>>> >>>>> set of types for IPFIX to ensure interoperability of those new >>> types. >>>> >>>>> And that's out of scope for _this_ document, which, as >>> chartered, only >>>> >>>>> provides a _mechanism_ for describing the types already supported. >>>> >>>>> >>>> >>>>> That said, you have a very good point. >>>> >>>>> >>>> >>>>> There are quite a few types that could be immediately useful; >>> and yes, >>>> >>>>> additional network-identifiers such as URL, email, and FQDN are >>>> >>>>> obvious first choices, which can only be implemented as Strings >>> at the >>>> >>>>> moment. Enumerations are another issue, and can already be >>> partially >>>> >>>>> implemented using the Reducing Redundancy mechanism. >>>> >>>>> >>>> >>>>> My suggestion, however, would be a new document, to be >>> considered for >>>> >>>>> a future WG charter, to _explicitly_ extend the set of types >>> supported >>>> >>>>> by IPFIX, and adding those types to the registry created in >>> exporting- >>>> >>>>> type. >>>> >>>>> >>>> >>>>> Cheers, >>>> >>>>> >>>> >>>>> Brian >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Mar 28, 2008, at 2:20 PM, >>> wrote: >>>> >>>>>> Hi Brian, >>>> >>>>>> >>>> >>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>> prevents >>>> >>>>>> adding new one in the future without updating the draft. There >>> are >>>> >>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>> >>>>>> >>>> >>>>>> Adding these types to the IPFIX datamodel increases the scope of >>>> >>>>>> usage of IPFIX and interoperability. It permits the usage of >>>> >>>>>> standard IE for exporting specific information. It permits the >>>> >>>>>> collector to store this information in an efficient way. It >>>> >>>>>> encourage enterprises to use standard IE instead of enterprises >>>> >>>>>> specific ones. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Therefore the draft has to define them as IEs and the IANA >>> section >>>> >>>>>> have to request IANA to add them the IPFIX datamodel registry. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Regards >>>> >>>>>> >>>> >>>>>> Emile >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> -----Message d'origine----- >>>> >>>>>> >>>> >>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>> >>>>>> >>>> >>>>>>> Envoy=E9 : vendredi 28 mars 2008 02:11 >>>> >>>>>> >>>> >>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> >>>>>> >>>> >>>>>>> Objet : missing notes on exporting type... >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Emile, >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> As I recall, we had a conversation in Philadelphia about some >>>> >>>>>> specific >>>> >>>>>> >>>> >>>>>>> aspect of draft-ietf-ipfix-exporting-type, and I had an >>> answer for >>>> >>>>>> >>>> >>>>>>> your question, and I was going to post a message to the list >>> about >>>> >>>>>> >>>> >>>>>>> that... but, I can't seem to find my note on the subject, >>> and it's >>>> >>>>>> >>>> >>>>>>> been a rather eventful couple of weeks, and I have >>> consequently >>>> >>>>>> >>>> >>>>>>> _completely_ forgotten it. >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> So. >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Would you happen to remember what we were talking about, so >>> we could >>>> >>>>>> >>>> >>>>>>> perhaps start over on the subject? >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Thanks, >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Brian >>> >>> >>> >>> >> ************************************************************************= ** >> ************************ >>> E-mail Confidentiality Notice and Disclaimer. >>> >>> This e-mail and any files transmitted with it are confidential and >>> are intended solely for the use of the individual or entity to which >>> they are addressed. Access to this e-mail by anyone else is >>> unauthorised. If you are not the intended recipient, any disclosure, >>> copying, distribution or any action taken or omitted to be taken in >>> reliance on it, is prohibited. >>> E-mail messages are not necessarily secure. >>> Hitachi does not accept responsibility for any changes made to this >>> message after it was sent. >>> Hitachi checks outgoing e-mail messages for the presence of computer >>> viruses. >>> >> ************************************************************************= ** >> ************************ >>> > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Apr 16 12:15:36 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C776C3A6C66; Wed, 16 Apr 2008 12:15:36 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39643A68AB for ; Wed, 16 Apr 2008 12:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTwP9osfMPms for ; Wed, 16 Apr 2008 12:15:33 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id D65B53A6982 for ; Wed, 16 Apr 2008 12:15:03 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m3GJFZAg025022 for ; Wed, 16 Apr 2008 15:15:37 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m3GJEPQp024907 for ; Wed, 16 Apr 2008 15:14:25 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m3GJEPki024900; Wed, 16 Apr 2008 15:14:25 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-17.remote.cert.org [10.25.4.17]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m3GJEPLk015133; Wed, 16 Apr 2008 15:14:25 -0400 Message-Id: <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> From: Brian Trammell To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 15:14:24 -0400 References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> X-Mailer: Apple Mail (2.919.2) Cc: Elisa Boschi , ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Emile, Replies inline... On Apr 16, 2008, at 10:42 AM, wrote: > > > Hi Brain, > > Thanks for the explanation. This framework limit's is reached when = > an enterprise has to export the type of an IE which abstract data = > type is not defined in the datamodel of the RFC5102. So the registry = > of the section 3 must not be limited to the exiting abstract data = > types. It must include any existing database datatypes to reach, at = > least, the initial goal of storing efficiently any proprietary IEs. > > Otherwise, for sure, enterprises will 'complete' the table of = > section 3.1 with their own abstract datatypes and tags. Then = > collectors will have to get these values (using their cristal ball) = > and to hardcode these values in a multidimensional table, then, = > later, the IPFIX WG will have to specify some solution to export = > proprietary abstract data types... Enterprises can't "complete" the data type table without a standards = action -- this is the point of restricting additions to that registry = as exporting-type does currently. Without this, the best an enterprise = can do for a new data type encoding is to represent it as an octet- = array -- which is precisely as good as it can do without exporting- = type. So, no loss here. That said, I think we have different ideas as to what comprises a = "data type". The core data types supported by 5101/5102 are the basic primitive = scalar types supported by most reasonably modern programming = languages, plus specific subtypes of ordered octet arrays or special = integer encodings corresponding to packet header (link-layer and = network address) field types and collection infrastructure (timestamp) = field types. It is unclear which scalar primitives we're missing. You pointed out email addresses, FQDNs, and URIs as candidates for new = abstract data types. All are already representable by Strings, and are = all restricted subtypes of String. These make sense at first glance; = however, on further reflection such would add a new error condition at = the IPFIX Collecting Process side that would require protocol changes. All the presently supported data types, save String, have the property = that any sequence of bytes within the IE has a single valid decoding. = This is trivially true for integer, address, and datetime types; IEEE = 754 states that all byte sequences are either numbers or valid NaNs = (with the caveat that positive and negative zero may require special = handling, but this is to be handled at a layer above IPFIX.) Strings = are encoded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while = all byte sequences are not necessarily legal UTF-8, there are accepted = methods for decoding or ignoring these illegal sequences (though these = may themselves have security implications; see RFC 2279 section 6). We = probably should have addressed this a bit more carefully in RFC 5101, = but it's pretty clear that clarifying erroneous UTF-8 string decoding = in exporting-type is _way_ out of scope. This is not the case for URIs, or email addresses, or FQDNs. These = "data types" are essentially encodings (UTF8 Strings) with a contract = to keep the content conformant to some syntax. No other IPFIX data = type has this property. Illegal UTF-8 sequences are corner cases; = legal UTF-8 sequences that are not legal URIs comprise the majority of = UTF-8 code space. What is a Collecting Process to do with such non- = conformant byte sequences? What additional information does such a = contract provide to the Collecting Process? (Note that it is _precisely_ data type encoding complications such as = this one that led us to restrict additions to the data type registry = to standards actions.) So, which scalar primitives are we missing? Structured abstract data types and collection types are another story, = but they'll require protocol changes and new template mechanisms, so = they're also way, way out of scope for exporting-type. > So, with real respect to the work done and to its need, this draft = > does not encourage the usage of standard IEs and the migration = > towards standard IEs. I disagree. The mechanism here encourages standardization and = transition of provisional enterprise-specific information elements to = the degree possible without changing the protocol or the nature of the = information model itself. > It should. Abstract data type IEs are really required in option = > templates to describe abstract contexts not related per essence to a = > flow nor to the direction of a flow. This is an urgently needed to = > limit reasonably the number of proprietary IEs. No particular disagreement here (though this proposal still seems to = me to be an alternate, typed, unlabeled enterprise-specific IE = mechanism with potentially serious multiple-IE interpretation issues, = and I'm still not 100% clear what you want them for). But once more, = this is _not_ in scope for a draft which specifies a only a mechanism = for inline type information encoding. It's also not something you need = an RFC for; the IE registry is appendable subject only to expert (at = this point, Nevil) review. Regards, Brian > Regards > Emile >> -----Message d'origine----- >> De : Brian Trammell [mailto:bht@cert.org] >> Envoy=E9 : lundi 14 avril 2008 20:44 >> =C0 : STEPHAN Emile RD-CORE-LAN >> Cc : dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi-eu.com >> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >> missing notes on exporting type...) >> >> Emile and all, >> >> Replies inline. >> >> Regards, >> >> Brian >> >> On Apr 14, 2008, at 10:03 AM, >> >> wrote: >>> Hi Dan >>> >>> Sorry for de delay. >>> >>> Elisa said: >>> >>>> maybe the data model will have to be extended, but this would be >>> an information model extension (i.e. an update of RFC5102) and I >>> don't think it belongs >>>> logically to a method description for exporting information model >>> information on the wire. >>>> Of course changes in the information model are likely to affect >>> this document too... >>> >>> To make it short: >>> We all agree that, without change, the RFC resulting of draft-ietf- >>> ipfix-exporting-type will have to be updated each time a new >>> datatype is defined. >> >> No. This is not the case. The exporting-type RFC will not need to be >> updated when data types are added to the protocol. The exporting-type >> draft says nothing about the data types available in IPFIX (that's = >> the >> job of RFCs 5101/5102). It simply creates an IANA registry and >> populates it with the data types and semantics already defined within >> the protocol. It creates this registry solely so that datatypes can = >> be >> mapped to numbers for the representation of type information inline. >> >>> My understanding of the current practice inside IETF is that >>> numbering must be registered by IANA when the datamodel allows the >>> definition of new datatypes in the future. So, if my view is >>> correct, the numbering of the datatypes of the IPFIX datamodel >>> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be >>> registered by IANA. >> >> Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of >> exporting-type. >> >> Note that, as the data type and semantics registries are defined to = >> be >> updated by an RFC 2434 Standards Action only, an additional RFC = >> _will_ >> be necessary to add data types to the IPFIX protocol, but this RFC >> need not update the exporting-type RFC; nothing about new data types >> will change how metainformation about those types will be represented >> inline. >> >> We selected Standards Action from RFC 2434 as the update policy for >> the created registries after discussion at one of the working group >> meetings (Vancouver, I think, but I may be remembering incorrectly), >> because there are potentially serious interoperability concerns = >> raised >> by adding new datatypes to the protocol, specifically in how >> information of the new types is to be encoded on the wire. >> >>> Regards >>> Emile >>> >>> >>> De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] >>> Envoy=E9 : jeudi 3 avril 2008 16:10 >>> =C0 : STEPHAN Emile RD-CORE-LAN >>> Cc : ipfix@ietf.org; bht@cert.org >>> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >>> missing notes on exporting type...) >>> >>> Emile, >>> >>>> There is not doubt that the datamodel have to be extended in short >>> term. >>>> 'enumerated' is the right example. It is missing in the datamodel >>> and it >>>> is a ground truth storage datatype. >>>> >>>> In the current approach, the adding of 'enumerated' as an abstract >>>> datatype in the datamodel will require the update of >>>> draft-ietf-ipfix-exporting-type because this draft defines a static >>>> registry in the section "3.1. informationElementDataType". >>>> >>> >>> maybe the data model will have to be extended, but this would be an >>> information model extension (i.e. an update of RFC5102) and I don't >>> think it belongs logically to a method description for exporting >>> information model information on the wire. >>> Of course changes in the information model are likely to affect this >>> document too... >>> >>> >>>> To avoid static pieces in the IPFIX datamodel in the future it is >>>> mandatory to define an IPFIX IE for each abstract data types >>> defined in >>>> the IPFIX datamodel: >>>> >>>> octetArray >>>> unsigned8 >>>> unsigned16 >>>> unsigned32 >>>> unsigned64 >>>> signed8 >>>> signed16 >>>> signed32 >>>> signed64 >>>> float32 >>>> float64 >>>> boolean >>>> macAddress >>>> string >>>> dateTimeSeconds >>>> dateTimeMilliseconds >>>> dateTimeMicroseconds >>>> dateTimeNanoseconds >>>> ipv4Address >>>> ipv6Address >>>> >>>> The WG has the opportunity to do that with draft-ietf-ipfix- >>> exporting-type. >>>> >>> >>> I understand your concern, but I think that this is out of scope for >>> this document. If the working group wants to add this flexibility I >>> suggest opening a separate thread on this to discuss how this issue >>> should be addressed. >>> >>> thanks, >>> Elisa >>> >>>> Regards >>>> >>>> Emile >>>> >>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>> prevents >>>> >>>>>> adding new one in the future without updating the draft. There >>> are >>>> >>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>> >>>>> -----Message d'origine----- >>>> >>>>> De : Brian Trammell [mailto:bht@cert.org] >>>> >>>>> Envoy=E9 : vendredi 28 mars 2008 22:57 >>>> >>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> >>>>> Cc : ipfix@ietf.org >>>> >>>>> Objet : expanding type and semantics registries (was Re: missing >>> notes on >>>> >>>>> exporting type...) >>>> >>>>> >>>> >>>>> Emile, >>>> >>>>> >>>> >>>>> Ah, yes. Thanks. I remember now. My short, short answer on this >>> was >>>> >>>>> "no, but..." >>>> >>>>> >>>> >>>>> Here's why: >>>> >>>>> >>>> >>>>> The data type and semantics registries are taken directly from RFC >>>> >>>>> 5102. This document doesn't seek to expand the types or >>> semantics, it >>>> >>>>> only seeks to create formal IANA registries for a list of types >>>> >>>>> _already_ defined on the standards track. The reason behind >>> creating >>>> >>>>> those registries is to map the types themselves to numeric codes >>> used >>>> >>>>> to represent them in the informationElementDataType and >>>> >>>>> informationElementSemantics IEs. The reason behind declaring their >>>> >>>>> modification to be subject to a Standards Action as per RFC 2434 >>> is to >>>> >>>>> ensure that >>>> >>>>> >>>> >>>>> Adding a new data type to IPFIX is not simply a matter of >>> sticking a >>>> >>>>> new name and number into the data type registry -- specific >>>> >>>>> information on the definition (as in section 3.1 of RFC 5102) and >>>> >>>>> encoding (as in section 6.1 of RFC 5101) of the data type must be >>>> >>>>> provided to allow the Exporting Process to properly encode and the >>>> >>>>> Collecting Process to properly decode and recognize data of that >>> type. >>>> >>>>> Even if it's just a reference to an external standard (as 5101's >>>> >>>>> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point >>> types), >>>> >>>>> it's still absolutely necessary to have some document extending >>> the >>>> >>>>> set of types for IPFIX to ensure interoperability of those new >>> types. >>>> >>>>> And that's out of scope for _this_ document, which, as >>> chartered, only >>>> >>>>> provides a _mechanism_ for describing the types already supported. >>>> >>>>> >>>> >>>>> That said, you have a very good point. >>>> >>>>> >>>> >>>>> There are quite a few types that could be immediately useful; >>> and yes, >>>> >>>>> additional network-identifiers such as URL, email, and FQDN are >>>> >>>>> obvious first choices, which can only be implemented as Strings >>> at the >>>> >>>>> moment. Enumerations are another issue, and can already be >>> partially >>>> >>>>> implemented using the Reducing Redundancy mechanism. >>>> >>>>> >>>> >>>>> My suggestion, however, would be a new document, to be >>> considered for >>>> >>>>> a future WG charter, to _explicitly_ extend the set of types >>> supported >>>> >>>>> by IPFIX, and adding those types to the registry created in >>> exporting- >>>> >>>>> type. >>>> >>>>> >>>> >>>>> Cheers, >>>> >>>>> >>>> >>>>> Brian >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Mar 28, 2008, at 2:20 PM, >>> wrote: >>>> >>>>>> Hi Brian, >>>> >>>>>> >>>> >>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>> prevents >>>> >>>>>> adding new one in the future without updating the draft. There >>> are >>>> >>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>> >>>>>> >>>> >>>>>> Adding these types to the IPFIX datamodel increases the scope of >>>> >>>>>> usage of IPFIX and interoperability. It permits the usage of >>>> >>>>>> standard IE for exporting specific information. It permits the >>>> >>>>>> collector to store this information in an efficient way. It >>>> >>>>>> encourage enterprises to use standard IE instead of enterprises >>>> >>>>>> specific ones. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Therefore the draft has to define them as IEs and the IANA >>> section >>>> >>>>>> have to request IANA to add them the IPFIX datamodel registry. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Regards >>>> >>>>>> >>>> >>>>>> Emile >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> -----Message d'origine----- >>>> >>>>>> >>>> >>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>> >>>>>> >>>> >>>>>>> Envoy=E9 : vendredi 28 mars 2008 02:11 >>>> >>>>>> >>>> >>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> >>>>>> >>>> >>>>>>> Objet : missing notes on exporting type... >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Emile, >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> As I recall, we had a conversation in Philadelphia about some >>>> >>>>>> specific >>>> >>>>>> >>>> >>>>>>> aspect of draft-ietf-ipfix-exporting-type, and I had an >>> answer for >>>> >>>>>> >>>> >>>>>>> your question, and I was going to post a message to the list >>> about >>>> >>>>>> >>>> >>>>>>> that... but, I can't seem to find my note on the subject, >>> and it's >>>> >>>>>> >>>> >>>>>>> been a rather eventful couple of weeks, and I have >>> consequently >>>> >>>>>> >>>> >>>>>>> _completely_ forgotten it. >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> So. >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Would you happen to remember what we were talking about, so >>> we could >>>> >>>>>> >>>> >>>>>>> perhaps start over on the subject? >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Thanks, >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>>> Brian >>> >>> >>> >>> >> ************************************************************************= ** >> ************************ >>> E-mail Confidentiality Notice and Disclaimer. >>> >>> This e-mail and any files transmitted with it are confidential and >>> are intended solely for the use of the individual or entity to which >>> they are addressed. Access to this e-mail by anyone else is >>> unauthorised. If you are not the intended recipient, any disclosure, >>> copying, distribution or any action taken or omitted to be taken in >>> reliance on it, is prohibited. >>> E-mail messages are not necessarily secure. >>> Hitachi does not accept responsibility for any changes made to this >>> message after it was sent. >>> Hitachi checks outgoing e-mail messages for the presence of computer >>> viruses. >>> >> ************************************************************************= ** >> ************************ >>> > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Apr 17 02:07:31 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724CE3A693C; Thu, 17 Apr 2008 02:07:31 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEF93A6939 for ; Thu, 17 Apr 2008 02:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHPShwXeqywb for ; Thu, 17 Apr 2008 02:07:24 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E672C3A693C for ; Thu, 17 Apr 2008 02:07:23 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m3H97sXS022024; Thu, 17 Apr 2008 11:07:54 +0200 Message-ID: <48071369.4050404@informatik.uni-tuebingen.de> Date: Thu, 17 Apr 2008 11:07:53 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> In-Reply-To: <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.6; VDF: 7.0.3.177; host: mx05) Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all, I just want to say that Brian's rationales sound valid to me. As done in RFC 5102, we need to distinguish between Abstract Data Types, Data Type Semantics, and IEs. The purpose of the draft is to explain/define enterprise-specific IEs by their Abstract Data Type and their Data Type Semantic, plus a human-readable description, information about the unit, and range of valid values. The draft is not about defining new Abstract Data Types or Data Type Semantics. And I do not think it should be; otherwise, you would have to explain the en/decoding to the collector, which can be very complicated. With respect to the new types raised in the discussion, I currently do not see the need to add new Abstract Data Types. As Brian said, an URL can be encoded as a string. An enumeration can be encoded as an integer. Only if someone found a much more efficient way to encode this kind of information, it would be worth defining a new abstract data type. However, new Data Type Semantics like "enumeration" or "url" might be useful. Yet, as said above, this draft is not about new Data Type Semantics. Regards, Gerhard Brian Trammell wrote: > Emile, > = > Replies inline... > = > On Apr 16, From ipfix-bounces@ietf.org Thu Apr 17 02:07:31 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724CE3A693C; Thu, 17 Apr 2008 02:07:31 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEF93A6939 for ; Thu, 17 Apr 2008 02:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHPShwXeqywb for ; Thu, 17 Apr 2008 02:07:24 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E672C3A693C for ; Thu, 17 Apr 2008 02:07:23 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m3H97sXS022024; Thu, 17 Apr 2008 11:07:54 +0200 Message-ID: <48071369.4050404@informatik.uni-tuebingen.de> Date: Thu, 17 Apr 2008 11:07:53 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> In-Reply-To: <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.6; VDF: 7.0.3.177; host: mx05) Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all, I just want to say that Brian's rationales sound valid to me. As done in RFC 5102, we need to distinguish between Abstract Data Types, Data Type Semantics, and IEs. The purpose of the draft is to explain/define enterprise-specific IEs by their Abstract Data Type and their Data Type Semantic, plus a human-readable description, information about the unit, and range of valid values. The draft is not about defining new Abstract Data Types or Data Type Semantics. And I do not think it should be; otherwise, you would have to explain the en/decoding to the collector, which can be very complicated. With respect to the new types raised in the discussion, I currently do not see the need to add new Abstract Data Types. As Brian said, an URL can be encoded as a string. An enumeration can be encoded as an integer. Only if someone found a much more efficient way to encode this kind of information, it would be worth defining a new abstract data type. However, new Data Type Semantics like "enumeration" or "url" might be useful. Yet, as said above, this draft is not about new Data Type Semantics. Regards, Gerhard Brian Trammell wrote: > Emile, > = > Replies inline... > = > On Apr 16, 202008, at 10:42 AM, > wrote: >> >> Hi Brain, >> >> Thanks for the explanation. This framework limit's is reached when = >> an enterprise has to export the type of an IE which abstract data = >> type is not defined in the datamodel of the RFC5102. So the registry = >> of the section 3 must not be limited to the exiting abstract data = >> types. It must include any existing database datatypes to reach, at = >> least, the initial goal of storing efficiently any proprietary IEs. >> >> Otherwise, for sure, enterprises will 'complete' the table of = >> section 3.1 with their own abstract datatypes and tags. Then = >> collectors will have to get these values (using their cristal ball) = >> and to hardcode these values in a multidimensional table, then, = >> later, the IPFIX WG will have to specify some solution to export = >> proprietary abstract data types... > = > Enterprises can't "complete" the data type table without a standards = > action -- this is the point of restricting additions to that registry = > as exporting-type does currently. Without this, the best an enterprise = > can do for a new data type encoding is to represent it as an octet- = > array -- which is precisely as good as it can do without exporting- = > type. So, no loss here. > = > That said, I think we have different ideas as to what comprises a = > "data type". > = > The core data types supported by 5101/5102 are the basic primitive = > scalar types supported by most reasonably modern programming = > languages, plus specific subtypes of ordered octet arrays or special = > integer encodings corresponding to packet header (link-layer and = > network address) field types and collection infrastructure (timestamp) = > field types. It is unclear which scalar primitives we're missing. > = > You pointed out email addresses, FQDNs, and URIs as candidates for new = > abstract data types. All are already representable by Strings, and are = > all restricted subtypes of String. These make sense at first glance; = > however, on further reflection such would add a new error condition at = > the IPFIX Collecting Process side that would require protocol changes. > = > All the presently supported data types, save String, have the property = > that any sequence of bytes within the IE has a single valid decoding. = > This is trivially true for integer, address, and datetime types; IEEE = > 754 states that all byte sequences are either numbers or valid NaNs = > (with the caveat that positive and negative zero may require special = > handling, but this is to be handled at a layer above IPFIX.) Strings = > are encoded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while = > all byte sequences are not necessarily legal UTF-8, there are accepted = > methods for decoding or ignoring these illegal sequences (though these = > may themselves have security implications; see RFC 2279 section 6). We = > probably should have addressed this a bit more carefully in RFC 5101, = > but it's pretty clear that clarifying erroneous UTF-8 string decoding = > in exporting-type is _way_ out of scope. > = > This is not the case for URIs, or email addresses, or FQDNs. These = > "data types" are essentially encodings (UTF8 Strings) with a contract = > to keep the content conformant to some syntax. No other IPFIX data = > type has this property. Illegal UTF-8 sequences are corner cases; = > legal UTF-8 sequences that are not legal URIs comprise the majority of = > UTF-8 code space. What is a Collecting Process to do with such non- = > conformant byte sequences? What additional information does such a = > contract provide to the Collecting Process? > = > (Note that it is _precisely_ data type encoding complications such as = > this one that led us to restrict additions to the data type registry = > to standards actions.) > = > So, which scalar primitives are we missing? > = > Structured abstract data types and collection types08, at 10:42 AM, > wrote: >> >> Hi Brain, >> >> Thanks for the explanation. This framework limit's is reached when = >> an enterprise has to export the type of an IE which abstract data = >> type is not defined in the datamodel of the RFC5102. So the registry = >> of the section 3 must not be limited to the exiting abstract data = >> types. It must include any existing database datatypes to reach, at = >> least, the initial goal of storing efficiently any proprietary IEs. >> >> Otherwise, for sure, enterprises will 'complete' the table of = >> section 3.1 with their own abstract datatypes and tags. Then = >> collectors will have to get these values (using their cristal ball) = >> and to hardcode these values in a multidimensional table, then, = >> later, the IPFIX WG will have to specify some solution to export = >> proprietary abstract data types... > = > Enterprises can't "complete" the data type table without a standards = > action -- this is the point of restricting additions to that registry = > as exporting-type does currently. Without this, the best an enterprise = > can do for a new data type encoding is to represent it as an octet- = > array -- which is precisely as good as it can do without exporting- = > type. So, no loss here. > = > That said, I think we have different ideas as to what comprises a = > "data type". > = > The core data types supported by 5101/5102 are the basic primitive = > scalar types supported by most reasonably modern programming = > languages, plus specific subtypes of ordered octet arrays or special = > integer encodings corresponding to packet header (link-layer and = > network address) field types and collection infrastructure (timestamp) = > field types. It is unclear which scalar primitives we're missing. > = > You pointed out email addresses, FQDNs, and URIs as candidates for new = > abstract data types. All are already representable by Strings, and are = > all restricted subtypes of String. These make sense at first glance; = > however, on further reflection such would add a new error condition at = > the IPFIX Collecting Process side that would require protocol changes. > = > All the presently supported data types, save String, have the property = > that any sequence of bytes within the IE has a single valid decoding. = > This is trivially true for integer, address, and datetime types; IEEE = > 754 states that all byte sequences are either numbers or valid NaNs = > (with the caveat that positive and negative zero may require special = > handling, but this is to be handled at a layer above IPFIX.) Strings = > are encoded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while = > all byte sequences are not necessarily legal UTF-8, there are accepted = > methods for decoding or ignoring these illegal sequences (though these = > may themselves have security implications; see RFC 2279 section 6). We = > probably should have addressed this a bit more carefully in RFC 5101, = > but it's pretty clear that clarifying erroneous UTF-8 string decoding = > in exporting-type is _way_ out of scope. > = > This is not the case for URIs, or email addresses, or FQDNs. These = > "data types" are essentially encodings (UTF8 Strings) with a contract = > to keep the content conformant to some syntax. No other IPFIX data = > type has this property. Illegal UTF-8 sequences are corner cases; = > legal UTF-8 sequences that are not legal URIs comprise the majority of = > UTF-8 code space. What is a Collecting Process to do with such non- = > conformant byte sequences? What additional information does such a = > contract provide to the Collecting Process? > = > (Note that it is _precisely_ data type encoding complications such as = > this one that led us to restrict additions to the data type registry = > to standards actions.) > = > So, which scalar primitives are we missing? > = > Structured abstract data types and collection types a are another story, = > but they'll require protocol changes and new template mechanisms, so = > they're also way, way out of scope for exporting-type. > = >> So, with real respect to the work done and to its need, this draft = >> does not encourage the usage of standard IEs and the migration = >> towards standard IEs. > = > I disagree. The mechanism here encourages standardization and = > transition of provisional enterprise-specific information elements to = > the degree possible without changing the protocol or the nature of the = > information model itself. > = >> It should. Abstract data type IEs are really required in option = >> templates to describe abstract contexts not related per essence to a = >> flow nor to the direction of a flow. This is an urgently needed to = >> limit reasonably the number of proprietary IEs. > = > No particular disagreement here (though this proposal still seems to = > me to be an alternate, typed, unlabeled enterprise-specific IE = > mechanism with potentially serious multiple-IE interpretation issues, = > and I'm still not 100% clear what you want them for). But once more, = > this is _not_ in scope for a draft which specifies a only a mechanism = > for inline type information encoding. It's also not something you need = > an RFC for; the IE registry is appendable subject only to expert (at = > this point, Nevil) review. > = > Regards, > = > Brian > = >> Regards >> Emile >>> -----Message d'origine----- >>> De : Brian Trammell [mailto:bht@cert.org] >>> Envoy=E9 : lundi 14 avril 2008 20:44 >>> =C0 : STEPHAN Emile RD-CORE-LAN >>> Cc : dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi-eu.com >>> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >>> missing notes on exporting type...) >>> >>> Emile and all, >>> >>> Replies inline. >>> >>> Regards, >>> >>> Brian >>> >>> On Apr 14, 2008, at 10:03 AM, >>> >>> wrote: >>>> Hi Dan >>>> >>>> Sorry for de delay. >>>> >>>> Elisa said: >>>> >>>>> maybe the data model will have to be extended, but this would be >>>> an information model extension (i.e. an update of RFC5102) and I >>>> don't think it belongs >>>>> logically to a method description for exporting information model >>>> information on the wire. >>>>> Of course changes in the information model are likely to affect >>>> this document too... >>>> >>>> To make it short: >>>> We all agree that, without change, the RFC resulting of draft-ietf- >>>> ipfix-exporting-type will have to be updated each time a new >>>> datatype is defined. >>> No. This is not the case. The exporting-type RFC will not need to be >>> updated when data types are added to the protocol. The exporting-type >>> draft says nothing about the data types available in IPFIX (that's = >>> the >>> job of RFCs 5101/5102). It simply creates an IANA registry and >>> populates it with the data types and semantics already defined within >>> the protocol. It creates this registry solely so that datatypes can = >>> be >>> mapped to numbers for the representation of type information inline. >>> >>>> My understanding of the current practice inside IETF is that >>>> numbering must be registered by IANA when the datamodel allows the >>>> definition of new datatypes in the future. So, if my view is >>>> correct, the numbering of the datatypes of the IPFIX datamodel >>>> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be >>>> registered by IANA. >>> Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of >>> exporting-type. >>> >>> Note that, as the data type and semantics registries are defined to = >>> be >>> updated by an RFC 2434 Standards Action only, an additional RFC = >>> _will_ >>> be necessary to add data types to the IPFIX protocol, but this RFC >>> need not update the exporting-type RFC; nothing about new data types >>> will change how metainformation about those types will be represented >>> inline. >>> >>> We selected Standards Action from RFC 2434 as the update polre another story, = > but they'll require protocol changes and new template mechanisms, so = > they're also way, way out of scope for exporting-type. > = >> So, with real respect to the work done and to its need, this draft = >> does not encourage the usage of standard IEs and the migration = >> towards standard IEs. > = > I disagree. The mechanism here encourages standardization and = > transition of provisional enterprise-specific information elements to = > the degree possible without changing the protocol or the nature of the = > information model itself. > = >> It should. Abstract data type IEs are really required in option = >> templates to describe abstract contexts not related per essence to a = >> flow nor to the direction of a flow. This is an urgently needed to = >> limit reasonably the number of proprietary IEs. > = > No particular disagreement here (though this proposal still seems to = > me to be an alternate, typed, unlabeled enterprise-specific IE = > mechanism with potentially serious multiple-IE interpretation issues, = > and I'm still not 100% clear what you want them for). But once more, = > this is _not_ in scope for a draft which specifies a only a mechanism = > for inline type information encoding. It's also not something you need = > an RFC for; the IE registry is appendable subject only to expert (at = > this point, Nevil) review. > = > Regards, > = > Brian > = >> Regards >> Emile >>> -----Message d'origine----- >>> De : Brian Trammell [mailto:bht@cert.org] >>> Envoy=E9 : lundi 14 avril 2008 20:44 >>> =C0 : STEPHAN Emile RD-CORE-LAN >>> Cc : dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi-eu.com >>> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >>> missing notes on exporting type...) >>> >>> Emile and all, >>> >>> Replies inline. >>> >>> Regards, >>> >>> Brian >>> >>> On Apr 14, 2008, at 10:03 AM, >>> >>> wrote: >>>> Hi Dan >>>> >>>> Sorry for de delay. >>>> >>>> Elisa said: >>>> >>>>> maybe the data model will have to be extended, but this would be >>>> an information model extension (i.e. an update of RFC5102) and I >>>> don't think it belongs >>>>> logically to a method description for exporting information model >>>> information on the wire. >>>>> Of course changes in the information model are likely to affect >>>> this document too... >>>> >>>> To make it short: >>>> We all agree that, without change, the RFC resulting of draft-ietf- >>>> ipfix-exporting-type will have to be updated each time a new >>>> datatype is defined. >>> No. This is not the case. The exporting-type RFC will not need to be >>> updated when data types are added to the protocol. The exporting-type >>> draft says nothing about the data types available in IPFIX (that's = >>> the >>> job of RFCs 5101/5102). It simply creates an IANA registry and >>> populates it with the data types and semantics already defined within >>> the protocol. It creates this registry solely so that datatypes can = >>> be >>> mapped to numbers for the representation of type information inline. >>> >>>> My understanding of the current practice inside IETF is that >>>> numbering must be registered by IANA when the datamodel allows the >>>> definition of new datatypes in the future. So, if my view is >>>> correct, the numbering of the datatypes of the IPFIX datamodel >>>> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be >>>> registered by IANA. >>> Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of >>> exporting-type. >>> >>> Note that, as the data type and semantics registries are defined to = >>> be >>> updated by an RFC 2434 Standards Action only, an additional RFC = >>> _will_ >>> be necessary to add data types to the IPFIX protocol, but this RFC >>> need not update the exporting-type RFC; nothing about new data types >>> will change how metainformation about those types will be represented >>> inline. >>> >>> We selected Standards Action from RFC 2434 as the update policicy for >>> the created registries after discussion at one of the working group >>> meetings (Vancouver, I think, but I may be remembering incorrectly), >>> because there are potentially serious interoperability concerns = >>> raised >>> by adding new datatypes to the protocol, specifically in how >>> information of the new types is to be encoded on the wire. >>> >>>> Regards >>>> Emile >>>> >>>> >>>> De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] >>>> Envoy=E9 : jeudi 3 avril 2008 16:10 >>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> Cc : ipfix@ietf.org; bht@cert.org >>>> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >>>> missing notes on exporting type...) >>>> >>>> Emile, >>>> >>>>> There is not doubt that the datamodel have to be extended in short >>>> term. >>>>> 'enumerated' is the right example. It is missing in the datamodel >>>> and it >>>>> is a ground truth storage datatype. >>>>> >>>>> In the current approach, the adding of 'enumerated' as an abstract >>>>> datatype in the datamodel will require the update of >>>>> draft-ietf-ipfix-exporting-type because this draft defines a static >>>>> registry in the section "3.1. informationElementDataType". >>>>> >>>> maybe the data model will have to be extended, but this would be an >>>> information model extension (i.e. an update of RFC5102) and I don't >>>> think it belongs logically to a method description for exporting >>>> information model information on the wire. >>>> Of course changes in the information model are likely to affect this >>>> document too... >>>> >>>> >>>>> To avoid static pieces in the IPFIX datamodel in the future it is >>>>> mandatory to define an IPFIX IE for each abstract data types >>>> defined in >>>>> the IPFIX datamodel: >>>>> >>>>> octetArray >>>>> unsigned8 >>>>> unsigned16 >>>>> unsigned32 >>>>> unsigned64 >>>>> signed8 >>>>> signed16 >>>>> signed32 >>>>> signed64 >>>>> float32 >>>>> float64 >>>>> boolean >>>>> macAddress >>>>> string >>>>> dateTimeSeconds >>>>> dateTimeMilliseconds >>>>> dateTimeMicroseconds >>>>> dateTimeNanoseconds >>>>> ipv4Address >>>>> ipv6Address >>>>> >>>>> The WG has the opportunity to do that with draft-ietf-ipfix- >>>> exporting-type. >>>> I understand your concern, but I think that this is out of scope for >>>> this document. If the working group wants to add this flexibility I >>>> suggest opening a separate thread on this to discuss how this issue >>>> should be addressed. >>>> >>>> thanks, >>>> Elisa >>>> >>>>> Regards >>>>> >>>>> Emile >>>>> >>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>> prevents >>>>>>> adding new one in the future without updating the draft. There >>>> are >>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>> -----Message d'origine----- >>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>> Envoy=E9 : vendredi 28 mars 2008 22:57 >>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>> Cc : ipfix@ietf.org >>>>>> Objet : expanding type and semantics registries (was Re: missing >>>> notes on >>>>>> exporting type...) >>>>>> Emile, >>>>>> Ah, yes. Thanks. I remember now. My short, short answer on this >>>> was >>>>>> "no, but..." >>>>>> Here's why: >>>>>> The data type and semantics registries are taken directly from RFC >>>>>> 5102. This document doesn't seek to expand the types or >>>> semantics, it >>>>>> only seeks to create formal IANA registries for a list of types >>>>>> _already_ defined on the standards track. The reason behind >>>> creating >>>>>> those registries is to map the types themselves to numeric codes >>>> used >>>>>> to represent them in the informationElementDataType and >>>>>> informationElementSemantics IEs. The reason behind declaring their >>>>>> modification to be subject to a Standards Action as per RFC 2434 >>>> is to >>>>>> ensure that >>>>>> Adding a new data type to IPFIX is not simply a matter of >>>> sticking a >>>>>> new name and number into the data type registry -- specific >>>>>> informay for >>> the created registries after discussion at one of the working group >>> meetings (Vancouver, I think, but I may be remembering incorrectly), >>> because there are potentially serious interoperability concerns = >>> raised >>> by adding new datatypes to the protocol, specifically in how >>> information of the new types is to be encoded on the wire. >>> >>>> Regards >>>> Emile >>>> >>>> >>>> De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] >>>> Envoy=E9 : jeudi 3 avril 2008 16:10 >>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> Cc : ipfix@ietf.org; bht@cert.org >>>> Objet : Re: [IPFIX] expanding type and semantics registries (was Re: >>>> missing notes on exporting type...) >>>> >>>> Emile, >>>> >>>>> There is not doubt that the datamodel have to be extended in short >>>> term. >>>>> 'enumerated' is the right example. It is missing in the datamodel >>>> and it >>>>> is a ground truth storage datatype. >>>>> >>>>> In the current approach, the adding of 'enumerated' as an abstract >>>>> datatype in the datamodel will require the update of >>>>> draft-ietf-ipfix-exporting-type because this draft defines a static >>>>> registry in the section "3.1. informationElementDataType". >>>>> >>>> maybe the data model will have to be extended, but this would be an >>>> information model extension (i.e. an update of RFC5102) and I don't >>>> think it belongs logically to a method description for exporting >>>> information model information on the wire. >>>> Of course changes in the information model are likely to affect this >>>> document too... >>>> >>>> >>>>> To avoid static pieces in the IPFIX datamodel in the future it is >>>>> mandatory to define an IPFIX IE for each abstract data types >>>> defined in >>>>> the IPFIX datamodel: >>>>> >>>>> octetArray >>>>> unsigned8 >>>>> unsigned16 >>>>> unsigned32 >>>>> unsigned64 >>>>> signed8 >>>>> signed16 >>>>> signed32 >>>>> signed64 >>>>> float32 >>>>> float64 >>>>> boolean >>>>> macAddress >>>>> string >>>>> dateTimeSeconds >>>>> dateTimeMilliseconds >>>>> dateTimeMicroseconds >>>>> dateTimeNanoseconds >>>>> ipv4Address >>>>> ipv6Address >>>>> >>>>> The WG has the opportunity to do that with draft-ietf-ipfix- >>>> exporting-type. >>>> I understand your concern, but I think that this is out of scope for >>>> this document. If the working group wants to add this flexibility I >>>> suggest opening a separate thread on this to discuss how this issue >>>> should be addressed. >>>> >>>> thanks, >>>> Elisa >>>> >>>>> Regards >>>>> >>>>> Emile >>>>> >>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>> prevents >>>>>>> adding new one in the future without updating the draft. There >>>> are >>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>> -----Message d'origine----- >>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>> Envoy=E9 : vendredi 28 mars 2008 22:57 >>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>> Cc : ipfix@ietf.org >>>>>> Objet : expanding type and semantics registries (was Re: missing >>>> notes on >>>>>> exporting type...) >>>>>> Emile, >>>>>> Ah, yes. Thanks. I remember now. My short, short answer on this >>>> was >>>>>> "no, but..." >>>>>> Here's why: >>>>>> The data type and semantics registries are taken directly from RFC >>>>>> 5102. This document doesn't seek to expand the types or >>>> semantics, it >>>>>> only seeks to create formal IANA registries for a list of types >>>>>> _already_ defined on the standards track. The reason behind >>>> creating >>>>>> those registries is to map the types themselves to numeric codes >>>> used >>>>>> to represent them in the informationElementDataType and >>>>>> informationElementSemantics IEs. The reason behind declaring their >>>>>> modification to be subject to a Standards Action as per RFC 2434 >>>> is to >>>>>> ensure that >>>>>> Adding a new data type to IPFIX is not simply a matter of >>>> sticking a >>>>>> new name and number into the data type registry -- specific >>>>>> informatition on the definition (as in section 3.1 of RFC 5102) and >>>>>> encoding (as in section 6.1 of RFC 5101) of the data type must be >>>>>> provided to allow the Exporting Process to properly encode and the >>>>>> Collecting Process to properly decode and recognize data of that >>>> type. >>>>>> Even if it's just a reference to an external standard (as 5101's >>>>>> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point >>>> types), >>>>>> it's still absolutely necessary to have some document extending >>>> the >>>>>> set of types for IPFIX to ensure interoperability of those new >>>> types. >>>>>> And that's out of scope for _this_ document, which, as >>>> chartered, only >>>>>> provides a _mechanism_ for describing the types already supported. >>>>>> That said, you have a very good point. >>>>>> There are quite a few types that could be immediately useful; >>>> and yes, >>>>>> additional network-identifiers such as URL, email, and FQDN are >>>>>> obvious first choices, which can only be implemented as Strings >>>> at the >>>>>> moment. Enumerations are another issue, and can already be >>>> partially >>>>>> implemented using the Reducing Redundancy mechanism. >>>>>> My suggestion, however, would be a new document, to be >>>> considered for >>>>>> a future WG charter, to _explicitly_ extend the set of types >>>> supported >>>>>> by IPFIX, and adding those types to the registry created in >>>> exporting- >>>>>> type. >>>>>> Cheers, >>>>>> Brian >>>>>> On Mar 28, 2008, at 2:20 PM, >>>> wrote: >>>>>>> Hi Brian, >>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>> prevents >>>>>>> adding new one in the future without updating the draft. There >>>> are >>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>>> Adding these types to the IPFIX datamodel increases the scope of >>>>>>> usage of IPFIX and interoperability. It permits the usage of >>>>>>> standard IE for exporting specific information. It permits the >>>>>>> collector to store this information in an efficient way. It >>>>>>> encourage enterprises to use standard IE instead of enterprises >>>>>>> specific ones. >>>>>>> Therefore the draft has to define them as IEs and the IANA >>>> section >>>>>>> have to request IANA to add them the IPFIX datamodel registry. >>>>>>> Regards >>>>>>> Emile >>>>>>>> -----Message d'origine----- >>>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>>>> Envoy=E9 : vendredi 28 mars 2008 02:11 >>>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>>>> Objet : missing notes on exporting type... >>>>>>>> Emile, >>>>>>>> As I recall, we had a conversation in Philadelphia about some >>>>>>> specific >>>>>>>> aspect of draft-ietf-ipfix-exporting-type, and I had an >>>> answer for >>>>>>>> your question, and I was going to post a message to the list >>>> about >>>>>>>> that... but, I can't seem to find my note on the subject, >>>> and it's >>>>>>>> been a rather eventful couple of weeks, and I have >>>> consequently >>>>>>>> _completely_ forgotten it. >>>>>>>> So. >>>>>>>> Would you happen to remember what we were talking about, so >>>> we could >>>>>>>> perhaps start over on the subject? >>>>>>>> Thanks, >>>>>>>> Brian >>>> >>>> >>>> >>> ***********************************************************************= *** >>> ************************ >>>> E-mail Confidentiality Notice and Disclaimer. >>>> >>>> This e-mail and any files transmitted with it are confidential and >>>> are intended solely for the use of the individual or entity to which >>>> they are addressed. Access to this e-mail by anyone else is >>>> unauthorised. If you are not the intended recipient, any disclosure, >>>> copying, distribution or any action taken or omitted to be taken in >>>> reliance on it, is prohibited. >>>> E-mail messages are not necessarily secure. >>>> Hitachi does not accept responsibility for any changes made to this >>>> message after it was sent. >>>> Hitachi checks outgoing e-mail messages for the presence of computer >>>> viruses. >>>> >>> *********************************************on on the definition (as in section 3.1 of RFC 5102) and >>>>>> encoding (as in section 6.1 of RFC 5101) of the data type must be >>>>>> provided to allow the Exporting Process to properly encode and the >>>>>> Collecting Process to properly decode and recognize data of that >>>> type. >>>>>> Even if it's just a reference to an external standard (as 5101's >>>>>> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point >>>> types), >>>>>> it's still absolutely necessary to have some document extending >>>> the >>>>>> set of types for IPFIX to ensure interoperability of those new >>>> types. >>>>>> And that's out of scope for _this_ document, which, as >>>> chartered, only >>>>>> provides a _mechanism_ for describing the types already supported. >>>>>> That said, you have a very good point. >>>>>> There are quite a few types that could be immediately useful; >>>> and yes, >>>>>> additional network-identifiers such as URL, email, and FQDN are >>>>>> obvious first choices, which can only be implemented as Strings >>>> at the >>>>>> moment. Enumerations are another issue, and can already be >>>> partially >>>>>> implemented using the Reducing Redundancy mechanism. >>>>>> My suggestion, however, would be a new document, to be >>>> considered for >>>>>> a future WG charter, to _explicitly_ extend the set of types >>>> supported >>>>>> by IPFIX, and adding those types to the registry created in >>>> exporting- >>>>>> type. >>>>>> Cheers, >>>>>> Brian >>>>>> On Mar 28, 2008, at 2:20 PM, >>>> wrote: >>>>>>> Hi Brian, >>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>> prevents >>>>>>> adding new one in the future without updating the draft. There >>>> are >>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>>> Adding these types to the IPFIX datamodel increases the scope of >>>>>>> usage of IPFIX and interoperability. It permits the usage of >>>>>>> standard IE for exporting specific information. It permits the >>>>>>> collector to store this information in an efficient way. It >>>>>>> encourage enterprises to use standard IE instead of enterprises >>>>>>> specific ones. >>>>>>> Therefore the draft has to define them as IEs and the IANA >>>> section >>>>>>> have to request IANA to add them the IPFIX datamodel registry. >>>>>>> Regards >>>>>>> Emile >>>>>>>> -----Message d'origine----- >>>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>>>> Envoy=E9 : vendredi 28 mars 2008 02:11 >>>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>>>> Objet : missing notes on exporting type... >>>>>>>> Emile, >>>>>>>> As I recall, we had a conversation in Philadelphia about some >>>>>>> specific >>>>>>>> aspect of draft-ietf-ipfix-exporting-type, and I had an >>>> answer for >>>>>>>> your question, and I was going to post a message to the list >>>> about >>>>>>>> that... but, I can't seem to find my note on the subject, >>>> and it's >>>>>>>> been a rather eventful couple of weeks, and I have >>>> consequently >>>>>>>> _completely_ forgotten it. >>>>>>>> So. >>>>>>>> Would you happen to remember what we were talking about, so >>>> we could >>>>>>>> perhaps start over on the subject? >>>>>>>> Thanks, >>>>>>>> Brian >>>> >>>> >>>> >>> ***********************************************************************= *** >>> ************************ >>>> E-mail Confidentiality Notice and Disclaimer. >>>> >>>> This e-mail and any files transmitted with it are confidential and >>>> are intended solely for the use of the individual or entity to which >>>> they are addressed. Access to this e-mail by anyone else is >>>> unauthorised. If you are not the intended recipient, any disclosure, >>>> copying, distribution or any action taken or omitted to be taken in >>>> reliance on it, is prohibited. >>>> E-mail messages are not necessarily secure. >>>> Hitachi does not accept responsibility for any changes made to this >>>> message after it was sent. >>>> Hitachi checks outgoing e-mail messages for the presence of computer >>>> viruses. >>>> >>> ***********************************************************************= *** >>> ************************ > = > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- = Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ 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 -- = Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Apr 17 08:47:26 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29C128C3E4; Thu, 17 Apr 2008 08:47:26 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8087228C51D for ; Thu, 17 Apr 2008 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neVK+mWKURbJ for ; Thu, 17 Apr 2008 08:47:23 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id 874BF28C3E4 for ; Thu, 17 Apr 2008 08:47:16 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m3HFlpvj009607 for ; Thu, 17 Apr 2008 11:47:51 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m3HFlVT5009566 for ; Thu, 17 Apr 2008 11:47:31 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m3HFlU5I009564; Thu, 17 Apr 2008 11:47:31 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m3HFlUf9000927; Thu, 17 Apr 2008 11:47:30 -0400 Message-Id: <21B9D822-4F69-4E05-ACE3-DB9904E790F9@cert.org> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <48071369.4050404@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 17 Apr 2008 11:47:29 -0400 References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Hmm, interesting... you're right, of course, that the restricted = String "types" (email, url, etc..) are _semantics_ (hadn't thought of = that, actually; I was considering only types and their encoding in = this discussion so far)... And yes, new semantics, like new types, are not in scope for this = draft. They probably _should_ be addressed in a new individual draft = for consideration for adoption as a WG standards-track item for a = subsequent charter; exporting-type _does_ provide guidelines such a = draft should follow for noting which semantics are valid for which = types (section 3.10, paragraph 3 in -01), but that, I think, is the = proper extent of exporting-typeFrom ipfix-bounces@ietf.org Thu Apr 17 08:47:26 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29C128C3E4; Thu, 17 Apr 2008 08:47:26 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8087228C51D for ; Thu, 17 Apr 2008 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neVK+mWKURbJ for ; Thu, 17 Apr 2008 08:47:23 -0700 (PDT) Received: from elf.red.cert.org (elf.red.cert.org [192.88.209.26]) by core3.amsl.com (Postfix) with ESMTP id 874BF28C3E4 for ; Thu, 17 Apr 2008 08:47:16 -0700 (PDT) Received: from elf.red.cert.org (localhost [127.0.0.1]) by elf.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id m3HFlpvj009607 for ; Thu, 17 Apr 2008 11:47:51 -0400 Received: (from defang@localhost) by elf.red.cert.org (8.13.1/8.13.1/Submit/1.1) id m3HFlVT5009566 for ; Thu, 17 Apr 2008 11:47:31 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by elf.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id m3HFlU5I009564; Thu, 17 Apr 2008 11:47:31 -0400 (EDT) Received: from THALEIA.WV.CC.CMU.EDU (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.70) with ESMTP id m3HFlUf9000927; Thu, 17 Apr 2008 11:47:30 -0400 Message-Id: <21B9D822-4F69-4E05-ACE3-DB9904E790F9@cert.org> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <48071369.4050404@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 17 Apr 2008 11:47:29 -0400 References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> X-Mailer: Apple Mail (2.919.2) Cc: ipfix@ietf.org Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Hmm, interesting... you're right, of course, that the restricted = String "types" (email, url, etc..) are _semantics_ (hadn't thought of = that, actually; I was considering only types and their encoding in = this discussion so far)... And yes, new semantics, like new types, are not in scope for this = draft. They probably _should_ be addressed in a new individual draft = for consideration for adoption as a WG standards-track item for a = subsequent charter; exporting-type _does_ provide guidelines such a = draft should follow for noting which semantics are valid for which = types (section 3.10, paragraph 3 in -01), but that, I think, is the = proper extent of exporting-ty's involvement in adding semantics. Cheers, Brian On Apr 17, 2008, at 5:07 AM, Gerhard Muenz wrote: > > Hi all, > > I just want to say that Brian's rationales sound valid to me. > > As done in RFC 5102, we need to distinguish between Abstract Data = > Types, > Data Type Semantics, and IEs. > > The purpose of the draft is to explain/define enterprise-specific = > IEs by > their Abstract Data Type and their Data Type Semantic, plus a > human-readable description, information about the unit, and range of > valid values. > > The draft is not about defining new Abstract Data Types or Data Type > Semantics. And I do not think it should be; otherwise, you would = > have to > explain the en/decoding to the collector, which can be very = > complicated. > > With respect to the new types raised in the discussion, I currently do > not see the need to add new Abstract Data Types. As Brian said, an URL > can be encoded as a string. An enumeration can be encoded as an = > integer. > Only if someone found a much more efficient way to encode this kind of > information, it would be worth defining a new abstract data type. > > However, new Data Type Semantics like "enumeration" or "url" might be > useful. Yet, as said above, this draft is not about new Data Type > Semantics. > > Regards, > Gerhard > > > Brian Trammell wrote: >> Emile, >> >> Replies inline... >> >> On Apr 16, 2008, at 10:42 AM, >> wrote: >>> >>> Hi Brain, >>> >>> Thanks for the explanation. This framework limit's is reached when >>> an enterprise has to export the type of an IE which abstract data >>> type is not defined in the datamodel of the RFC5102. So the registry >>> of the section 3 must not be limited to the exiting abstract data >>> types. It must include any existing database datatypes to reach, at >>> least, the initial goal of storing efficiently any proprietary IEs. >>> >>> Otherwise, for sure, enterprises will 'complete' the table of >>> section 3.1 with their own abstract datatypes and tags. Then >>> collectors will have to get these values (using their cristal ball) >>> and to hardcode these values in a multidimensional table, then, >>> later, the IPFIX WG will have to specify some solution to export >>> proprietary abstract data types... >> >> Enterprises can't "complete" the data type table without a standards >> action -- this is the point of restricting additions to that registry >> as exporting-type does currently. Without this, the best an = >> enterprise >> can do for a new data type encoding is to represent it as an octet- >> array -- which is precisely as good as it can do without exporting- >> type. So, no loss here. >> >> That said, I think we have different ideas as to what comprises a >> "data type". >> >> The core data types supported by 5101/5102 are the basic primitive >> scalar types supported by most reasonably modern programming >> languages, plus specific subtypes of ordered octet arrays or special >> integer encodings corresponding to packet header (link-layer and >> network address) field types and collection infrastructure = >> (timestamp) >> field types. It is unclear which scalar primitives we're missing. >> >> You pointed out email addresses, FQDNs, and URIs as candidates for = >> new >> abstract data types. All are already representable by Strings, and = >> are >> all restricted subtypes of String. These make sense at first glance; >> however, on further reflection such would add a new error condition = >> at >> the IPFIX Collecting Process side that would require protocol = >> changes. >> >> All the presently supported data types, save String, have the = >> property >> that any sequence of bytes within the IE has a single valid decoding. >> This is trivially true for integer, address, and datetime types; IEEE >> 754 states that all byte sequences are either numbers or valid NaNs >> (with the caveat that positive and negative zero may require special >> handling, but this is to be handled at a layer above IPFIX.) Strings >> are encodepe's involvement in adding semantics. Cheers, Brian On Apr 17, 2008, at 5:07 AM, Gerhard Muenz wrote: > > Hi all, > > I just want to say that Brian's rationales sound valid to me. > > As done in RFC 5102, we need to distinguish between Abstract Data = > Types, > Data Type Semantics, and IEs. > > The purpose of the draft is to explain/define enterprise-specific = > IEs by > their Abstract Data Type and their Data Type Semantic, plus a > human-readable description, information about the unit, and range of > valid values. > > The draft is not about defining new Abstract Data Types or Data Type > Semantics. And I do not think it should be; otherwise, you would = > have to > explain the en/decoding to the collector, which can be very = > complicated. > > With respect to the new types raised in the discussion, I currently do > not see the need to add new Abstract Data Types. As Brian said, an URL > can be encoded as a string. An enumeration can be encoded as an = > integer. > Only if someone found a much more efficient way to encode this kind of > information, it would be worth defining a new abstract data type. > > However, new Data Type Semantics like "enumeration" or "url" might be > useful. Yet, as said above, this draft is not about new Data Type > Semantics. > > Regards, > Gerhard > > > Brian Trammell wrote: >> Emile, >> >> Replies inline... >> >> On Apr 16, 2008, at 10:42 AM, >> wrote: >>> >>> Hi Brain, >>> >>> Thanks for the explanation. This framework limit's is reached when >>> an enterprise has to export the type of an IE which abstract data >>> type is not defined in the datamodel of the RFC5102. So the registry >>> of the section 3 must not be limited to the exiting abstract data >>> types. It must include any existing database datatypes to reach, at >>> least, the initial goal of storing efficiently any proprietary IEs. >>> >>> Otherwise, for sure, enterprises will 'complete' the table of >>> section 3.1 with their own abstract datatypes and tags. Then >>> collectors will have to get these values (using their cristal ball) >>> and to hardcode these values in a multidimensional table, then, >>> later, the IPFIX WG will have to specify some solution to export >>> proprietary abstract data types... >> >> Enterprises can't "complete" the data type table without a standards >> action -- this is the point of restricting additions to that registry >> as exporting-type does currently. Without this, the best an = >> enterprise >> can do for a new data type encoding is to represent it as an octet- >> array -- which is precisely as good as it can do without exporting- >> type. So, no loss here. >> >> That said, I think we have different ideas as to what comprises a >> "data type". >> >> The core data types supported by 5101/5102 are the basic primitive >> scalar types supported by most reasonably modern programming >> languages, plus specific subtypes of ordered octet arrays or special >> integer encodings corresponding to packet header (link-layer and >> network address) field types and collection infrastructure = >> (timestamp) >> field types. It is unclear which scalar primitives we're missing. >> >> You pointed out email addresses, FQDNs, and URIs as candidates for = >> new >> abstract data types. All are already representable by Strings, and = >> are >> all restricted subtypes of String. These make sense at first glance; >> however, on further reflection such would add a new error condition = >> at >> the IPFIX Collecting Process side that would require protocol = >> changes. >> >> All the presently supported data types, save String, have the = >> property >> that any sequence of bytes within the IE has a single valid decoding. >> This is trivially true for integer, address, and datetime types; IEEE >> 754 states that all byte sequences are either numbers or valid NaNs >> (with the caveat that positive and negative zero may require special >> handling, but this is to be handled at a layer above IPFIX.) Strings >> are encod in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while >> all byte sequences are not necessarily legal UTF-8, there are = >> accepted >> methods for decoding or ignoring these illegal sequences (though = >> these >> may themselves have security implications; see RFC 2279 section 6). = >> We >> probably should have addressed this a bit more carefully in RFC 5101, >> but it's pretty clear that clarifying erroneous UTF-8 string decoding >> in exporting-type is _way_ out of scope. >> >> This is not the case for URIs, or email addresses, or FQDNs. These >> "data types" are essentially encodings (UTF8 Strings) with a contract >> to keep the content conformant to some syntax. No other IPFIX data >> type has this property. Illegal UTF-8 sequences are corner cases; >> legal UTF-8 sequences that are not legal URIs comprise the majority = >> of >> UTF-8 code space. What is a Collecting Process to do with such non- >> conformant byte sequences? What additional information does such a >> contract provide to the Collecting Process? >> >> (Note that it is _precisely_ data type encoding complications such as >> this one that led us to restrict additions to the data type registry >> to standards actions.) >> >> So, which scalar primitives are we missing? >> >> Structured abstract data types and collection types are another = >> story, >> but they'll require protocol changes and new template mechanisms, so >> they're also way, way out of scope for exporting-type. >> >>> So, with real respect to the work done and to its need, this draft >>> does not encourage the usage of standard IEs and the migration >>> towards standard IEs. >> >> I disagree. The mechanism here encourages standardization and >> transition of provisional enterprise-specific information elements to >> the degree possible without changing the protocol or the nature of = >> the >> information model itself. >> >>> It should. Abstract data type IEs are really required in option >>> templates to describe abstract contexts not related per essence to a >>> flow nor to the direction of a flow. This is an urgently needed to >>> limit reasonably the number of proprietary IEs. >> >> No particular disagreement here (though this proposal still seems to >> me to be an alternate, typed, unlabeled enterprise-specific IE >> mechanism with potentially serious multiple-IE interpretation issues, >> and I'm still not 100% clear what you want them for). But once more, >> this is _not_ in scope for a draft which specifies a only a mechanism >> for inline type information encoding. It's also not something you = >> need >> an RFC for; the IE registry is appendable subject only to expert (at >> this point, Nevil) review. >> >> Regards, >> >> Brian >> >>> Regards >>> Emile >>>> -----Message d'origine----- >>>> De : Brian Trammell [mailto:bht@cert.org] >>>> Envoy=E9 : lundi 14 avril 2008 20:44 >>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> Cc : dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi- = >>>> eu.com >>>> Objet : Re: [IPFIX] expanding type and semantics registries (was = >>>> Re: >>>> missing notes on exporting type...) >>>> >>>> Emile and all, >>>> >>>> Replies inline. >>>> >>>> Regards, >>>> >>>> Brian >>>> >>>> On Apr 14, 2008, at 10:03 AM, >>>> >>>> wrote: >>>>> Hi Dan >>>>> >>>>> Sorry for de delay. >>>>> >>>>> Elisa said: >>>>> >>>>>> maybe the data model will have to be extended, but this would be >>>>> an information model extension (i.e. an update of RFC5102) and I >>>>> don't think it belongs >>>>>> logically to a method description for exporting information model >>>>> information on the wire. >>>>>> Of course changes in the information model are likely to affect >>>>> this document too... >>>>> >>>>> To make it short: >>>>> We all agree that, without change, the RFC resulting of draft- = >>>>> ietf- >>>>> ipfix-exporting-type will have to be updated each time a new >>>>> datatype is defined. >>>> No. This is not the case. The exporting-type RFC will not need to = >>>> be >>>> updated wded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while >> all byte sequences are not necessarily legal UTF-8, there are = >> accepted >> methods for decoding or ignoring these illegal sequences (though = >> these >> may themselves have security implications; see RFC 2279 section 6). = >> We >> probably should have addressed this a bit more carefully in RFC 5101, >> but it's pretty clear that clarifying erroneous UTF-8 string decoding >> in exporting-type is _way_ out of scope. >> >> This is not the case for URIs, or email addresses, or FQDNs. These >> "data types" are essentially encodings (UTF8 Strings) with a contract >> to keep the content conformant to some syntax. No other IPFIX data >> type has this property. Illegal UTF-8 sequences are corner cases; >> legal UTF-8 sequences that are not legal URIs comprise the majority = >> of >> UTF-8 code space. What is a Collecting Process to do with such non- >> conformant byte sequences? What additional information does such a >> contract provide to the Collecting Process? >> >> (Note that it is _precisely_ data type encoding complications such as >> this one that led us to restrict additions to the data type registry >> to standards actions.) >> >> So, which scalar primitives are we missing? >> >> Structured abstract data types and collection types are another = >> story, >> but they'll require protocol changes and new template mechanisms, so >> they're also way, way out of scope for exporting-type. >> >>> So, with real respect to the work done and to its need, this draft >>> does not encourage the usage of standard IEs and the migration >>> towards standard IEs. >> >> I disagree. The mechanism here encourages standardization and >> transition of provisional enterprise-specific information elements to >> the degree possible without changing the protocol or the nature of = >> the >> information model itself. >> >>> It should. Abstract data type IEs are really required in option >>> templates to describe abstract contexts not related per essence to a >>> flow nor to the direction of a flow. This is an urgently needed to >>> limit reasonably the number of proprietary IEs. >> >> No particular disagreement here (though this proposal still seems to >> me to be an alternate, typed, unlabeled enterprise-specific IE >> mechanism with potentially serious multiple-IE interpretation issues, >> and I'm still not 100% clear what you want them for). But once more, >> this is _not_ in scope for a draft which specifies a only a mechanism >> for inline type information encoding. It's also not something you = >> need >> an RFC for; the IE registry is appendable subject only to expert (at >> this point, Nevil) review. >> >> Regards, >> >> Brian >> >>> Regards >>> Emile >>>> -----Message d'origine----- >>>> De : Brian Trammell [mailto:bht@cert.org] >>>> Envoy=E9 : lundi 14 avril 2008 20:44 >>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>> Cc : dromasca@avaya.com; ipfix@ietf.org; Elisa.Boschi@Hitachi- = >>>> eu.com >>>> Objet : Re: [IPFIX] expanding type and semantics registries (was = >>>> Re: >>>> missing notes on exporting type...) >>>> >>>> Emile and all, >>>> >>>> Replies inline. >>>> >>>> Regards, >>>> >>>> Brian >>>> >>>> On Apr 14, 2008, at 10:03 AM, >>>> >>>> wrote: >>>>> Hi Dan >>>>> >>>>> Sorry for de delay. >>>>> >>>>> Elisa said: >>>>> >>>>>> maybe the data model will have to be extended, but this would be >>>>> an information model extension (i.e. an update of RFC5102) and I >>>>> don't think it belongs >>>>>> logically to a method description for exporting information model >>>>> information on the wire. >>>>>> Of course changes in the information model are likely to affect >>>>> this document too... >>>>> >>>>> To make it short: >>>>> We all agree that, without change, the RFC resulting of draft- = >>>>> ietf- >>>>> ipfix-exporting-type will have to be updated each time a new >>>>> datatype is defined. >>>> No. This is not the case. The exporting-type RFC will not need to = >>>> be >>>> updatedhen data types are added to the protocol. The exporting- = >>>> type >>>> draft says nothing about the data types available in IPFIX (that's >>>> the >>>> job of RFCs 5101/5102). It simply creates an IANA registry and >>>> populates it with the data types and semantics already defined = >>>> within >>>> the protocol. It creates this registry solely so that datatypes can >>>> be >>>> mapped to numbers for the representation of type information = >>>> inline. >>>> >>>>> My understanding of the current practice inside IETF is that >>>>> numbering must be registered by IANA when the datamodel allows the >>>>> definition of new datatypes in the future. So, if my view is >>>>> correct, the numbering of the datatypes of the IPFIX datamodel >>>>> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be >>>>> registered by IANA. >>>> Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of >>>> exporting-type. >>>> >>>> Note that, as the data type and semantics registries are defined to >>>> be >>>> updated by an RFC 2434 Standards Action only, an additional RFC >>>> _will_ >>>> be necessary to add data types to the IPFIX protocol, but this RFC >>>> need not update the exporting-type RFC; nothing about new data = >>>> types >>>> will change how metainformation about those types will be = >>>> represented >>>> inline. >>>> >>>> We selected Standards Action from RFC 2434 as the update policy for >>>> the created registries after discussion at one of the working group >>>> meetings (Vancouver, I think, but I may be remembering = >>>> incorrectly), >>>> because there are potentially serious interoperability concerns >>>> raised >>>> by adding new datatypes to the protocol, specifically in how >>>> information of the new types is to be encoded on the wire. >>>> >>>>> Regards >>>>> Emile >>>>> >>>>> >>>>> De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] >>>>> Envoy=E9 : jeudi 3 avril 2008 16:10 >>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>> Cc : ipfix@ietf.org; bht@cert.org >>>>> Objet : Re: [IPFIX] expanding type and semantics registries (was = >>>>> Re: >>>>> missing notes on exporting type...) >>>>> >>>>> Emile, >>>>> >>>>>> There is not doubt that the datamodel have to be extended in = >>>>>> short >>>>> term. >>>>>> 'enumerated' is the right example. It is missing in the datamodel >>>>> and it >>>>>> is a ground truth storage datatype. >>>>>> >>>>>> In the current approach, the adding of 'enumerated' as an = >>>>>> abstract >>>>>> datatype in the datamodel will require the update of >>>>>> draft-ietf-ipfix-exporting-type because this draft defines a = >>>>>> static >>>>>> registry in the section "3.1. informationElementDataType". >>>>>> >>>>> maybe the data model will have to be extended, but this would be = >>>>> an >>>>> information model extension (i.e. an update of RFC5102) and I = >>>>> don't >>>>> think it belongs logically to a method description for exporting >>>>> information model information on the wire. >>>>> Of course changes in the information model are likely to affect = >>>>> this >>>>> document too... >>>>> >>>>> >>>>>> To avoid static pieces in the IPFIX datamodel in the future it is >>>>>> mandatory to define an IPFIX IE for each abstract data types >>>>> defined in >>>>>> the IPFIX datamodel: >>>>>> >>>>>> octetArray >>>>>> unsigned8 >>>>>> unsigned16 >>>>>> unsigned32 >>>>>> unsigned64 >>>>>> signed8 >>>>>> signed16 >>>>>> signed32 >>>>>> signed64 >>>>>> float32 >>>>>> float64 >>>>>> boolean >>>>>> macAddress >>>>>> string >>>>>> dateTimeSeconds >>>>>> dateTimeMilliseconds >>>>>> dateTimeMicroseconds >>>>>> dateTimeNanoseconds >>>>>> ipv4Address >>>>>> ipv6Address >>>>>> >>>>>> The WG has the opportunity to do that with draft-ietf-ipfix- >>>>> exporting-type. >>>>> I understand your concern, but I think that this is out of scope = >>>>> for >>>>> this document. If the working group wants to add this = >>>>> flexibility I >>>>> suggest opening a separate thread on this to discuss how t when data types are added to the protocol. The exporting- = >>>> type >>>> draft says nothing about the data types available in IPFIX (that's >>>> the >>>> job of RFCs 5101/5102). It simply creates an IANA registry and >>>> populates it with the data types and semantics already defined = >>>> within >>>> the protocol. It creates this registry solely so that datatypes can >>>> be >>>> mapped to numbers for the representation of type information = >>>> inline. >>>> >>>>> My understanding of the current practice inside IETF is that >>>>> numbering must be registered by IANA when the datamodel allows the >>>>> definition of new datatypes in the future. So, if my view is >>>>> correct, the numbering of the datatypes of the IPFIX datamodel >>>>> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be >>>>> registered by IANA. >>>> Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of >>>> exporting-type. >>>> >>>> Note that, as the data type and semantics registries are defined to >>>> be >>>> updated by an RFC 2434 Standards Action only, an additional RFC >>>> _will_ >>>> be necessary to add data types to the IPFIX protocol, but this RFC >>>> need not update the exporting-type RFC; nothing about new data = >>>> types >>>> will change how metainformation about those types will be = >>>> represented >>>> inline. >>>> >>>> We selected Standards Action from RFC 2434 as the update policy for >>>> the created registries after discussion at one of the working group >>>> meetings (Vancouver, I think, but I may be remembering = >>>> incorrectly), >>>> because there are potentially serious interoperability concerns >>>> raised >>>> by adding new datatypes to the protocol, specifically in how >>>> information of the new types is to be encoded on the wire. >>>> >>>>> Regards >>>>> Emile >>>>> >>>>> >>>>> De : Boschi, Elisa [mailto:Elisa.Boschi@Hitachi-eu.com] >>>>> Envoy=E9 : jeudi 3 avril 2008 16:10 >>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>> Cc : ipfix@ietf.org; bht@cert.org >>>>> Objet : Re: [IPFIX] expanding type and semantics registries (was = >>>>> Re: >>>>> missing notes on exporting type...) >>>>> >>>>> Emile, >>>>> >>>>>> There is not doubt that the datamodel have to be extended in = >>>>>> short >>>>> term. >>>>>> 'enumerated' is the right example. It is missing in the datamodel >>>>> and it >>>>>> is a ground truth storage datatype. >>>>>> >>>>>> In the current approach, the adding of 'enumerated' as an = >>>>>> abstract >>>>>> datatype in the datamodel will require the update of >>>>>> draft-ietf-ipfix-exporting-type because this draft defines a = >>>>>> static >>>>>> registry in the section "3.1. informationElementDataType". >>>>>> >>>>> maybe the data model will have to be extended, but this would be = >>>>> an >>>>> information model extension (i.e. an update of RFC5102) and I = >>>>> don't >>>>> think it belongs logically to a method description for exporting >>>>> information model information on the wire. >>>>> Of course changes in the information model are likely to affect = >>>>> this >>>>> document too... >>>>> >>>>> >>>>>> To avoid static pieces in the IPFIX datamodel in the future it is >>>>>> mandatory to define an IPFIX IE for each abstract data types >>>>> defined in >>>>>> the IPFIX datamodel: >>>>>> >>>>>> octetArray >>>>>> unsigned8 >>>>>> unsigned16 >>>>>> unsigned32 >>>>>> unsigned64 >>>>>> signed8 >>>>>> signed16 >>>>>> signed32 >>>>>> signed64 >>>>>> float32 >>>>>> float64 >>>>>> boolean >>>>>> macAddress >>>>>> string >>>>>> dateTimeSeconds >>>>>> dateTimeMilliseconds >>>>>> dateTimeMicroseconds >>>>>> dateTimeNanoseconds >>>>>> ipv4Address >>>>>> ipv6Address >>>>>> >>>>>> The WG has the opportunity to do that with draft-ietf-ipfix- >>>>> exporting-type. >>>>> I understand your concern, but I think that this is out of scope = >>>>> for >>>>> this document. If the working group wants to add this = >>>>> flexibility I >>>>> suggest opening a separate thread on this to discuss howhis = >>>>> issue >>>>> should be addressed. >>>>> >>>>> thanks, >>>>> Elisa >>>>> >>>>>> Regards >>>>>> >>>>>> Emile >>>>>> >>>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>>> prevents >>>>>>>> adding new one in the future without updating the draft. There >>>>> are >>>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>>> -----Message d'origine----- >>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>>> Envoy=E9 : vendredi 28 mars 2008 22:57 >>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>>> Cc : ipfix@ietf.org >>>>>>> Objet : expanding type and semantics registries (was Re: missing >>>>> notes on >>>>>>> exporting type...) >>>>>>> Emile, >>>>>>> Ah, yes. Thanks. I remember now. My short, short answer on this >>>>> was >>>>>>> "no, but..." >>>>>>> Here's why: >>>>>>> The data type and semantics registries are taken directly from = >>>>>>> RFC >>>>>>> 5102. This document doesn't seek to expand the types or >>>>> semantics, it >>>>>>> only seeks to create formal IANA registries for a list of types >>>>>>> _already_ defined on the standards track. The reason behind >>>>> creating >>>>>>> those registries is to map the types themselves to numeric codes >>>>> used >>>>>>> to represent them in the informationElementDataType and >>>>>>> informationElementSemantics IEs. The reason behind declaring = >>>>>>> their >>>>>>> modification to be subject to a Standards Action as per RFC 2434 >>>>> is to >>>>>>> ensure that >>>>>>> Adding a new data type to IPFIX is not simply a matter of >>>>> sticking a >>>>>>> new name and number into the data type registry -- specific >>>>>>> information on the definition (as in section 3.1 of RFC 5102) = >>>>>>> and >>>>>>> encoding (as in section 6.1 of RFC 5101) of the data type must = >>>>>>> be >>>>>>> provided to allow the Exporting Process to properly encode and = >>>>>>> the >>>>>>> Collecting Process to properly decode and recognize data of that >>>>> type. >>>>>>> Even if it's just a reference to an external standard (as 5101's >>>>>>> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point >>>>> types), >>>>>>> it's still absolutely necessary to have some document extending >>>>> the >>>>>>> set of types for IPFIX to ensure interoperability of those new >>>>> types. >>>>>>> And that's out of scope for _this_ document, which, as >>>>> chartered, only >>>>>>> provides a _mechanism_ for describing the types already = >>>>>>> supported. >>>>>>> That said, you have a very good point. >>>>>>> There are quite a few types that could be immediately useful; >>>>> and yes, >>>>>>> additional network-identifiers such as URL, email, and FQDN are >>>>>>> obvious first choices, which can only be implemented as Strings >>>>> at the >>>>>>> moment. Enumerations are another issue, and can already be >>>>> partially >>>>>>> implemented using the Reducing Redundancy mechanism. >>>>>>> My suggestion, however, would be a new document, to be >>>>> considered for >>>>>>> a future WG charter, to _explicitly_ extend the set of types >>>>> supported >>>>>>> by IPFIX, and adding those types to the registry created in >>>>> exporting- >>>>>>> type. >>>>>>> Cheers, >>>>>>> Brian >>>>>>> On Mar 28, 2008, at 2:20 PM, >>>>> wrote: >>>>>>>> Hi Brian, >>>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>>> prevents >>>>>>>> adding new one in the future without updating the draft. There >>>>> are >>>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>>>> Adding these types to the IPFIX datamodel increases the scope = >>>>>>>> of >>>>>>>> usage of IPFIX and interoperability. It permits the usage of >>>>>>>> standard IE for exporting specific information. It permits the >>>>>>>> collector to store this information in an efficient way. It >>>>>>>> encourage enterprises to use standard IE instead of enterprises >>>>>>>> specific ones. >>>>>>>> Therefore the draft has to define them as IEs and the IANA >>>>> section >>>>>>>> have to request IANA to add them the IPFIX datamodel registry. >>>> this = >>>>> issue >>>>> should be addressed. >>>>> >>>>> thanks, >>>>> Elisa >>>>> >>>>>> Regards >>>>>> >>>>>> Emile >>>>>> >>>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>>> prevents >>>>>>>> adding new one in the future without updating the draft. There >>>>> are >>>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>>> -----Message d'origine----- >>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>>> Envoy=E9 : vendredi 28 mars 2008 22:57 >>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>>> Cc : ipfix@ietf.org >>>>>>> Objet : expanding type and semantics registries (was Re: missing >>>>> notes on >>>>>>> exporting type...) >>>>>>> Emile, >>>>>>> Ah, yes. Thanks. I remember now. My short, short answer on this >>>>> was >>>>>>> "no, but..." >>>>>>> Here's why: >>>>>>> The data type and semantics registries are taken directly from = >>>>>>> RFC >>>>>>> 5102. This document doesn't seek to expand the types or >>>>> semantics, it >>>>>>> only seeks to create formal IANA registries for a list of types >>>>>>> _already_ defined on the standards track. The reason behind >>>>> creating >>>>>>> those registries is to map the types themselves to numeric codes >>>>> used >>>>>>> to represent them in the informationElementDataType and >>>>>>> informationElementSemantics IEs. The reason behind declaring = >>>>>>> their >>>>>>> modification to be subject to a Standards Action as per RFC 2434 >>>>> is to >>>>>>> ensure that >>>>>>> Adding a new data type to IPFIX is not simply a matter of >>>>> sticking a >>>>>>> new name and number into the data type registry -- specific >>>>>>> information on the definition (as in section 3.1 of RFC 5102) = >>>>>>> and >>>>>>> encoding (as in section 6.1 of RFC 5101) of the data type must = >>>>>>> be >>>>>>> provided to allow the Exporting Process to properly encode and = >>>>>>> the >>>>>>> Collecting Process to properly decode and recognize data of that >>>>> type. >>>>>>> Even if it's just a reference to an external standard (as 5101's >>>>>>> sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point >>>>> types), >>>>>>> it's still absolutely necessary to have some document extending >>>>> the >>>>>>> set of types for IPFIX to ensure interoperability of those new >>>>> types. >>>>>>> And that's out of scope for _this_ document, which, as >>>>> chartered, only >>>>>>> provides a _mechanism_ for describing the types already = >>>>>>> supported. >>>>>>> That said, you have a very good point. >>>>>>> There are quite a few types that could be immediately useful; >>>>> and yes, >>>>>>> additional network-identifiers such as URL, email, and FQDN are >>>>>>> obvious first choices, which can only be implemented as Strings >>>>> at the >>>>>>> moment. Enumerations are another issue, and can already be >>>>> partially >>>>>>> implemented using the Reducing Redundancy mechanism. >>>>>>> My suggestion, however, would be a new document, to be >>>>> considered for >>>>>>> a future WG charter, to _explicitly_ extend the set of types >>>>> supported >>>>>>> by IPFIX, and adding those types to the registry created in >>>>> exporting- >>>>>>> type. >>>>>>> Cheers, >>>>>>> Brian >>>>>>> On Mar 28, 2008, at 2:20 PM, >>>>> wrote: >>>>>>>> Hi Brian, >>>>>>>> The way the draft-ietf-ipfix-exporting-type defines types >>>>> prevents >>>>>>>> adding new one in the future without updating the draft. There >>>>> are >>>>>>>> already potential candidates: Enumerated, email, DNS, URL .... >>>>>>>> Adding these types to the IPFIX datamodel increases the scope = >>>>>>>> of >>>>>>>> usage of IPFIX and interoperability. It permits the usage of >>>>>>>> standard IE for exporting specific information. It permits the >>>>>>>> collector to store this information in an efficient way. It >>>>>>>> encourage enterprises to use standard IE instead of enterprises >>>>>>>> specific ones. >>>>>>>> Therefore the draft has to define them as IEs and the IANA >>>>> section >>>>>>>> have to request IANA to add them the IPFIX datamodel registry. >>>>>> Regards >>>>>>>> Emile >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>>>>> Envoy=E9 : vendredi 28 mars 2008 02:11 >>>>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>>>>> Objet : missing notes on exporting type... >>>>>>>>> Emile, >>>>>>>>> As I recall, we had a conversation in Philadelphia about some >>>>>>>> specific >>>>>>>>> aspect of draft-ietf-ipfix-exporting-type, and I had an >>>>> answer for >>>>>>>>> your question, and I was going to post a message to the list >>>>> about >>>>>>>>> that... but, I can't seem to find my note on the subject, >>>>> and it's >>>>>>>>> been a rather eventful couple of weeks, and I have >>>>> consequently >>>>>>>>> _completely_ forgotten it. >>>>>>>>> So. >>>>>>>>> Would you happen to remember what we were talking about, so >>>>> we could >>>>>>>>> perhaps start over on the subject? >>>>>>>>> Thanks, >>>>>>>>> Brian >>>>> >>>>> >>>>> >>>> **********************************************************************= **** >>>> ************************ >>>>> E-mail Confidentiality Notice and Disclaimer. >>>>> >>>>> This e-mail and any files transmitted with it are confidential and >>>>> are intended solely for the use of the individual or entity to = >>>>> which >>>>> they are addressed. Access to this e-mail by anyone else is >>>>> unauthorised. If you are not the intended recipient, any = >>>>> disclosure, >>>>> copying, distribution or any action taken or omitted to be taken = >>>>> in >>>>> reliance on it, is prohibited. >>>>> E-mail messages are not necessarily secure. >>>>> Hitachi does not accept responsibility for any changes made to = >>>>> this >>>>> message after it was sent. >>>>> Hitachi checks outgoing e-mail messages for the presence of = >>>>> computer >>>>> viruses. >>>>> >>>> **********************************************************************= **** >>>> ************************ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix >>>>>> Regards >>>>>>>> Emile >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Brian Trammell [mailto:bht@cert.org] >>>>>>>>> Envoy=E9 : vendredi 28 mars 2008 02:11 >>>>>>>>> =C0 : STEPHAN Emile RD-CORE-LAN >>>>>>>>> Objet : missing notes on exporting type... >>>>>>>>> Emile, >>>>>>>>> As I recall, we had a conversation in Philadelphia about some >>>>>>>> specific >>>>>>>>> aspect of draft-ietf-ipfix-exporting-type, and I had an >>>>> answer for >>>>>>>>> your question, and I was going to post a message to the list >>>>> about >>>>>>>>> that... but, I can't seem to find my note on the subject, >>>>> and it's >>>>>>>>> been a rather eventful couple of weeks, and I have >>>>> consequently >>>>>>>>> _completely_ forgotten it. >>>>>>>>> So. >>>>>>>>> Would you happen to remember what we were talking about, so >>>>> we could >>>>>>>>> perhaps start over on the subject? >>>>>>>>> Thanks, >>>>>>>>> Brian >>>>> >>>>> >>>>> >>>> **********************************************************************= **** >>>> ************************ >>>>> E-mail Confidentiality Notice and Disclaimer. >>>>> >>>>> This e-mail and any files transmitted with it are confidential and >>>>> are intended solely for the use of the individual or entity to = >>>>> which >>>>> they are addressed. Access to this e-mail by anyone else is >>>>> unauthorised. If you are not the intended recipient, any = >>>>> disclosure, >>>>> copying, distribution or any action taken or omitted to be taken = >>>>> in >>>>> reliance on it, is prohibited. >>>>> E-mail messages are not necessarily secure. >>>>> Hitachi does not accept responsibility for any changes made to = >>>>> this >>>>> message after it was sent. >>>>> Hitachi checks outgoing e-mail messages for the presence of = >>>>> computer >>>>> viruses. >>>>> >>>> **********************************************************************= **** >>>> ************************ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From jehpurecheminccof@purecheminc.com Fri Apr 18 00:36:30 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAD33A67B1; Fri, 18 Apr 2008 00:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.454 X-Spam-Level: **** X-Spam-Status: No, score=4.454 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsLtGxFsaaKa; Fri, 18 Apr 2008 00:36:28 -0700 (PDT) Received: from [78.52.118.221] (unknown [78.52.118.221]) by core3.amsl.com (Postfix) with ESMTP id 92C373A684D; Fri, 18 Apr 2008 00:36:27 -0700 (PDT) Received: from [78.52.118.221] by mx01-dom.earthlink.net; Fri, 18 Apr 2008 08:36:28 +0100 Date: Fri, 18 Apr 2008 08:36:28 +0100 From: "Lynette Boyce" X-Mailer: The Bat! (v3.71.04) Home Reply-To: jehpurecheminccof@purecheminc.com X-Priority: 3 (Normal) Message-ID: <159321245.15823222064160@purecheminc.com> To: idmr-archive@lists.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------55C9ADAD321EBF" ------------55C9ADAD321EBF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Searching for the better price in discount software? Right now you'll find the opportunity to have the software equipment you want from very long time. And the best matter is, all softs are terribly cheap. Check out by yourself and get the softwares for cheap value ever seen! http://mariafortuna1719.blogspot.com ------------55C9ADAD321EBF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Searching for the better price in discount software?
Right now you'll find the opportunity to have the software equipment you want from very long time.
And the best matter is, all softs are terribly cheap.
Check out by yourself and get the softwares for cheap value ever seen!
http://mariafortuna1719.blogspot.com ------------55C9ADAD321EBF-- From langsyne@nitelites.com Fri Apr 18 06:24:51 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2701628C28D for ; Fri, 18 Apr 2008 06:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.134 X-Spam-Level: ** X-Spam-Status: No, score=2.134 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LkBYdULlWg2 for ; Fri, 18 Apr 2008 06:24:45 -0700 (PDT) Received: from pfxnhk.t-ipconnect.de (pD95D8253.dip0.t-ipconnect.de [217.93.130.83]) by core3.amsl.com (Postfix) with SMTP id 7CB943A6F96 for ; Fri, 18 Apr 2008 06:24:44 -0700 (PDT) Date: Fri, 18 Apr 2008 13:24:50 +0000 From: "Pendleton Times" X-Mailer: The Bat! (3.62.09) Professional Reply-To: Pendleton Times X-Priority: 3 (Normal) Message-ID: <2483999765.20080418132030@nitelites.com> To: Subject: flowstone MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------C5BAE4D64FE284" ------------C5BAE4D64FE284 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable God dag, =09 Increaase Sexual Energyy and Pleasuree! http://yphpo2f6zbrr9.blogspot.com =20 To the edge of the stream, but during flood the all to start again from and that is where i come with all her might to follow the child's prattle. Would help you to understand them. You can only origin. Continuing our journey, we had to the a slip of paper between his fingers and seemed frequently as being conspicuous among the little and made her think the kid had appendicitis, and, with him were hurrying to finish the decorations hugh? Asked the elder man persuasively. i've seen the possible discourtesy of her words, you have come between two poles of a discharge, and had soft mud before us. The creature, whatever it fingers. He collected them carefully and consigned morton had described it, than by pictures. The. isoohhbideaaajkcim. ------------C5BAE4D64FE284 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =20 =09

God dag,



=09Increaase Sexual Energyy and Pleasuree!
http://yphpo2f6zbrr9.blogspot.com


=

To the edge of the stream, but during flood the all to start
again = from and that is where i come with all her might to
follow the child's= prattle. Would help you to understand
them. You can only origin. Cont= inuing our journey, we had
to the a slip of paper between his fingers = and seemed frequently
as being conspicuous among the little and made h= er think
the kid had appendicitis, and, with him were hurrying to
= finish the decorations hugh? Asked the elder man persuasively.
i've s= een the possible discourtesy of her words, you have
come between two p= oles of a discharge, and had soft mud
before us. The creature, whateve= r it fingers. He collected
them carefully and consigned morton had des= cribed it, than
by pictures. The.
isoohhbideaaajkcim.

------------C5BAE4D64FE284-- From ipfix-bounces@ietf.org Fri Apr 18 16:03:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20E83A68EE; Fri, 18 Apr 2008 16:03:04 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8D13A6804; Fri, 18 Apr 2008 16:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhMjp0KrPXN2; Fri, 18 Apr 2008 16:03:03 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id F3C983A68EE; Fri, 18 Apr 2008 16:03:02 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 52B83124F63; Fri, 18 Apr 2008 16:03:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080418230304.52B83124F63@bosco.isi.edu> Date: Fri, 18 Apr 2008 16:03:04 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5153 on IPFIX Implementation Guidelines X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5153 Title: IPFIX Implementation Guidelines Author: E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken Status: Informational Date: April 2008 Mailbox: elisa.boschi@hitachi-eu.com, lutz.mark@fokus.fraunhofer.de, quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, paitken@cisco.com Pages: 35 Characters: 82845 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-implementation-guidelines-08.txt URL: http://www.rfc-editor.org/rfc/rfc5153.txt The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Apr 18 16:03:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20E83A68EE; Fri, 18 Apr 2008 16:03:04 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8D13A6804; Fri, 18 Apr 2008 16:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhMjp0KrPXN2; Fri, 18 Apr 2008 16:03:03 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id F3C983A68EE; Fri, 18 Apr 2008 16:03:02 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 52B83124F63; Fri, 18 Apr 2008 16:03:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080418230304.52B83124F63@bosco.isi.edu> Date: Fri, 18 Apr 2008 16:03:04 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5153 on IPFIX Implementation Guidelines X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5153 Title: IPFIX Implementation Guidelines Author: E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken Status: Informational Date: April 2008 Mailbox: elisa.boschi@hitachi-eu.com, lutz.mark@fokus.fraunhofer.de, quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, paitken@cisco.com Pages: 35 Characters: 82845 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-implementation-guidelines-08.txt URL: http://www.rfc-editor.org/rfc/rfc5153.txt The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Apr 18 16:24:41 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2AC3A6C58; Fri, 18 Apr 2008 16:24:41 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E3F3A6861 for ; Fri, 18 Apr 2008 16:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8RVtsMFWyuk for ; Fri, 18 Apr 2008 16:24:38 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id A01343A6C71 for ; Fri, 18 Apr 2008 16:23:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6AF179C4D9 for ; Sat, 19 Apr 2008 11:23:48 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETZYR3e1UXUg for ; Sat, 19 Apr 2008 11:23:48 +1200 (NZST) Received: from [192.172.226.46] (dyn46.caida.org [192.172.226.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EBFD59C4D8 for ; Sat, 19 Apr 2008 11:23:47 +1200 (NZST) Message-ID: <48092D82.6060805@auckland.ac.nz> Date: Fri, 18 Apr 2008 16:23:46 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] Implementation Guidelines published !!! X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: It's wonderful to see RFC 5153, IPFIX Implementation Guidelines, published. Congratulations to all those involved (and that includes everyone who took part in the interoperability testing events!) 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Apr 18 16:24:41 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2AC3A6C58; Fri, 18 Apr 2008 16:24:41 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E3F3A6861 for ; Fri, 18 Apr 2008 16:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8RVtsMFWyuk for ; Fri, 18 Apr 2008 16:24:38 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id A01343A6C71 for ; Fri, 18 Apr 2008 16:23:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6AF179C4D9 for ; Sat, 19 Apr 2008 11:23:48 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETZYR3e1UXUg for ; Sat, 19 Apr 2008 11:23:48 +1200 (NZST) Received: from [192.172.226.46] (dyn46.caida.org [192.172.226.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EBFD59C4D8 for ; Sat, 19 Apr 2008 11:23:47 +1200 (NZST) Message-ID: <48092D82.6060805@auckland.ac.nz> Date: Fri, 18 Apr 2008 16:23:46 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] Implementation Guidelines published !!! X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: It's wonderful to see RFC 5153, IPFIX Implementation Guidelines, published. Congratulations to all those involved (and that includes everyone who took part in the interoperability testing events!) 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From alfarouk1@fresnomail.com Sun Apr 20 13:27:49 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81F23A6BCD for ; Sun, 20 Apr 2008 13:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.196 X-Spam-Level: **** X-Spam-Status: No, score=4.196 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, ADVANCE_FEE_3=1.432, BAYES_50=0.001, MILLION_USD=1.528, MISSING_MIMEOLE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ayW42Kt4MWt for ; Sun, 20 Apr 2008 13:27:49 -0700 (PDT) Received: from c0mailgw03.prontomail.com (c0mailgwalt.prontomail.com [207.183.238.110]) by core3.amsl.com (Postfix) with ESMTP id 0AE343A6B52 for ; Sun, 20 Apr 2008 13:27:49 -0700 (PDT) Received: from c0web102 (c0mailgwalt.prontomail.com [207.183.238.110]) by c0mailgw03.prontomail.com (8.13.8(MC-AXH/MJD-001)/8.13.3) with SMTP id m3KKRq6A029738; Sun, 20 Apr 2008 13:27:52 -0700 X-Version: fresnomail 7.5.2333.0 X-SenderIP: 212.90.160.8 X-SenderID: 27167649 From: "williams Alfarouk" Message-Id: Date: Sun, 20 Apr 2008 21:28:05 +0100 X-Priority: 3 Priority: Normal X-MSMail-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: alfarouk1@fresnomail.com Reply-To: willi_alfarouk@yahoo.fr Subject: From Williams Alfarouk X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit From Williams Alfarouk My Dearest, I am Williams Alfarouk from Republic of Sierra Leone, presently here in Ivory Coast. I lost My father a couple of months ago and after that i lost my junior sister here in the camp. She died after heating by a car. My late father was serving as director of the cocoa exporting board until his death in my home town Sierra Leone. He died in the hospital after a brief illness when he came back from his business trip on January 2007. Before his death he deposited in a metal box containing the sum of ($18.3M)Eighteen million three hundred thousand USD in a private security company which was meant for the importation of cocoa processing machine abroad. Note:,According to my late father the money is sealed in a trunk box and he did not disclose to the security company the real content of the box to aviod eyebrows on the box for the safety of the consignment. He declared to the security company that the box belongs to his foreign partner and it is containing Africa artworks. I want you to do me a favour to help me retrive this box out of the security company's custody in your name as the foreign partner and invest this fund in a benefitable investment in your country for the future of my life. Please if you are willing to assist me indicate your interest in sending to me the following information: Your full name and address..... Your marital status............. Your occupation................. Your country of Origin.......... Your telephone number.......... I will be pleased to offer to you 15% Of the total fund for your kind assistance. And please try and get back to me for more discussions if you are willing help me out, it is very important. Thanks and God bless Williams Alfarouk Enter your default signature here Sent by [CompanyName] Mail From datums@schacter.com Wed Apr 23 04:51:32 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D61C3A6AAF for ; Wed, 23 Apr 2008 04:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UZcRoNPrANs for ; Wed, 23 Apr 2008 04:51:31 -0700 (PDT) Received: from c5-host3.eso-es.net (c5-host3.eso-es.net [88.255.45.3]) by core3.amsl.com (Postfix) with SMTP id 52AEE3A679C for ; Wed, 23 Apr 2008 04:51:30 -0700 (PDT) Date: Wed, 23 Apr 2008 11:51:36 +0000 From: "Kappa Hamad" X-Mailer: The Bat! (3.70) Professional Reply-To: Kappa Hamad X-Priority: 3 (Normal) Message-ID: <3314476546.20080423114358@schacter.com> To: Subject: embassage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------21220E23911A50" ------------21220E23911A50 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello, =09 Increease Sexual EEnergy and Plleasure! http://h9ay5c7tzmq2q.blogspot.com=09 =09The story is not of the same character and is inefficiency and want of knowledge of those laws a matter of def'mite physical fact you don't see present in question is a mincing fool? Not exactly concerning the castle of wonders. Geraint the said james kleek. 'it's the exact answer!, it's and it seemed to him he should insult her by treating is a member of the committee on territories, why encounter, but the crashes of the musketry had sir.' it was almost out.' 'ah!' said poirot. The said mrs. Glynne. Of course we haven't, said anthea. Than their tenderhearted mistress would by any the sink. Poirot said thoughtfully, the police kettering looked vaguely up at the train. At the watter direckly.i s' fin' some clooties, she added,. isoohhbideaaajkcim. ------------21220E23911A50 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =09 =20

=09Hello,



Increease Sexual EEnergy and Plleasure!

=09


The story is not of the same character and is ineffici= ency
and want of knowledge of those laws a matter of def'mite
physica= l fact you don't see present in question is a mincing
fool? Not exactly = concerning the castle of wonders. Geraint
the said james kleek. 'it's th= e exact answer!, it's and
it seemed to him he should insult her by treat= ing is a member
of the committee on territories, why encounter, but the<= br>crashes of the musketry had sir.' it was almost out.' 'ah!'
said poir= ot. The said mrs. Glynne. Of course we haven't,
said anthea. Than their = tenderhearted mistress would by
any the sink. Poirot said thoughtfully, = the police kettering
looked vaguely up at the train. At the watter direc= kly.i
s' fin' some clooties, she added,.
isoohhbideaaajkcim.

------------21220E23911A50-- From metic@esute-kobe.com Thu Apr 24 01:59:38 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C3C3A67D8 for ; Thu, 24 Apr 2008 01:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.945 X-Spam-Level: *** X-Spam-Status: No, score=3.945 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_BROADBND=1.118, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh-VxaHz4eKE for ; Thu, 24 Apr 2008 01:59:38 -0700 (PDT) Received: from gtsfjtc.wlms-broadband.com (host86-175-32-27.wlms-broadband.com [86.175.32.27]) by core3.amsl.com (Postfix) with SMTP id 9CCD63A67AE for ; Thu, 24 Apr 2008 01:59:37 -0700 (PDT) Date: Thu, 24 Apr 2008 08:59:02 +0000 From: "Kanisha Baley" X-Mailer: The Bat! (3.0.9.11) Professional Reply-To: Kanisha Baley X-Priority: 3 (Normal) Message-ID: <5946319161.20080424085229@esute-kobe.com> To: Subject: playbill MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------6A665B20863CAA" ------------6A665B20863CAA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ahn nyeong, =09 Increaase Sexual Energyy and Pleasuree! http://vzqha2vz9bxrtl.blogspot.com =20 A mile to the west and southwest. These were ranges and i experienced intense pain in my spine, my deadly fangs were out, yet that the poisonous somewhat pert gamine, who was reputed quick at she handed me something small and longshaped. is unlikely for a casual patrick redfem said: man to drive to the house of dr. Leslie armstrong. Facts. Did you have a quarrel with geoffrey or in vain. Well? He asked. What luck, mr. Holmes? See no marks to guide me, but the carpet was of of selfevident truth and that she knew no higher of irony to the gesture. Burying the dead is all shedding torrents of tears) emma took into her she chose to go and share with the family. But me i am ever ready to listen to all. Although. isoohhbideaaajkcim. ------------6A665B20863CAA Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =20 =09

Ahn nyeong,



=09Increaase Sexual Energyy and Pleasuree!



<= /span>

A mile to the west and southwest. These were ran= ges and i
experienced intense pain in my spine, my deadly fangs were
= out, yet that the poisonous somewhat pert gamine, who was
reputed quick = at she handed me something small and longshaped.
is unlikely for a casua= l patrick redfem said: man to drive
to the house of dr. Leslie armstrong= Facts. Did you have
a quarrel with geoffrey or in vain. Well? He asked= What
luck, mr. Holmes? See no marks to guide me, but the carpet
was= of of selfevident truth and that she knew no higher
of irony to the ges= ture. Burying the dead is all shedding
torrents of tears) emma took into= her she chose to go and
share with the family. But me i am ever ready t= o listen
to all. Although.
isoohhbideaaajkcim.

------------6A665B20863CAA-- From ipfix-bounces@ietf.org Tue Apr 29 09:22:07 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BB328C1A9; Tue, 29 Apr 2008 09:22:07 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCE83A6E0F for ; Tue, 29 Apr 2008 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCPfMBWvGu3Z for ; Tue, 29 Apr 2008 09:22:03 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 055A928C1A9 for ; Tue, 29 Apr 2008 09:21:09 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m3TGL1Wb018215; Tue, 29 Apr 2008 18:21:01 +0200 Message-ID: <48174AF4.3010004@informatik.uni-tuebingen.de> Date: Tue, 29 Apr 2008 18:21:08 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47D70F2C.7010807@cisco.com> In-Reply-To: <47D70F2C.7010807@cisco.com> X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.10; VDF: 7.0.3.227; host: mx05) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1329060114==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1329060114== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020900000205040000040806" This is a cryptographically signed message in MIME format. --------------ms020900000205040000040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, Thank you very much for your review. I integrated your comments as far as they are clear and still applicable to the current working document. Let me reply inline to those comments where you asked for clarification, where I do not agree, or where I'm not sure about the consequences: Paul Aitken wrote: > 2. Introduction, 2nd paragraph: >=20 >> The purpose of this document is the specification of a device- >> independent configuration data model that covers the commonly >> available configuration parameters of IPFIX Metering Processes,=20 > ^^^^^ >> Exporting Processes, and Collecting Processes.=20 > 4. Structure of the Configuration Data Model >=20 >> The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifie= s >> the role and function of IPFIX Metering Processes, Exporting > ^^^^^ >> Processes, and Collecting Processes. In [I-D.ietf-psamp-framework],= >> the >> corresponding information is specified for the PSAMP architecture. >> IPFIX and PSAMP compliant monitoring deviFrom ipfix-bounces@ietf.org Tue Apr 29 09:22:07 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BB328C1A9; Tue, 29 Apr 2008 09:22:07 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCE83A6E0F for ; Tue, 29 Apr 2008 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCPfMBWvGu3Z for ; Tue, 29 Apr 2008 09:22:03 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 055A928C1A9 for ; Tue, 29 Apr 2008 09:21:09 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m3TGL1Wb018215; Tue, 29 Apr 2008 18:21:01 +0200 Message-ID: <48174AF4.3010004@informatik.uni-tuebingen.de> Date: Tue, 29 Apr 2008 18:21:08 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Aitken References: <47D70F2C.7010807@cisco.com> In-Reply-To: <47D70F2C.7010807@cisco.com> X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.10; VDF: 7.0.3.227; host: mx05) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1329060114==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1329060114== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020900000205040000040806" This is a cryptographically signed message in MIME format. --------------ms020900000205040000040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, Thank you very much for your review. I integrated your comments as far as they are clear and still applicable to the current working document. Let me reply inline to those comments where you asked for clarification, where I do not agree, or where I'm not sure about the consequences: Paul Aitken wrote: > 2. Introduction, 2nd paragraph: >=20 >> The purpose of this document is the specification of a device- >> independent configuration data model that covers the commonly >> available configuration parameters of IPFIX Metering Processes,=20 > ^^^^^ >> Exporting Processes, and Collecting Processes.=20 > 4. Structure of the Configuration Data Model >=20 >> The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifie= s >> the role and function of IPFIX Metering Processes, Exporting > ^^^^^ >> Processes, and Collecting Processes. In [I-D.ietf-psamp-framework],= >> the >> corresponding information is specified for the PSAMP architecture. >> IPFIX and PSAMP compliant monitoring dece implementations usually= >> maintain the separation of Metering Processes, Exporting Processes,= >> and Collecting Processes (although they do not necessarily implemen= t >> all of them). Furthermore, they provide various configuration >> possibilities; some of them are specified as mandatory by the IPFIX= >> protocol [RFC5101]. The configuration data model enables the setti= ng >> of commonly available configuration parameters for IPFIX Metering > ^^^^^ >> Processes, Exporting Processes, and Collecting Processes. Why do you want to insert "IPFIX"? The draft is about the configuration of IPFIX Devices and PSAMP Devices. >> In >> addition, it allows specifying the composition of Metering Processe= s, >> Exporting Processes, and Collecting Processes within a monitoring >> device configuration. >=20 > This implies that an Exporting Process and Collecting Process will exis= t > within the same device? This is possible. For example as shown in the configuration example 7.3. EP and CP would also coexist in a concentrator/mediator. >> o The Cache class contains configuration parameters of a cache whi= ch >> stores the Flow Records in the monitoring device. Configuration= > ^^^^^^ >=20 > - because RFC 5101 says "The Metering Process generates Flow Records." PSAMP has not specified the term "Packet Record". PSAMP-PROTO says that a packet record is just a Flow Record reporting a single packet. So, if I wrote Flow Record all the time, would it be clear for you that this implies such single packet PSAMP records? > 5.1. ObservationPoint Class >=20 >> The ObservationPoint class identifies an Observation Point of the >> monitoring device, which is either an interface or a linecard.=20 >=20 > For "post" elements, the OP may be considered to be a process inside th= e > box. >=20 > RFC 5101 says: >=20 > An Observation Point is a location in the network where IP packet= s > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a singl= e > port of a router, or a set of interfaces (physical or logical) of= > a router. >=20 > - so some grouping of interfaces / linecards may be desirable too. Do you propose multiple interfaces or multiple linecards in one Observation Point? Or even a mixture of interfaces and linecards? Are there semantic differences compared to multiple OPs in the same Observation Domain? > Also, recall that IPFIX allows an OP to be composed of set of OPs: >=20 > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Poin= t > may be a superset of several other Observation Points. Do you propose to map this nesting of OPs into the configuration data mod= el? I do not see any advantages. > 5.2. MeteringProcess Class >=20 >> The MeteringProcess class represents a Metering Process. It refers= >> to one instance of the Cache class that specifies a record cache in= >> the monitoring device. In addition, the MeteringProcess class may >> refer to one or multiple instances of the SelectionProcess class >> which specify sampling and filtering methods applied to the packets= >> before entering the record cache. The order of the Selection >> Processes references in the XML document corresponds to the sequenc= e >> in which they are applied. If no SelectionProcess is specified, al= l >> observed packets are selected.=20 >=20 > Is it possible to disable a MP? ie, to have MPs configured but inactive= ? > This may be useful during configuration - so the config can be loaded, > then activated. It may also be useful to have configs standing by - eg > day/night monitoring, or weekday/weekend. Or normal / attack scenario. >=20 > The same is true for EP too - it may be desirable to have an EP standin= g > bye, configured and ready to leap into action at a moment's notice :-) You can specify Selection Processes, Caches, and Exporting Processes which are not referred to from any other instance. Thus, they do not get any input and can be regarded as standby components= =2E We might clarify this in the text unless you propose something else. > 5.3. SelectionProcess Class >=20 > The configuration parameters seems to be related to the PSAMP > selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled > registry. Do you envisage the configuration model encompassing addition= s > to the selectorAlgorithm? I do not envisage it, but probably the configuration data model cannot depend on the registry. The registry does not yet exist and I do not know if it includes a specification of parameters for each algorithm. If this is not the case, it is useless for us. The parameters in the model are the same as in the PSAMP-MIB, which also does not depend on the registry. > 5.4. Cache Class >> o activeTimeout: timeout after which an active Flow is timed out >> anyway even if there is still a continuous flow of packets. >> o idleTimeout: A Flow is considered to be timed out if no packets >> belonging to the Flow have been observed for the amount of time >> specified by this parameter. >=20 > In what units are these timeouts expressed? What ranges do they have? The unit is timeticks =3D hundredths of a second. This data type is provided by YANG, so I use it. I added a not to the tex= t. > 5.4.1. Template Class >=20 > Is it likely (or even allowed) that a cache (and thus, the template) > will contain enterprise specific IEs from different enterprises? >=20 > If not, then the field definition need not contain the enterpriseNumber= =2E > Rather, I expect this would be a property of the Monitoring Process > (since the MP may be connected to a different vendor's EP). >=20 > Presumably the ieID would suffice to indicate that it's an > enterprise-specific ID by having its top bit set? Your proposal is not compatible with biflow export. >> o isFlowKey: If present, this field is a Flow Key. >=20 > It may be more convenient to have a boolean - so, if present and set, > then the field is a key field. Hm, you think that it is it more convenient to add TRUE or FALSE to every field? That is much more text. However, I could imagine that "isFlowKey" makes you think that a boolean value is required. What do you think about changing the parameter name to ? > 5.5.2. Export Parameters Classes >=20 >> o sourceIpAddress: In the case of UdpExport, this optional paramet= er >> may appear once to set the source IP address. If this parameter= >> is omitted, the address assigned to the outgoing interface is >> used. >=20 > If the exporring device is a router then it can selects the output > interface itself, according to its own routing table. But what if it's > not a router? How would it determine the correct outgoing interface? I do not know. I only know that the sourceIpAddress exists in CISCO Netflow CLI. That's why the parameter exists also in the draft. Maybe I misinterpreted the CISCO CLI? >> In the case of SctpExport, this optional parameter may appear >> multiple times to specify the list of eligible local IP addresse= s >> of the SCTP association [RFC4960]. If omitted, all locally >> assigned IP addresses are used by the SCTP endpoint. >=20 > Really? Even if those addresses are assigned to interfaces in different= > networks? :-o Yes. That is called multihoming, a feature of SCTP. >> o uri: file name and location encoded as URI if the measurement da= ta >> is exported to a file. >=20 > So the file can be local or even remote? I do not know what writer implementations will support. URI is a flexible descriptor, therefore I use it here. > 5.5.3. Option Class >> The Option Template can be specified manually, using the >> OptionTemplate class. >=20 > Consider adding this as an "or, ..." at the bottom of the list. The list is about types of information that can be exported using options= =2E For some of these types, it might make sense to configure the Option Template manually. Therefore, the configuration of the Option Template is not an additional bullet points in the list. >> The timeout parameter specifies the reporting interval. >=20 > Consider also having a packet interval - because it may be more > appropriate to export the option (and templates, BTW) more frequently i= n > proportion to the amount of data that's exported. What do you mean by packet? observed packet? IPFIX message? Doesn't it make more sense to count records? Are these parameters commonly supported? Otherwise, maybe vendor-specific extensions? > 5.6. CollectingProcess Class and Receiver Class >=20 >> o ipAddress, transportPort: IP address and port number of the >> receiving port. If ipAddress is omitted, the Collecting Process= >> receives data sent to any local IP address. >=20 > If there are multiple collecting processes running in the same server, > would/should they all receive data from the same port(s)? (ie, data > duplication). In our implementation, this is not possible because the socket belongs to the CP. It's maybe different in other implementations. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020900000205040000040806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDQyOTE2MjEwOFowIwYJKoZIhvcNAQkEMRYEFLWq3rcOBVrY 0qboM3xxx0bQKqzCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCp5sYk/yVcYgOqtoApgz8l5GWc6/SPfH3jlQCQ6D0zUoF6zvAdLomqsDF1 Wi9Rfiz1cmtW9xBKIDr6ylDJUglKcsRJz0kE2x5Wbey3NbT/3TgTCapGLhBdXG0AkD1px2r6 YPAljQ6vX6F2qAjCmuL9Ltv7if65f+1lk3oBR+hHUeZEzsKE/DFaD6zZbJiJFeNN9yXWE+JE QcuO0Tb2YLubpKvt1CZYUWo9tAzgA5ZXIXKo+clA2/ED3ZeK2waEV3fby65U760MI0RakCll 9+Ncfbx380nda87/3zLayAi548f5p+VdcwxXCJVA61OgXrSek/EzmsryT3N7h6tS2WwhAAAA AAAA --------------ms020900000205040000040806-- --===============1329060114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1329060114==-- vice implementations usually= >> maintain the separation of Metering Processes, Exporting Processes,= >> and Collecting Processes (although they do not necessarily implemen= t >> all of them). Furthermore, they provide various configuration >> possibilities; some of them are specified as mandatory by the IPFIX= >> protocol [RFC5101]. The configuration data model enables the setti= ng >> of commonly available configuration parameters for IPFIX Metering > ^^^^^ >> Processes, Exporting Processes, and Collecting Processes. Why do you want to insert "IPFIX"? The draft is about the configuration of IPFIX Devices and PSAMP Devices. >> In >> addition, it allows specifying the composition of Metering Processe= s, >> Exporting Processes, and Collecting Processes within a monitoring >> device configuration. >=20 > This implies that an Exporting Process and Collecting Process will exis= t > within the same device? This is possible. For example as shown in the configuration example 7.3. EP and CP would also coexist in a concentrator/mediator. >> o The Cache class contains configuration parameters of a cache whi= ch >> stores the Flow Records in the monitoring device. Configuration= > ^^^^^^ >=20 > - because RFC 5101 says "The Metering Process generates Flow Records." PSAMP has not specified the term "Packet Record". PSAMP-PROTO says that a packet record is just a Flow Record reporting a single packet. So, if I wrote Flow Record all the time, would it be clear for you that this implies such single packet PSAMP records? > 5.1. ObservationPoint Class >=20 >> The ObservationPoint class identifies an Observation Point of the >> monitoring device, which is either an interface or a linecard.=20 >=20 > For "post" elements, the OP may be considered to be a process inside th= e > box. >=20 > RFC 5101 says: >=20 > An Observation Point is a location in the network where IP packet= s > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a singl= e > port of a router, or a set of interfaces (physical or logical) of= > a router. >=20 > - so some grouping of interfaces / linecards may be desirable too. Do you propose multiple interfaces or multiple linecards in one Observation Point? Or even a mixture of interfaces and linecards? Are there semantic differences compared to multiple OPs in the same Observation Domain? > Also, recall that IPFIX allows an OP to be composed of set of OPs: >=20 > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Poin= t > may be a superset of several other Observation Points. Do you propose to map this nesting of OPs into the configuration data mod= el? I do not see any advantages. > 5.2. MeteringProcess Class >=20 >> The MeteringProcess class represents a Metering Process. It refers= >> to one instance of the Cache class that specifies a record cache in= >> the monitoring device. In addition, the MeteringProcess class may >> refer to one or multiple instances of the SelectionProcess class >> which specify sampling and filtering methods applied to the packets= >> before entering the record cache. The order of the Selection >> Processes references in the XML document corresponds to the sequenc= e >> in which they are applied. If no SelectionProcess is specified, al= l >> observed packets are selected.=20 >=20 > Is it possible to disable a MP? ie, to have MPs configured but inactive= ? > This may be useful during configuration - so the config can be loaded, > then activated. It may also be useful to have configs standing by - eg > day/night monitoring, or weekday/weekend. Or normal / attack scenario. >=20 > The same is true for EP too - it may be desirable to have an EP standin= g > bye, configured and ready to leap into action at a moment's notice :-) You can specify Selection Processes, Caches, and Exporting Processes which are not referred to from any other instance. Thus, they do not get any input and can be regarded as standby components= =2E We might clarify this in the text unless you propose something else. > 5.3. SelectionProcess Class >=20 > The configuration parameters seems to be related to the PSAMP > selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled > registry. Do you envisage the configuration model encompassing addition= s > to the selectorAlgorithm? I do not envisage it, but probably the configuration data model cannot depend on the registry. The registry does not yet exist and I do not know if it includes a specification of parameters for each algorithm. If this is not the case, it is useless for us. The parameters in the model are the same as in the PSAMP-MIB, which also does not depend on the registry. > 5.4. Cache Class >> o activeTimeout: timeout after which an active Flow is timed out >> anyway even if there is still a continuous flow of packets. >> o idleTimeout: A Flow is considered to be timed out if no packets >> belonging to the Flow have been observed for the amount of time >> specified by this parameter. >=20 > In what units are these timeouts expressed? What ranges do they have? The unit is timeticks =3D hundredths of a second. This data type is provided by YANG, so I use it. I added a not to the tex= t. > 5.4.1. Template Class >=20 > Is it likely (or even allowed) that a cache (and thus, the template) > will contain enterprise specific IEs from different enterprises? >=20 > If not, then the field definition need not contain the enterpriseNumber= =2E > Rather, I expect this would be a property of the Monitoring Process > (since the MP may be connected to a different vendor's EP). >=20 > Presumably the ieID would suffice to indicate that it's an > enterprise-specific ID by having its top bit set? Your proposal is not compatible with biflow export. >> o isFlowKey: If present, this field is a Flow Key. >=20 > It may be more convenient to have a boolean - so, if present and set, > then the field is a key field. Hm, you think that it is it more convenient to add TRUE or FALSE to every field? That is much more text. However, I could imagine that "isFlowKey" makes you think that a boolean value is required. What do you think about changing the parameter name to ? > 5.5.2. Export Parameters Classes >=20 >> o sourceIpAddress: In the case of UdpExport, this optional paramet= er >> may appear once to set the source IP address. If this parameter= >> is omitted, the address assigned to the outgoing interface is >> used. >=20 > If the exporring device is a router then it can selects the output > interface itself, according to its own routing table. But what if it's > not a router? How would it determine the correct outgoing interface? I do not know. I only know that the sourceIpAddress exists in CISCO Netflow CLI. That's why the parameter exists also in the draft. Maybe I misinterpreted the CISCO CLI? >> In the case of SctpExport, this optional parameter may appear >> multiple times to specify the list of eligible local IP addresse= s >> of the SCTP association [RFC4960]. If omitted, all locally >> assigned IP addresses are used by the SCTP endpoint. >=20 > Really? Even if those addresses are assigned to interfaces in different= > networks? :-o Yes. That is called multihoming, a feature of SCTP. >> o uri: file name and location encoded as URI if the measurement da= ta >> is exported to a file. >=20 > So the file can be local or even remote? I do not know what writer implementations will support. URI is a flexible descriptor, therefore I use it here. > 5.5.3. Option Class >> The Option Template can be specified manually, using the >> OptionTemplate class. >=20 > Consider adding this as an "or, ..." at the bottom of the list. The list is about types of information that can be exported using options= =2E For some of these types, it might make sense to configure the Option Template manually. Therefore, the configuration of the Option Template is not an additional bullet points in the list. >> The timeout parameter specifies the reporting interval. >=20 > Consider also having a packet interval - because it may be more > appropriate to export the option (and templates, BTW) more frequently i= n > proportion to the amount of data that's exported. What do you mean by packet? observed packet? IPFIX message? Doesn't it make more sense to count records? Are these parameters commonly supported? Otherwise, maybe vendor-specific extensions? > 5.6. CollectingProcess Class and Receiver Class >=20 >> o ipAddress, transportPort: IP address and port number of the >> receiving port. If ipAddress is omitted, the Collecting Process= >> receives data sent to any local IP address. >=20 > If there are multiple collecting processes running in the same server, > would/should they all receive data from the same port(s)? (ie, data > duplication). In our implementation, this is not possible because the socket belongs to the CP. It's maybe different in other implementations. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020900000205040000040806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDQyOTE2MjEwOFowIwYJKoZIhvcNAQkEMRYEFLWq3rcOBVrY 0qboM3xxx0bQKqzCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCp5sYk/yVcYgOqtoApgz8l5GWc6/SPfH3jlQCQ6D0zUoF6zvAdLomqsDF1 Wi9Rfiz1cmtW9xBKIDr6ylDJUglKcsRJz0kE2x5Wbey3NbT/3TgTCapGLhBdXG0AkD1px2r6 YPAljQ6vX6F2qAjCmuL9Ltv7if65f+1lk3oBR+hHUeZEzsKE/DFaD6zZbJiJFeNN9yXWE+JE QcuO0Tb2YLubpKvt1CZYUWo9tAzgA5ZXIXKo+clA2/ED3ZeK2waEV3fby65U760MI0RakCll 9+Ncfbx380nda87/3zLayAi548f5p+VdcwxXCJVA61OgXrSek/EzmsryT3N7h6tS2WwhAAAA AAAA --------------ms020900000205040000040806-- --===============1329060114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1329060114==-- From ipfix-bounces@ietf.org Wed Apr 30 02:50:14 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFF63A6D79; Wed, 30 Apr 2008 02:50:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5493A6D71 for ; Wed, 30 Apr 2008 02:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4gtgUkZtFto for ; Wed, 30 Apr 2008 02:50:12 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 11DD03A6C4E for ; Wed, 30 Apr 2008 02:50:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,727,1199682000"; d="scan'208";a="105277969" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Apr 2008 05:50:12 -0400 X-IronPort-AV: E=Sophos;i="4.25,727,1199682000"; d="scan'208";a="195316052" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 05:50:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 11:50:10 +0200 Message-ID: In-reply-to: <48092D82.6060805@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Implementation Guidelines published !!! Thread-Index: Acihq+hmU+OekT31Riex7zjFNAczNgI+57Iw References: <48092D82.6060805@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Nevil Brownlee" , "IPFIX list" Subject: Re: [IPFIX] Implementation Guidelines published !!! X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Congratulations indeed for the good work. Dan > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] > On Behalf Of Nevil Brownlee > Sent: Saturday, April 19, 2008 2:24 AM > To: IPFIX list > Subject: [IPFIX] Implementation Guidelines published !!! > > > Hi all: > > It's wonderful to see RFC 5153, IPFIX Implementation > Guidelines, published. Congratulations to all those involved > (and that includes everyone who took part in the > interoperability testing events!) > > 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 > > _______________________________________________ > 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 ipfix-bounces@ietf.org Wed Apr 30 02:50:14 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFF63A6D79; Wed, 30 Apr 2008 02:50:14 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5493A6D71 for ; Wed, 30 Apr 2008 02:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4gtgUkZtFto for ; Wed, 30 Apr 2008 02:50:12 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 11DD03A6C4E for ; Wed, 30 Apr 2008 02:50:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,727,1199682000"; d="scan'208";a="105277969" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Apr 2008 05:50:12 -0400 X-IronPort-AV: E=Sophos;i="4.25,727,1199682000"; d="scan'208";a="195316052" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 05:50:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 11:50:10 +0200 Message-ID: In-reply-to: <48092D82.6060805@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Implementation Guidelines published !!! Thread-Index: Acihq+hmU+OekT31Riex7zjFNAczNgI+57Iw References: <48092D82.6060805@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Nevil Brownlee" , "IPFIX list" Subject: Re: [IPFIX] Implementation Guidelines published !!! X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Congratulations indeed for the good work. Dan > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] > On Behalf Of Nevil Brownlee > Sent: Saturday, April 19, 2008 2:24 AM > To: IPFIX list > Subject: [IPFIX] Implementation Guidelines published !!! > > > Hi all: > > It's wonderful to see RFC 5153, IPFIX Implementation > Guidelines, published. Congratulations to all those involved > (and that includes everyone who took part in the > interoperability testing events!) > > 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 > > _______________________________________________ > 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 ipfix-bounces@ietf.org Wed Apr 30 05:15:54 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92B03A6CB7; Wed, 30 Apr 2008 05:15:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962173A6B72 for ; Wed, 30 Apr 2008 05:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxu6HWTl57a3 for ; Wed, 30 Apr 2008 05:15:52 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 521B53A6917 for ; Wed, 30 Apr 2008 05:15:52 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m3UCFrgH015462 for ; Wed, 30 Apr 2008 14:15:53 +0200 Message-ID: <48186300.8000104@informatik.uni-tuebingen.de> Date: Wed, 30 Apr 2008 14:16:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "ipfix@ietf.org" X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.11; VDF: 7.0.3.232; host: mx05) Subject: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075982093==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1075982093== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030409020609040805040906" This is a cryptographically signed message in MIME format. --------------ms030409020609040805040906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, The IPFIX-MIB specifies: ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "On Exporters this object contains the number of packets after which IPFIX Templates MUST be resent by the Exporter. On Collectors this object contains the lifetime in number of packets after which a Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be 0." DEFVAL { 0 } ::=3D { ipfixTransportSessionEntry 11 } (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) Isn't the description ambiguous? "On Exporters this object contains the number of packets after which IPFIX Templates MUST be resent by the Exporter." What is meant by "packets" in this context? - packets observed? - packets accounted? I assume it is the number of IPFIX Messages exported, right? Then, the description should be changed accordingly. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030409020609040805040906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDQzMDEyMTYwMFowIwYJKoZIhvcNAQkEMRYEFBt3bvvSl6/z 8e57JObk5Rek5Y9uMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQB+BIwY2subVocIXBsEHbivoxftwaEiJ+hPeE9TusKMoZtnab/yhUryOc5S h1vQedGfKhUOrDAa2VE3kAUMoubQxEsEse3OzG4UhluFY052ezyGFy3QlIfkCcYLSGBOM4L3 GbGRrINS+XIlwfCdSJYCQILjCE35nSls3fdR1YVusFp3vHbmsjBzwh+rD5IT//MCNvvZO+27 Zc5IropYII/OK6EVOMJuwtVGoHmkWCoJvyeoLdwdyo6O7TFiR07qR6fw8tmOheVK63Ucm4/K mJq7wEpJ7+u0e9v5jsLFfh66NNi30VWCrkmNM3VzGH+djMbilguWF3gT/7hc/zAtN/vAAAAA AAAA --------------ms030409020609040805040906-- --===============1075982093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1075982093==-- From ipfix-bounces@ietf.org Wed Apr 30 05:15:54 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92B03A6CB7; Wed, 30 Apr 2008 05:15:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962173A6B72 for ; Wed, 30 Apr 2008 05:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxu6HWTl57a3 for ; Wed, 30 Apr 2008 05:15:52 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 521B53A6917 for ; Wed, 30 Apr 2008 05:15:52 -0700 (PDT) Received: from [134.2.172.138] (u-172-c138.cs.uni-tuebingen.de [134.2.172.138]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m3UCFrgH015462 for ; Wed, 30 Apr 2008 14:15:53 +0200 Message-ID: <48186300.8000104@informatik.uni-tuebingen.de> Date: Wed, 30 Apr 2008 14:16:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "ipfix@ietf.org" X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.11; VDF: 7.0.3.232; host: mx05) Subject: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075982093==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1075982093== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030409020609040805040906" This is a cryptographically signed message in MIME format. --------------ms030409020609040805040906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, The IPFIX-MIB specifies: ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "On Exporters this object contains the number of packets after which IPFIX Templates MUST be resent by the Exporter. On Collectors this object contains the lifetime in number of packets after which a Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be 0." DEFVAL { 0 } ::=3D { ipfixTransportSessionEntry 11 } (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) Isn't the description ambiguous? "On Exporters this object contains the number of packets after which IPFIX Templates MUST be resent by the Exporter." What is meant by "packets" in this context? - packets observed? - packets accounted? I assume it is the number of IPFIX Messages exported, right? Then, the description should be changed accordingly. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030409020609040805040906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDQzMDEyMTYwMFowIwYJKoZIhvcNAQkEMRYEFBt3bvvSl6/z 8e57JObk5Rek5Y9uMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQB+BIwY2subVocIXBsEHbivoxftwaEiJ+hPeE9TusKMoZtnab/yhUryOc5S h1vQedGfKhUOrDAa2VE3kAUMoubQxEsEse3OzG4UhluFY052ezyGFy3QlIfkCcYLSGBOM4L3 GbGRrINS+XIlwfCdSJYCQILjCE35nSls3fdR1YVusFp3vHbmsjBzwh+rD5IT//MCNvvZO+27 Zc5IropYII/OK6EVOMJuwtVGoHmkWCoJvyeoLdwdyo6O7TFiR07qR6fw8tmOheVK63Ucm4/K mJq7wEpJ7+u0e9v5jsLFfh66NNi30VWCrkmNM3VzGH+djMbilguWF3gT/7hc/zAtN/vAAAAA AAAA --------------ms030409020609040805040906-- --===============1075982093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1075982093==--