Subject: [ipfix] Information Model Issue list

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 21 Nov 2003 13:09:46 -0800

Hi,
 
  I've compiled the set of issues from the various e-mails since v01 of the
Information Model draft.
 
  I'm attaching the current list below, but will also be sending each one
out as its own subject with "[issue]" beginning the subject line, so that
scanning the e-mail archive to find issues (opened or closed) will be easier
this way.  As well as to group responses to the issue.
 
  Also in the next v02 draft, I intend to add an appendix with the Change
history.  I expect this to come out before Thanksgiving.
 
Regards,
 
  Jeff Meyer

draft-ietf-ipfix-info-01.txt  Issue List  (Nov. 21, 2003)
 
Issue:  INFO-17  Variant Field Types
Description: 
  - allow in encoding, make explicit in information model.
    Motivation is if known integer quantities for a given exporter
    are in a smaller range, fewer bytes can be used to send across
    the wire.
    
    A consumer should be made aware of the largest size any compliant
    should export - (information model)
  
  http://ipfix.doit.wisc.edu/archive/1935.html
<http://ipfix.doit.wisc.edu/archive/1935.html> 

Issue:  INFO-18   Field semantics (counters vs. quantities)
Description: 
  Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?) 
   - explicitly distinguish between the two.  However, when it comes to
     storing results, e.g. to do reporting, a counter is pretty much
     useless (i.e. a collector will likely turn a counter into an
     integer).
     
   - Counters may NOT have a variable length, as this makes wrap 
     calculation problematic.
     
   - Needs discussion in protocol encoding section.  I.e. something like:
   
      When specifying field length in templates an implementation MAY
      chose to specify a length shorter than that associated with the
      declared integral information element type from the information model.
      This can reduce overall message lengths when a particular 
      implementation knows it will only encounter values in a smaller
      range which can fit in fewer bytes.
      
      Sizes should be downgraded in powers of two in bytes:  i.e. 
      1, 2 or 4.  Currently there are no integral types greater than 
      8 bytes.  If these come into vogue then downgrading from 16 to
      8 say would also be an option.
 
  http://ipfix.doit.wisc.edu/archive/1981.html
<http://ipfix.doit.wisc.edu/archive/1981.html> 

Issue:  INFO-19  Timestamps
Description: 
  http://ipfix.doit.wisc.edu/archive/2056.html
<http://ipfix.doit.wisc.edu/archive/2056.html> 
  
  - various resolutions and encoding formats can be specified:
    o seconds      - 32 bit since EPOCH
    o milliseconds - 64 bit since EPOCH  (no rollover)
    o microseconds - ?
    o nanoseconds  - ? ** Use for NTP **
    o NTP format  - 232 picosecond resolution (1/2**32)
    
    Encoding options include:
    
      - simple 32-bit time (sec)
      - simple 64-bit time (msec)
      - high res 32-bit time (m or usec) relative to header time
      - very high res 2*32-bit time in NTP format sec.fraction
    
  Alternate interpretation from Simon Leinen:
  
    http://ipfix.doit.wisc.edu/archive/1928.html
<http://ipfix.doit.wisc.edu/archive/1928.html> 
    
  Doesn't want absolute time, but some relative, i.e. are we wasting the
  32-bits?  This seems like an encoding/protocol vs. information model
  issue.
  
  More from Simon:
  
        http://ipfix.doit.wisc.edu/archive/1927.html
<http://ipfix.doit.wisc.edu/archive/1927.html> 
 
  Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
  
  struct timespec{
          time_t tv_sec;          /*seconds*/
          long    tv_nsec;        /*nanoseconds*/
  };

  Effectively similar to NTP time, although your divisor for the 
  second factor is 10**9 vs. 2**32

Issue:  INFO-20  Separate Normative from Informative References
Description:  many current RFC's separate Normative from Informative
References,
 although it is not currently required by RFC2223 (see section 8.
"References Section"

INFO-20  Use of signed versus unsigned
 
  Description:  Many of the items in the information model specify signed
quantities,
   when these values will never go below zero.  Call them out as unsigned:
   
  - Sign bit on AS numbers x
 
  http://ipfix.doit.wisc.edu/archive/1931.html
<http://ipfix.doit.wisc.edu/archive/1931.html> 
  
  Should be unsigned not int, but may move from 16 to 32 bits.
  
  - Sign and direction on counters x
 
  http://ipfix.doit.wisc.edu/archive/1930.html
<http://ipfix.doit.wisc.edu/archive/1930.html> 
  
  Is there ambiguity in current statements?  Should these be unsigned
quantities?
  
  - ProtocolIdentifier should be of type unsignedByte x
  
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
    
  currently this is of type int.
        
  - ClassOfService should be unsigned byte v. byte x
  
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  - RFC791 and RFC1883?
  
  TcpControlBits should be an unsigned byte x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 

  - SamplingInterval should be unsignedInt x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 

  - SamplingAlgorithm as unsignedShort x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 

  - FlowEndState as unsigned (int or short) x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  - IfIndex (egress and ingress) can be 2**32 x
 
  http://ipfix.doit.wisc.edu/archive/1929.html
<http://ipfix.doit.wisc.edu/archive/1929.html> 
  
  reference RFC2863

Issue: INFO-21 FlowCreationTime/EndTime ids should be swithced 22<->23 x
Description:
  transcription error from NFv9.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 

Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
Description
  the flow label field only has 20 bytes allocated to it.  Hence it doesn't
  need a full int.  Is this an issue, or simply indicate this fact in
  info model.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html>   

Issue: INFO-23  Explicit IP version in message
Descriptin:
  Should IP version be explicit in the flow or implied by the type of 
  address element passed?  For now it will remain implicit.  Although
  could introduce a byte or short information element called ipVersion,
  which would have either 4 or 6 as meaningful values.
 
  http://ipfix.doit.wisc.edu/archive/1920.html
<http://ipfix.doit.wisc.edu/archive/1920.html>