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

Brian Trammell <[email protected]> Sat, 1 Mar 2014 15:11:32 +0000
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
hi Juergen,

no, I mean, if a collector wants to try and interpret "t" as "true", then we leave that up to the certificate, and don't specify anything helpful in the document.

Cheers,

Brian

On 1 Mar 2014, at 14:52, Juergen Quittek <[email protected]> wrote:

> Hi Brian,
> What do you mean with "leaving it unstated"?
> Not fixing the textual encoding?
> Cheers,
>    Juergen
> 
>> -----Original Message-----
>> From: Brian Trammell [mailto:[email protected]]
>> Sent: Donnerstag, 27. Februar 2014 10:03
>> To: Paul Aitken
>> Cc: Juergen Quittek; IPFIX Working Group
>> Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt
>> 
>> 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 protected]> 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.
>>> 
>>> 
>>> On 27/02/2014 08:42, Juergen Quittek wrote:
>>>> 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
>>>> 
>>>>> -----Original Message-----
>>>>> From: Paul Aitken [mailto:[email protected]]
>>>>> 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,
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 
>>>>> 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)