Subject: [ipfix] info/data model status, con-call minutes

From: Dave Plonka <[email-masked]>
Date: Thu, 5 Jun 2003 10:48:56 -0500

IPFIXers,

I joined in on a conference call, to serve as scribe for minutes, on
this past tuesday with the editors of the IPFIX Information/Data Model
draft (formerly known as: draft-ietf-ipfix-data).

Below please find the minutes that I prepared, to keep the
WG/mailing-list participants up to date on the status of that
document.

Thanks,
Dave

----------------------------------------------------------------------

The call began Tue Jun  3 14:30 CDT 2003 and included the following
document editors Paul Calato, Jeff Meyer, Juergen Quittek, and
Dave Plonka served as the scribe.

The following topics regarding the Information/Data Model draft were discussed:

1) List of Attributes
   ------------------

   It was suggested that we discuss the procedure for selecting the
   list of flow attributes and to define what is the scope of the
   document concerning these attributes.

   It was noted that the draft-ietf-ipfix-data-01 document has expired
   (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-01.txt),
   and only the "-00" version is available here:

      http://ipfix.doit.wisc.edu/data/draft-ietf-ipfix-data-00.txt

   The editors considered whether it would be better to refer to it
   as the Information rather than Data Model.

   Juergen pointed out that there is an existing RFC (RFC3444:
   http://www.ietf.org/rfc/rfc3444.txt) "On the Difference between
   Information Models and Data Models" which should clear up the
   meaning and lead to a decision on this.

   [That RFC was left to be read afterward.]

   Generally, it was agreed that the document should describe which
   information elements (ie. flow attributes) map to which (primitive)
   IPFIX data types.

2) Structure of attribute specification (enumeration, data type, semantics)
   ------------------------------------

   It was generally agreed that basic data types should be defined as
   primitive types in the protocol specification draft.  However, there
   was some discussion as to how much type information should be in
   this document instead.

   It was noted that the chairs have been encouraging that the WG
   produce protocol specification document (slated for standards track)
   and a more often changing information/data model document.  This
   should enable new attributes to be added without the requirement to
   revise the base protocol specification document.

   Some participants suggested that they would like the this info model
   document to define both semantics and type, to make the protocol as
   general a "data carrier" as possible.

   It was mentioned however that the protocol specification should
   define the type and this info/data model document simply make
   normative references to those types as defined in that protocol
   spec.  This would reduce the chance of potentially conflicting
   definitions between the protocol and info/data model documents.
   Likely, the protocol spec. needs to completely define the encodings
   and all behavior (eg. overflow) for each type.

3) Template
   --------

   A possible template (such as an XML stanza) for flow attribute
   definitions was considered.

   Jeff offered a sample from IPDR:
      http://www.ipdr.org/documents/ipfix/infomodel/ipfix_info.xsd

   It was generally agreed that the flow attribute template should
   include the folling mandatory fields:

     a) Name, eg. name="sourceAddress"
     b) Type, eg. type="IPFIX:ipV4Addr"
              (types glommed from W3C XMLSchema + some ipdr add's)
     c) Semantics: eg. <annotation><documentation></documentation></annotation>
     d) ID

   also, the following option fields were recognized:

     e) Range, eg. a qualifier, perhaps more limiting than that of the primitive
     f) Enumeration, 1 => foo, 2 => bar, 3 => baz, etc.
        Enumeration and Range are mutually exclusive.
     g) Units, eg. packets, bytes,
     h) Reference: eg. BGP id from such-and-such RFC, etc.
     i) Vendor ID

   It was noted that enumerations have been defined by XML schema, and
   therefore that syntax might be a useful precedent.

   That said, it was also noted that ultimately the WG must care more
   about the text-rendered description rather than one that is XML
   coded, since our deliverably is a plain-text Internet Draft or RFC.

   The editors will explore defining the attributes in XML and rendering
   them to plain text suitable for the I-D.

   Regarding the optional Vendor ID, which has been suggested for
   extensibility, the editors will either include it (or not) in their
   next info/data draft revision and give the WG/mailing-list
   participants the opportunity to weigh-in either for (or against)
   that option.  Perhaps it should be called a Namespace rather than
   a Vendor?  It was thought to consider DIAMETER'S solution to this,
   with the default being the IETF-defined Vendor/Namespace (if none
   other is speicifed.)
   
4) XML-coded attribute description in appendix
   -------------------------------------------

   This topic was generally covered in previous discussion.  IPDR has a
   number of precedents for defining things based upon W3C-defined
   XML.  These might be used by the info/data document editors where
   appropriate/feasible.

5) Review of the existing attributes (defined in existing WG documents)
   ---------------------------------

   A volunteer was requested to review the existing flow attributes
   defined in the existing Requirements (draft-ietf-ipfix-reqs), Data
   Model (draft-ietf-ipfix-data), and NetFlow v9
   (draft-bclaise-netflow-9-00) documents, and to prepare a merged list
   for use by the document editors.

   Paul Calato accepted this responsibility.
   Jeff Meyer is willing to do the transliation of that list into XML.

   It was proposed that the flow attribute namespace be "camelback",
   which is initial lower-case and then upper-case as the first letter
   of subsequent words, eg. "ipV4Address".

   Dave Plonka offered to review RFC3470 ("Guidelines for the Use of
   Extensible Markup Language (XML) within IETF Protocols"), to
   determine whether or not we can make normative references to W3C
   documents (for the primitive types).  If not, what do we do instead?

   Paul agreed that it would be useful to annotate the list with info
   about the source for each attribute, to aid in the tracking of
   document changes.

   Following the production of this initial list, the info/data model
   document editors plan to identify what's missing, what's perhaps
   unnecessary, and get feedback from the WG participants.

6) Document submission schedule
   ----------------------------

   June 23rd deadline for new "-00" revision for the 57th IETF meeting.

   The editors plan to produce a new revision by that deadline, and submit
   it by either its new name (Information Model) or as the "-02" revision
   of the previous document named draft-ietf-ipfix-data (edited by Paul
   Calato and KC Norseth), which has since expired.

We signed off from the call Tue Jun  3 ~16:00 CDT 2003

----------------------------------------------------------------------

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/