Subject: [ipfix] Drafts: state after WG Last Call

From: Nevil Brownlee <[email-masked]>
Date: Tue, 12 Jul 2005 09:27:44 +1200

Hi all:

Our WG Last Call prompted a good discussion on the IPFIX list, resulting
in quite a few small, editorial (better explanations, tidying up, etc)
changes to the drafts, none of which I believe are sufficient to require 
another WG Last Call.  The current versions are:

     Architecture  08.txt
 **  Protocol      16.txt
 **  Info          08.txt
 **  AS            06.txt

If you have any last-minute comments on the drafts, please post them to 
the IPFIX list now.  Unless any show-stopper issues are raised, I intend 
to submit them to IESG for publication as RFCs this Thursday, 14 July 05.

Cheers, Nevil  (IPFIX co-chair)

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
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: Juergen Quittek <[email-masked]>
Date: Tue, 12 Jul 2005 01:22:27 +0200

Nevil,

Unfortunately, there is a one more small issue.

Caused by a misunderstanding between me and the Cisco people,
the encoding of the new Information Elements ipDiffServCodePoint
and ipPrecedence is wrong in the current version.

I already fixed it and submitted an update of the info model draft.
I hope the update (version -09) will be posted until Thursday.

The applied changes are documeted below:

OLD
5.3.18  ipDiffServeCodePoint

   Description:
      The value of a Differentiated Services Code Point (DSCP).  The
      DSCP value is encoded in the first 6 bits of the IPv4 TOS field or
      the IPv6 Traffic class field, respectively.
      For a particular Flow or packet, this Information Element may have
      the same value as Information Element ipClassOfService.  However,
      the bits that are not used by the Differentiated Services Field
      for specifying a DiffServ Code Point (DSCP) are to be ignored.
      This is relevant when the DSCP serves as flow key.  In this case
      the key consists of the first 6 bits.  The remaining 2 bits are
      not part of the flow key.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 195
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 2460 for the definition of the IPv6 Traffic Class field.  See
      RFC 2474 for the definition of the Differentiated Services Field.
NEW
5.3.18  ipDiffServCodePoint

   Description:
      The value of a Differentiated Services Code Point (DSCP) encoded
      in the Differentiated Services Field.  The Differentiated Services
      Field spans the most significant 6 bits of the IPv4 TOS field or
      the IPv6 Traffic class field, respectively.
      This Information Element encodes only the 6 bits of the
      Differentiated Services field.  Therefore its value may range from
      0 to 63.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 195
   Status: current
   Range: The valid range is 0-63.
   Reference: See RFC 3260 for the definition of the Differentiated
      Services Field.  See section 5.3.2 of RFC 1812 and RFC 791 for the
      definition of the IPv4 TOS field.  See RFC 2460 for the definition
      of the IPv6 Traffic Class field.

OLD
5.3.19  ipPrecedence

   Description:
      The value of the IP Precedence.  The IP Precedence value is
      encoded in the first 3 bits of the IPv4 TOS field or the IPv6
      Traffic class field, respectively.
      For a particular Flow or packet, this Information Element may have
      the same value as Information Element ipClassOfService.  However,
      the last 5 bits are to be ignored.  This is relevant when the
      ipPrecedence serves as flow key.  In this case the key consists of
      the first 3 bits.  The remaining 5 bits are not part of the flow
      key.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 196
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field and
      the IP Precedence.  See RFC 2460 for the definition of the IPv6
      Traffic Class field.
NEW
5.3.19  ipPrecedence

   Description:
      The value of the IP Precedence.  The IP Precedence value is
      encoded in the first 3 bits of the IPv4 TOS field or the IPv6
      Traffic class field, respectively.
      This Information Element encodes only the 3 bits of the
      Differentiated Services field.  Therefore its value may range from
      0 to 7.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 196
   Status: current
   Range: The valid range is 0-7.
   Reference: See section 5.3.3 of RFC 1812 and RFC 791 for the
      definition of the IP Precedence.  See section 5.3.2 of RFC 1812
      and RFC 791 for the definition of the IPv4 TOS field.  See RFC
      2460 for the definition of the IPv6 Traffic Class field.

Sorry,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de