Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs. quant ities)

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 24 Nov 2003 11:37:54 -0800

Stewart,

  How about "An identifier SHOULD be unsigned."  The way I view it, a signed
32-bit integer encoded as 0xFFFFFFFF is not the same identifier as the
unsigned 32-bit integer encoded as 0xFFFFFFFF.  Sequence numbers used to a
relative point in a series might make use of the signed property:  e.g. 30,
29, 28 .. 0, -1, -2 ..  The identifier -2 means something different than the
identifier 2.  

  I agree, signed is the exception rather than the norm, but I'd prefer not
to exclude this possible distinction by saying MUST.

-- Jeff

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, November 24, 2003 2:33 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Tal Givoly'; 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-18 Field semantics (counters vs. quant
ities)

4.21.3 Identifier

An integral value which serves as an identifier. Specifically mathematical 
operations on two identifiers (aside from the equality operation) are 
meaningless. E.g. Autonomous System Id 1 * Autonomous System Id 2 is
meaningless.

SB> An identifier is an unsigned object.

Stewart

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Tal,
>  
>   Take a look at the text in the current draft:
>  
>    
>
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#
anchor25
>  
>   Around Integer Semantic Qualifiers.  The terms I chose were:
>     - quantity
>     - counter
>     - identifier
>     - flags
>  
>   I did not use guage.  I don't think the definitions of counter, 
> identifier or flags or their names should be too contentious.
>  
>   The definition I used for quantity sounds in line with the discussion 
> in your e-mail.  However, the name "quantity" may be up for debate.  
> Note however I indicate that "quantity" is the default semantic when 
> none is specified.  So in the information model, these show up as 
> unqualified integral types (byte, unsignedByte, short, unsignedShort, 
> int, unsignedInt, long, unsignedLong).
>  
>   There are currently no counters identified in the information model.  
> Proposing some of these would probably be appropriate.  e.g. 
> byteCounter, droppedPacketCounter, etc. for applications which benefit 
> from counter vs. quantity semantics (i.e. not classic NF, maybe exported 
> flow aggregates, or meter statistics).
>  
> Regards,
>  
>   Jeff Meyer
> 
>     -----Original Message-----
>     From: Tal Givoly [mailto:[email-masked]]
>     Sent: Saturday, November 22, 2003 3:14 PM
>     To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
>     Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs.
>     quantities)
> 
>     Jeff,
>      
>     I don't believe that "gauge", "quantities" or "identifiers" are good
>     enough one-word-descriptions for "delta values" we refered to
>     sometimes as "integers". I made an earlier recommendation on
>     terminology and didn't see any response (also see
>     http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html ).
>      
>     Tal
> 
>         -----Original Message-----
>         From: majordomo listserver
>         [mailto:[email-masked]]On Behalf Of MEYER,JEFFREY D
>         (HP-Cupertino,ex1)
>         Sent: Friday, November 21, 2003 1:12 PM
>         To: 'Ipfix Wg' (E-mail)
>         Subject: [ipfix] [issue] INFO-18 Field semantics (counters vs.
>         quantities)
> 
>         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
>          

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