Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt

From: Brian Trammell <[email-masked]>
Date: Tue, 11 Feb 2014 15:54:55 +0100

Greetings, all,

This revision addresses WGLC comments to date; left open is the representation of boolean-true and boolean-false, which I’ve kept at the literal integer values “1” and “0” respectively, because it’s not clear to me there’s a better resolution that’s consistent with the rest of the document.

WGLC continues up to the 14 Feb deadline.

Best regards,

Brian

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-ietf-ipfix-text-adt-01.txt
> Date: 11 Feb 2014 15:51:58 GMT+1
> To: "Brian Trammell" <[email-masked]>, Brian Trammell <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-ipfix-text-adt-01.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
> 
> Name:		draft-ietf-ipfix-text-adt
> Revision:	01
> Title:		Textual Representation of IPFIX Abstract Data Types
> Document date:	2014-02-11
> Group:		ipfix
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-01
> 
> Abstract:
>   This document defines UTF-8 representations for IPFIX abstract data
>   types, to support interoperable usage of the IPFIX Information
>   Elements with protocols based on textual encodings.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Paul Aitken <[email-masked]>
Date: Tue, 11 Feb 2014 20:32:11 +0000

Brian, some suggestions:

1. true = 1, false = { anything else }

     - works with both the usual 0/1 convention and the IPFIX 1/2 convention

2. true = "true", false = "false"

     - quite unambiguous

3. true = "t", false = "f"

     - shorter

P.

On 11/02/2014 14:54, Brian Trammell wrote:
> Greetings, all,
>
> This revision addresses WGLC comments to date; left open is the 
> representation of boolean-true and boolean-false, which I've kept at 
> the literal integer values "1" and "0" respectively, because it's not 
> clear to me there's a better resolution that's consistent with the 
> rest of the document.
>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-ietf-ipfix-text-adt-01.txt*
>> *Date: *11 Feb 2014 15:51:58 GMT+1
>> *To: *"Brian Trammell" <[email-masked] 
>> <mailto:[email-masked]>>, Brian Trammell 
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-ietf-ipfix-text-adt
>> Revision:01
>> Title:Textual Representation of IPFIX Abstract Data Types
>> Document date:2014-02-11
>> Group:ipfix
>> Pages:13
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>
>
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Tue, 11 Feb 2014 22:11:33 +0100

>     - works with both the usual 0/1 convention and the IPFIX 1/2 convention

Much as I hate to propogate the idea the "2 is false" is anything other than a terrible, terrible idea, I like the approach. The issue I have with it is that the string "true" is false, which seems error-prone; the bigger issue I have with it is that every other type has a set of acceptable values and a set of unacceptable values. We don't for example say that any unparseable string for an unsigned8 is 0.

I'd be slightly more okay with this being encoded as an unsigned8, where 0 is false and any nonzero value is true, but this means we have two different encodings one of which has "2 is false" and the other has "2 is true", and I don't like that either.

We could say true = 1 and false = 0 | 2 but then we need to explain that we're carrying forward something from 7011 encoding, which we do for no other type.

> 3. true = "t", false = "f"

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.

Thanks, cheers,

Brian

>>> Name:
>>>  draft-ietf-ipfix-text-adt
>>> Revision: 01
>>> Title:
>>> 
>>>               
>>>  Textual Representation of IPFIX Abstract Data Types
>>> Group:
>>>  ipfix
>>> Pages:
>>>  13

---

From: Paul Aitken <[email-masked]>
Date: Tue, 11 Feb 2014 21:32:20 +0000

Brian,

Aside from the fact that this is English-specific, it works for me.

P.

---

From: Andrew Feren <[email-masked]>
Date: Fri, 14 Feb 2014 18:44:21 +0000

Hi Paul and Brian,

This works for me too.

FWIW I think worrying about this one tiny instance being English specific is way too little too late.  When we start translating the IE names, IE descriptions, data type names, data semantic names, etc. then we can worry about if boolean values need some internationalization.

-Andrew
________________________________________
From: IPFIX [[email-masked]] on behalf of Paul Aitken [[email-masked]]
Sent: Tuesday, February 11, 2014 4:32 PM
To: Brian Trammell
Cc: IPFIX Working Group
Subject: Re: [IPFIX] Fwd: New Version Notification for  draft-ietf-ipfix-text-adt-01.txt

Brian,

P.