Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt

Brian Trammell <[email protected]> Wed, 26 Feb 2014 12:50:21 +0100
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
hi Paul, Juergen,

On 26 Feb 2014, at 11:48, Paul Aitken <[email protected]> wrote:

> Juergen,
> 
> The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolean encoding definition, which says:
> 
> 6.1.5.  boolean
> 
>    The boolean data type is specified according to the TruthValue in
>    [RFC2579].  It is encoded as a single-octet integer per
>    Section 6.1.1, 
> with the value 1 for true and value 2 for false
> .
>    Every other value is undefined.
> 
> 
> Option 3 provides the benefits of consistency with RFC 7011, and no conversion required between the RFC 7011 and text-adt formats.

This is, pedantically speaking, not correct: the representation in IPFIX are 0x01 and 0x02, while the representation with text-adt for option 3 would be 0x31 (UTF-8 '1') and 0x32 (UTF-8 '2'). Conversion is necessary in any case, but you are correct that option 3 provides less opportunity for confusion when building transcoders than option 1.

> Expressed another way: the IPFIX WG group already decided the boolean encoding. Although we might not like that definition now, we should consistently use the same encoding across all the IPFIX RFCs.

I have to disagree here. As above, it's _not_ the same encoding. It's simply a _related_ encoding.

The IPFIX boolean encoding is _just barely_ explainable by reference to the SMI definition (which explicitly uses 0 for undefined, missing from the IPFIX definition); otherwise it is a clear error by violation of the principle of least surprise. It is _barely acceptable_ in that it is defined as a binary representation such that the expectation is that only developers debugging protocol implementations will be looking at the bits on the wire. (Indeed, as an aside, given the violation of the principle of least surprise, I would be interested to know how many implementations of IPFIX incorrectly export 0 for false and 1 for true.)

Carrying this encoding forward into a _human readable_ representation of the ADT would compound the error we made in 5101; here, as the intention is that the text-adt representations _are_ indeed understandable by people who are not IPFIX developers, the violation of the principle of least surprise would not, I think, be a defensible decision.

Option 2, "true" and "false" is a compromise position, recognizing that by using strings which do not collide with the binary encoding, we reduce the possibility of confusion that option 1 presents.

Regards,

Brian

> P.
> 
> 
> On 26/02/2014 10:18, Juergen Quittek wrote:
>> Dear all,
>> 
>> The open question is: What is the best textual encoding for Boolean values in flow records?
>> 
>> Here are the alternatives discussed so far:
>> 
>> 1. true: "1", false: "0"
>> Pro: very common, used by several programming languages, international (not language-specific)
>> Con:  0 may be misinterpreted as "don't know"
>> 
>> 2. true: "true", false: "false"
>> Pro: very common, unambiguous, used by several programming languages, 
>> Con:  not international: English language-specific
>> 
>> 3. true:"1", false: "2"
>> Pro: in line with SMI encoding for Booleans
>> Con: unknown outside of SNMP community. Not intuitively clear which is true and which is false
>> 
>> 4. true: "t"*, false: "f"*
>> Con: may be confusing or misleading.
>> 
>> Writing now as technical contributor, I would eliminate option #4 because I do not see any advantage of this alternative. #3 has only a weak "pro" being used by SMI.  Thus, we should either choose #1 or #2. Here, I would go for #1 because it is not language-specific.
>> 
>> Cheers,
>>     Juergen
>> 
>> 
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: IPFIX [
>>> mailto:[email protected]
>>> ] On Behalf Of Paul Aitken
>>> Sent: Dienstag, 11. Februar 2014 22:32
>>> To: Brian Trammell
>>> Cc: IPFIX Working Group
>>> Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-
>>> adt-01.txt
>>> 
>>> Brian,
>>> 
>>> Aside from the fact that this is English-specific, it works for me.
>>> 
>>> P.
>>> 
>>> 
>>> 
>>>> Aside from the fact that these aren't case-insensitive (which at least causes
>>>> 
>>> an error as opposed to a non-detected incorrect acceptance), I'd say we
>>> could combine these:
>>> 
>>>> true = ('t' | 'T') 0*ALPHA
>>>> 
>>>> false = ('f' | 'F') 0*ALPHA
>>>> 
>>>> i.e., the decoder only looks at the first letter for [tT] or [fF], probably with a
>>>> 
>>> note that "true" and "false" are the preferred encodings.
>>> 
>>> 
>>> _______________________________________________
>>> IPFIX mailing list
>>> 
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/ipfix
> 
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
signature.asc (application/pgp-signature, 496 B)