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 14:50:02 -0400

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/

---

From: Mark Fullmer <[email-masked]>
Date: Tue, 29 Apr 2003 17:53:15 -0400

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