Subject: RE: [ipfix] drawing the line between protocol and data model docu ment

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 29 Apr 2003 18:25:11 -0400

Mark,

  I'll try to clarify:

  Concept #1:  The information model and the encoding are separate.
   A well defined mapping determines how an information model is
   to be encoded for a specific use (e.g. IPFIX).  The encoding
   may take whatever approach allows both ends to do something
   useful with the data.  As you point out there is some useful
   stuff which can be done with the length alone.

  Concept #2:  Derived typing.  By defining a base set of types,
   which must be understood, derived types can be defined in terms
   of these base types.  For instance Diameter does this.  This
   enables a core set of types to be defined and coded to, but
   also enables richer types later on with an appropriate fallback
   for systems which aren't aware of the extensions.

  The benefit I see of explicit typing is that instead of seeing
that a field is of length "4 bytes" something which will be seen
A LOT.  Is that we can instead differentiate between IPAddr, Integer,
unsigned integer, and float.  This seems handy to me.

  Your argument seems centered around the long term potential of
adding lots of fixed length fields whose base length is not 4,8
or 16 bytes long, for instance MACAddr (although if we agree on
going the type route, I'd recommend adding MACAddr and then you
have 1,2,4,6,8 and 16 bytes covered.  I guess I don't foresee
a lot more fixed length fields coming down the pipe in the IPFIX 
domain.  Hence my desire to make it more explicit for the types 
which do occur all the time and are likely points of extension.  
WHY?  Because then a tool could at least present these in a meaningful
way.  As opposed to incorrectly formatting a float type as an int.

  But hey, either way will work.  If the goal is to limit the
amount of changes, I'll (grudgingly) go along.  I haven't heard
any opinions from anyone but you in either direction.  So,
at this point I don't see a quorom either way...

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Mark Fullmer [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 2:53 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: [email-masked]
> Subject: Re: [ipfix] drawing the line between protocol and data model
> docu ment
> 
> 
> IMHO crippling the protocol to serve the needs of a documentation tool
> is just silly.
> 
> It would be possible to use both a Type name and a Length instead of
> the existing Length, which would allow a collector to process
> unknown Types.
> 
> With the existing v9 protocol a collector can ignore an 
> unknown attribute,
> or possibly just pass it on to post processing tools which 
> might understand
> it.
> 
> Your suggested changes no longer allow a collector to ignore unknown
> attributes if the Type is also unknown.  Resorting to encoding all
> new Types after the initial protocol spec as octet strings is (IMHO)
> not acceptable.
> 
> I'm still trying to understand what the benefits to explicit 
> Types sent
> in templates are.
> 
> mark
> 
> On Tue, Apr 29, 2003 at 02:50:02PM -0400, MEYER,JEFFREY D 
> (HP-Cupertino,ex1) wrote:
> > Juergen,
> > 
> >   I agree that the data model should have a well defined type
> > system.   And that that typing system should reflect the 
> requirements.
> > 
> >   This is in part why I was hoping that the protocol itself would
> > be more explicit here.  (See my mail
> > http://ipfix.doit.wisc.edu/archive/1604.html)
> > 
> >   There is also a type list in that mail.  However, I would suggest
> > using the names from XML-Schema part 2 Data types, as this would
> > facilitate creating a formal/normative definition, versus 
> reinventing
> > names for the types.
> > 
> >   Here are the type names from XML-Schema/IPDR:
> > 
> >      boolean      - true/false (may be encoded in byte)
> >      byte
> >      unsignedByte
> >      short
> >      unsignedShort
> >      int          - 32-bit signed
> >      long         - 64-bit signed
> >      unsignedInt
> >      unsignedLong
> >      float
> >      double
> >      dateTime     - 32-bit integer representing seconds since EPOCH
> > (1/1/1970 0:00 GMT)
> >      string       - UTF-8 formatted text
> >      ipdr:dateTimeMsec - 64-bit integer representing msecs 
> since EPOCH
> >      ipdr:ipV4Addr
> >      ipdr:ipV6Addr
> >      ipdr:UUID
> >      hexBinary    - arbitrary sequence of octets
> >    
> >   If the protocol itself has a basic "octetString" (or from 
> XML, hexBinary)
> > payload,
> > then this can be used to carry new classes of information 
> in the future w/o
> > rejiggering the protocol itself.
> > 
> >   In addition other "derived" types may be created from the 
> base types.  For
> > instance in IPDR, the ipdr:dateTimeMsec is derived from long.
> > 
> > Regards,
> > 
> >   Jeff Meyer
> > 
> > > -----Original Message-----
> > > From: Juergen Quittek [mailto:[email-masked]]
> > > Sent: Monday, April 28, 2003 2:06 PM
> > > To: [email-masked]
> > > Subject: [ipfix] drawing the line between protocol and data model
> > > document
> > > 
> > > 
> > > Hi all,
> > > 
> > > When shaping the planned documents, we have to draw a line
> > > between the protocol and the data model.
> > > 
> > > Definitely, the data model document defines all field types,
> > > but does it also define basic data types, such as '16 bit
> > > unsigned integer'?
> > > 
> > > Maybe we should have a set of basic data types defined in
> > > the protocol document and restrict the data model doc to 
> these types?
> > > This would further structure the data model.
> > > 
> > > Any thoughts?
> > > 
> > >     Juergen
> > > 
> > > --
> > > 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/
> > > 
> > 
> > --
> > 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/
> 

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