Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.txt

From: [email-masked]
Date: Sun, 03 Aug 2014 22:07:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Flow Information Export Working Group of the IETF.

        Title           : Textual Representation of IPFIX Abstract Data Types
        Author          : Brian Trammell
	Filename        : draft-ietf-ipfix-text-adt-08.txt
	Pages           : 13
	Date            : 2014-08-03

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-08

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Trammell <[email-masked]>
Date: Mon, 4 Aug 2014 09:32:12 +0200

Greetings, all,

This revision addresses final IETF LC comments on extensibility and copy/paste errors in the examples (thanks, Paul)!

Best regards,

Brian

Begin forwarded message:

> From: [email-masked]
> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.txt
> Date: 4 Aug 2014 07:07:37 GMT+2
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Mon, 04 Aug 2014 09:04:30 +0100

Brian,

> This revision addresses final IETF LC comments on extensibility and copy/paste errors in the examples (thanks, Paul)!

You missed tcpControlBits: since it's defined as unsigned16 in [IANA], 
you should either use unsigned16 or explain why unsigned8 is being used 
(eg, say that reduced-size encoding is being used).

Recall:

>> And tcpControlBits:
>>
>>           tcpControlBits(6)<unsigned8>[1]
>>
>> - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly.
>
> It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16
>

It would be useful to discuss reduced size encoding and show a specific 
example. eg, if I'm collecting ingressInterface which is nominally a 
u32, but I'm a small device so I only export a u8, should I export:

ingressInterface(10)<unsigned32>[1]

or

ingressInterface(10)<unsigned8>[1]

P.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 4 Aug 2014 10:10:19 +0200

On 04 Aug 2014, at 10:04, Paul Aitken <[email-masked]> wrote:

> You missed tcpControlBits: since it's defined as unsigned16 in [IANA], you should either use unsigned16 or explain why unsigned8 is being used (eg, say that reduced-size encoding is being used).
> 
> Recall:
> 
>>> And tcpControlBits:
>>> 

Note that in a textual encoding, alignment is irrelevant.

>> It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16

Ah, indeed. Rev -09 then.

> 
> It would be useful to discuss reduced size encoding and show a specific example. eg, if I'm collecting ingressInterface which is nominally a u32, but I'm a small device so I only export a u8, should I export:
> 

This is an interesting question but it would not appear to be in scope at all for this document. 

Thanks, cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 04 Aug 2014 09:21:56 +0100

Brian,

> Note that in a textual encoding, alignment is irrelevant.

That was cut-n-paste from an earlier email. I can't immediately see what 
it was referring to.

> This is an interesting question but it would not appear to be in scope at all for this document.

Where would such a clarification be given if not here?

P.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 4 Aug 2014 10:27:00 +0200

On 04 Aug 2014, at 10:21, Paul Aitken <[email-masked]> wrote:

> That was cut-n-paste from an earlier email. I can't immediately see what it was referring to.

Ah.. then disregard.

> Where would such a clarification be given if not here?

So you're talking about distinguishing among typed export types (i.e., how to handle internal storage at an EP or CP), and this document is about textual representation of these data types (where the internal storage is (1) not in scope and (2) as per section 4.2 is only a matter of implicit ranges when no explicit range for an IE is given.

I'm really not seeing how these relate.

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 04 Aug 2014 09:39:46 +0100

Brian,

> I'm really not seeing how these relate.

Nope; I'm saying that in one line you should explain how reduced size 
encoding works wrt text encoding, using the example you've created using 
tcpControlBits:

          tcpControlBits(6)<unsigned16>[1]

Here the size of [1] doesn't immediately seem to agree with the 
<unsigned16> type.

So under Figure 1 you could say, "Note that IPFIX Reduced-Size Encoding 
[RFC7011] is being used for tcpControlBits."

(The same was done under Figure 19 in RFC6313.)

This both shows readers how to use RSE with textual encodings, and 
prevents future errata from "correcting" this apparent "mistake".

P.