Subject: [ipfix] Re: WG process, 18 Feb teleconference minutes

From: [email-masked]
Date: Wed, 20 Feb 2002 08:53:39 -0800 (PST)

Hello everyone:

Responding to the "what's going on" postings on the list:

As you all know from my last few 'WG cochair' postings, the co-chairs
convened an 'editorial' teleconference to clarify what should be in
each the Architecture and Data Model drafts, and make sure they get 
submitted on time.  I realise that my selection of a small editorial
team (only 5 people) was arbitrary, it was only intended to get the
drafts safely submitted before the Minneapolis cutoff date, 22 February.

Recommendations from the teleconference (full minutes follow below):

 - Need to focus energy on charter goals at this stage. Co-chairs
   will summarise / moderate the mailing list discussions, and
   produce lists of 'current issues' from time to time.
 
 - WG should consider making an 'Applicability' draft covering
   'how to use IPFIX,' in more detail than will fit comfortably
   in the Architecture document.
 
 - WG should consider moving the 'middleboxes' material from the
   Architecture document (it's not mentioned in the WG charter)
   into a new draft.
 
 - Configuration.  Not in charter, at this stage we need to
   document what current flow export systems do. (other 'not-in-charter'
   things include 'what's not done well in existing flow export systems')
 
 - 'Protocols' material in Architecture document.  Our charter
   says we need to select a protocol.  We propose to start by 
   listing requirements, with reference to exisiting systems (as
   documented in their various Internet Drafts).  When we have 
   consensus on these requirements we will be able to evaluate
   the various protocols.
 
 - The 'Data Model' draft is really a combined information and data model,
   i.e. it defines a traffic flow (a set of packets which share common
   values from some attributes) and gives clear definitions for all
   the attributes supported in current flow export systems, together
   with brief encoding details for each attribute (e.g. using SNMP
   textual conventions).  It does not say how a complete flow is
   to be encoded into a complete packet, that belongs in the Architecture
   document.  Furthermeore, the data model details do not cover data 
   elements of the "control" traffic (like message formats) only the 
   flow information itself.
 
 - Architecture and Data Model drafts need IANA Considerations
   and Security Considerations sections.
 
 - Document editors.  Teleconference believes each of the new
   documents should have two editors (on the title page), and a list
   of authors (i.e. all those who supplied text for the document)
   and their companies in a suitable section of the document.
   Suggested editors: Architecture - KC, Ganesh
                      Data Model - KC, Paul
 
Your co-chairs are working on agenda for the Minneapolis meeting. 
They encourage everyone to continue discussion on the list!

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

Thanks to Cisco for arranging and hosting the conference call.
A list of those that participated follows the minutes below.

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

The call began Mon Feb 18 ~1100 CST 2002.

The conference call followed a rough list of agenda items introduced by
KC Norseth and the chairs.

The following topics were discussed:

 *) We began with a reminder that our charter should be the guide to
    what issues need to be addressed in the "Architecture" and "Data
    Model" documents.  We reviewed the following list of items from our
    charter, naming which document (REQuirements, DATA model,
    ARCHitecture) should address each:

    flow definition: req
    data encodings:  data
    packet sampling: req/data
    ...
    security:        all
    transport:       arch
    reliability:     all

    To limit the work for our document milestones, we mentioned that we
    should be careful not to "design the future" at this point, i.e.
    we are not chartered to design an entire IPFIX system.

 *) Regarding the "design team" arch and data documents, it was noted
    that "middleboxes" is not mentioned in the charter.  It should
    perhaps be moved/deferred to a yet-to-be-proposed document.

 *) It was noted that our focus for the discussion today is to prepare
    "-00" versions of teh drafts of arch and data by the end of the
    week.   We are not choosing which is "technically best" amongst the
    implementation proposals at this point.

 *) There was some discussion on the items currently in the early draft
    of the "Data Model" document.  It was generally agreed that this
    doucment should define data members in an
    implementation-independent way.  This led to some terminology
    discussions in which is was noted that our "Data Model" is also, or
    is instead, an Information Model document.

 *) We discussed our charter item regarding selecting a protocol
    (whether an existing transport or full flow-export implementation)
    and the chairs suggested that this be deferred for the time being.
    This will be proposed in the mailing list.

 *) We asked Benoit and Ganesh they were OK with the integration of
    portions of their B/G "IPFIX proposal" document at this point.  No
    issues were raised, and they agreed that its use as a source of
    input for the other documents was satisfactory.

 *) Renaming data model to informational model was proposed.  In
    general, throughout the discussion, this seemed generally accepted
    amongst the participants.  While this document has this new,
    hopefully clearer purpose, we will continue to refer to the
    document as the _data_ model.

    It was noted that some things that are in the current "Data Model"
    document don't belong there, if it is really an information model,
    with some minor encoding details (such as integer sizes and such).
    Specifically things such as version number fields, message formats
    and structures do'tn't belong in this document.

 *) It was asked which documents are responsible for specifying the
    "flow definition" (as mentioned in the charter).  It was proposed,
    and generally accepted, that the requirements document addresses
    the flow defintion as it should, and that additionally the data
    model doc should further qualify the flow defintion using the
    terminology and info/data model elements that it introduces.

 *) We discussed, at some length, which sections of the existing
    documents could be be moved to applicability document(s).  Further
    discussion on this issue should continue in the mailing list.

 *) It was proposed that it is the Architecture document that may
    ultimately have the message encodings on the wire and such, so that
    material will be removed from the data document.

 *) It was proposed that the architecture document talk about how you export
    or act upon the flow info that is assembled in terms of things defined in
    informational model.

 *) Where does information abelong bout how the thing is configured?
    This is out-of-scope... w/regard to current practice there is no
    communication of this information.  (negotiation of what the exporter
    is doing is out-of-scope but not necessarily what the collector is
    capable of)  It was agreed that this is still a hot issue in the list...

 *) The chairs were asked to participate more in the mailing list to
    raise a warning when long discussions about topics that are not in
    the charter are drawing the pariticipants efforts away from our
    focus.

 *) It was noted that after another Requirements document revision, and
    discussion in Minneapolis, the requirements doc will probably
    be about two months behind the scedule originally proposed.
    We'll aim for last call in April.

 *) Packet sampling was discussed - because it is in our charter.  It
    was suggeste that sampling belongs, at least, in the data model
    document.  Possibly also in the architecture, but as yet it is
    unknown to what degree.

    To constrain this portion of the effort from leading to undue
    complications, it was suggested that we address it to the point
    that packet sampling is used in existing practice.

    Dave Plonka volunteered to proposed (in the public mailing) list
    how this should be addressed in the existing docs.

 *) It was proposed that the current architecture doc should add a
    section that defines what the selection criteria will be for an
    IPFIX transport protocol.

 *) Terminology - Requirements draft will contain a subset of all 
    requirements, Architecture and data will have their own terminology

 *) Limit arch and info/data model to what the charter requires
    (section 8 of arch pretty much goes out)

 *) We discussed who should be listed as "Authors" or "Editors" of the
    existing "design team" draft documents.  It was noted that the IESG
    suggest that it only be a short list, and our current list is not
    suitably short.

    It was proposed that only the document editors be specified at the
    top of the documents, and that all the other authoring participants
    be acknowledged in an "Authors" section of each document.

    The chairs asked that we attempt to choose select just two people
    to be the editor for each document.  Also, it was noted that the
    editors must be able to cooperate with each other.

    For the Requirements document, Juergen said the authors would
    discuss this soon, such as on Feb 19.

    For the Architecture document, KC and Ganesh have been proposed.

    For the Data Model, KC and Paul Calato have been proposed. 

 *) Participating authors will suitably credited in an "Authors"
    section, perhaps in addition to others in the usual
    Acknowledgements section.

We signed off from the call Mon Feb 18 ~1300 CST 2002

The following participated in the conference call:

   KC Norseth
   Ganesh Sadasivan
   Benoit Claise
   Dave Plonka
   Paul Calato
   Juergen Quittek
   Nevil Brownlee

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

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