Re: [tcpm] [IPFIX] WG LC: IPFIX documents

["Aitken, Paul" <[e-mail]>]

Med,

   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP Flow Information Export (IPFIX) Entities (iana.org) [iana.org]<https://urldefense.com/v3/__https://www.iana.org/assignments/ipfix/ipfix.xhtml__;!!OSsGDw!PbyTGwK6ng1xsDx7EDsqY-zP5SN-siBTe9ltLeN6whqtHew5I4J3MgqA7QOaYGnkTWnF4w1wMldDkBYIpjb9XwrB$> (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs having data semantic of flags.

It is consistent but wrong, as the numeric value of these fields is meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" value.


    5.  An Example

   Given UDP kind allocation in Section 10 of
   [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
   Section 4.1,

Section 4.1 of what?
[Med] of this document.

Please write that for clarity.


The octetArray type is especially confusing as these are really hextetArrays.

[Med] Not sure we need a new data type here as octeArray is defined as follows:
   The octetArray data type has no encoding rules; it represents a raw
   array of zero or more octets, with the interpretation of the octets
   defined in the Information Element definition.

The draft proposes the encoding not of octets, but of 16-bit values. Therefore it's not an "array of zero or more octets" but rather, an "array of zero or more hextets".

P.