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

From: Juergen Quittek <[email-masked]>
Date: Wed, 26 Feb 2014 10:18:42 +0000

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-masked]] 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-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Wed, 26 Feb 2014 10:48:28 +0000

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.

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.

P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 26 Feb 2014 13:01:31 +0100

hi Paul, Juergen,

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

> Juergen,
> 
> The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolean encoding definition, which says:
> 
> 6.1.5.  boolean
> 
>   Section 6.1.1, 
> with the value 1 for true and value 2 for false
> .
> 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

>>> From: IPFIX [
>>> mailto:[email-masked]
>>> ] On Behalf Of Paul Aitken

---

From: Brian Trammell <[email-masked]>
Date: Wed, 26 Feb 2014 12:50:21 +0100

hi Paul, Juergen,

Regards,

Brian

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 27 Feb 2014 08:42:41 +0000

Hi Paul,

You are right. It is another pro for the true="1" and false="2" encoding that it is in line with RFC 7011. Thank you for pointing out this issue and sorry for not having this in my previous email.  For developers it would be a step of convenience to have encodings in line and use the one from SMI and RFC7011. 

However, the textual representation addresses a larger community than just implementers. The textual representation is something that will be particularly interesting to people not very familiar with IPFIX encoding details. Here I think that the 1-2 encoding should not be used, because of its high potential to be not understood or misunderstood.

Cheers,
    Juergen

> From: Paul Aitken [mailto:[email-masked]]
> Sent: Mittwoch, 26. Februar 2014 11:48
> To: Juergen Quittek; Brian Trammell
> Cc: IPFIX Working Group
> Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt
> 
> Juergen,
> 
>    Section 6.1.1, with the value 1 for true and value 2 for false.
> 	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
> 
> 
> 
> 
>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 27 Feb 2014 08:48:47 +0000

Juergen,

Since there's potential for the 1/2 and "1"/"0" encodings to be 
confused, and since this is by definition a textual encoding, I'd prefer 
option 2 ("true", "false").

P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 27 Feb 2014 10:03:24 +0100

Paul, Juergen,

I'm okay with this. We can simply leave it unstated and up to reader implementers as to how much they want to follow the principle of liberal acceptance.

Cheers,

Brian

On 27 Feb 2014, at 09:48, Paul Aitken <[email-masked]> wrote:

> Juergen,
> 
> Since there's potential for the 1/2 and "1"/"0" encodings to be confused, and since this is by definition a textual encoding, I'd prefer option 2 ("true", "false").
> 
> P.
> 
>