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

[Brian Trammell <[e-mail]>]

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

> Brian,
> 
>> On 04 Aug 2014, at 10:04, Paul Aitken <[e-mail]> wrote:
>> 
>>> 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.
>> 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.

Ah.. then disregard.

>>>> 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:
>>> 
>>> ingressInterface(10)<unsigned32>[1]
>>> 
>>> or
>>> 
>>> ingressInterface(10)<unsigned8>[1]
>> 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?

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