Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt

[Brian Trammell <[e-mail]>]

hi Paul,

(inline)^n.

On 31 Oct 2012, at 14:26 , Paul Aitken wrote:

> Brian,
> 
> A few replies inline; other stuff cut for brevity.
> 
> 
>> Hi, Paul,
>> 
>> Many, many thanks for your review. We hadn't actually done a new revision (as we got no commentary during the LC), so let's call these WGLC comments and roll them into a -07 revision, which I'll submit once the Atlanta window is open again (or once this thread comes to a conclusion, whichever comes first).
> 
> To be clear, Nevil started WGLC on -05 (see the subject line above) just hours after -06 was announced. I reviewed -06.

Ah, oops. I presumed that was an oversight; I thought -06 got WGLC'd.

>> Specific comments inline; omitted sections accepted without comment, as usual. Comments on Section 5 deferred until we have a consensus on whether we keep it (see other thread).
>> 
>> On Oct 30, 2012, at 11:28 PM, Paul Aitken wrote:
>> 
>>> Some IEs are missing from this document, although they are defined in IANA's IPFIX registry:
>>> 
>>>    All the IE's from section 5.8. "Min/Max Flow Properties" of [5102] are missing:
>>> 
>>>        6    tcpControlBits
>>>        25    minimumIpTotalLength
>>>        26    maximumIpTotalLength
>>>        52    minimumTTL
>>>        53    maximumTTL
>>>        64    ipv6ExtensionHeaders
>>>        208    ipv4Options
>>>        209    tcpOptions
>>> 
>>> 
>>>    This 5103 IE is missing:
>>> 
>>>        239    biflowDirection
>>> 
>>> 
>>>    The following IEs defined by cisco are listed by IANA, but not in this text:
>>> 
>>>        82    interfaceName
>>>        83    interfaceDescription
>>>        91    mplsTopLabelPrefixLength
>>>        98    postIpDiffServCodePoint
>>>        99    multicastReplicationFactor
>>>        105-127
>>>        225-236
>>>        240+
>>> 
>>> 
>>>    The following IEs are not mentioned here, although they are detailed in draft-yourtchenko-cisco-ies :
>>> 
>>>        3, 34, 35, 38, 39, 43, 48-51, 65-69, 84, 87, 89, 92-93, 100, 101, 102, 103, 104, 94-97.
>> The IEs in 5102bis' categories were chosen because they appeared in 5102; we decided to keep the categorization but explicitly not to update the document to point to IEs added since 5102's publication. (Section 5.8 appears to be an editing oversight; I'm not sure when it fell out of the document, but is not in any working copy of the doc I have; I'll add it back in).
>> 
>> However, if we replace Section 5 as I propose in the other thread, this discussion becomes moot.
> 
> ~somewhat. However proto-IE-doctors should check that these IE's all conform to the 5102bis specifications.

Point; will make a note of this list somewhere.

> 
>>> Please find specific feedback inline:
>>> 
>>>> 1.1. Changes since RFC 5102
>>>> 
>>>>    This document obsoletes the Proposed Standard revision of the IPFIX
>>>>    Protocol Specification [RFC5102].  The following changes have been
>>>>    made to this document with respect to the previous document:
>>>> 
>>>>       - All outstanding technical and editorial errata filed on the
>>>>    [RFC5102] as of publication time have been corrected
>>>>       - All references into [RFC5101] have been updated to [RFC5101bis],
>>>>    reflecting changes in that document as necessary
>>>>       - Information element definitions have been removed, as the
>>>>    reference for these is now [IPFIX-IANA]; categorizations of
>>>>    information elements as defines in [RFC5102] have been retained in
>>>>    section 5.
>>>>       - The process for modifying [IPFIX-IANA] has been improved, and is
>>>>    now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated
>>>>    accordingly, and a new section 7.3 gives IANA considerations for this
>>>>    process.
>>>>       - Definitions of timestamp data types have been clarified
>>>>       - Appendices A and B have been removed
>>> BTW, the indentation of that section makes it difficult to read. Can you get all the text - including the wrapped lines - to the right of the bullets?
>> I'm not an nroff hacker. Any pointers?
> 
> Personally, I had to hack rfc2xml to make it do what I wanted.

Bah; okay, I'll look somewhere for some nroff that does things correctly and copy from that then.

>> It's also not clear that this section should survive IESG processing / RFC editor processing.
> 
> Since this doc obsoletes 5102, I find it useful to get a high level overview of what was changed, and for that overview to be given early in the document.

Okay, that's one vote, so we'll keep it.

>>>> 2.3.  Naming Conventions for Information Elements
>>>> 
>>>>    The following naming conventions were used for naming Information
>>>>    Elements in this document.  It is recommended that extensions of the
>>>>    model use the same conventions.
>>>> 
>>>>    o  Names of Information Elements SHOULD be descriptive.
>>>> 
>>>>    o  Names of Information Elements MUST be unique within the IANA
>>>>       registry.   Enterprise-specific Information Elements SHOULD be
>>>>       prefixed with a vendor name.
>>>> 
>>>>    o  Names of Information Elements MUST start with non-capitalized
>>>>       letters.
>>>> 
>>>>    o  Composed names MUST use capital letters for the first letter of
>>>>       each component (except for the first one).  All other letters are
>>>>       non-capitalized, even for acronyms.  Exceptions are made for
>>>>       acronyms containing non-capitalized letters, such as 'IPv4' and
>>>>       'IPv6'.  Examples are sourceMacAddress and destinationIPv4Address.
>>> Combination of the above rules means that IANA will name an IE "foo", while the ES equivalent is named "enterpriseFoo".
>>> It's unfortunate that "foo" != "Foo".
>> We have the same issue with RFC5103. Fortunately most platforms have an equivalent of tolower()/toupper(), but yeah, this is a little bit of a pain.
> 
> So does the "names must be unique" rule include or exclude case?
> 
> eg, are "fondantHem" and "fondAnthem" the same name? Are "coveredRaft" and "coveRedraft" the same?

Ugh. Point. My inclination is we should define naming match as case-insensitive, since the intention is not to have these names used on the wire, and the only examples I can think of of collision are typographical in nature.

>>>> 3.2.3.  deltaCounter
>>>> 
>>>>    An numeric value reporting the value of a counter. Counters are
>>>>    unsigned and wrap back to zero after reaching the limit of the type.
>>>>    For example, an unsigned64 with counter semantics will continue to
>>>>    increment until reaching the value of 2**64 - 1. At this point, the
>>>>    next increment will wrap its value to zero and continue counting from
>>>>    zero. The semantics of a delta counter is similar to the semantics of
>>>>    counters used in SNMP, such as Counter32 defined in RFC 2578
>>>>    [RFC2578]. The only difference between delta counters and counters
>>>>    used in SNMP is that the delta counters have an initial value of 0. A
>>>>    delta counter is reset to 0 each time its value is exported.
>>> What if the cache entry is removed but not exported (eg, an export filter blocks the export) ?
>>> Then the counter was not exported, so it should not be reset to 0?
>>> 
>>> ie, the reset action is more to do with the cache entry expiring than whatever happens to it next.
>> As I read it, this language was chosen in an attempt to be implementation-independent; nowhere in 5102 does the word "cache" appear, since that makes assumptions about how flow records are created in an MP. (The terminology and implicit design choices associated therewith crept into IPFIX in 6728, but I suppose there was nothing to be done there; you have to make some assumptions about MP internals if you're going to describe how to configure an MP.)
>> 
>> How about the more neutral:
>> 
>> A delta counter is reset to 0 each time it is exported and/or expires without export.
> 
> By their nature, delta counters don't exist after they expire or are exported - so they're not really reset.

Implementation-dependent. You cannot at the protocol level force the MP implementation to forget things it doesn't want to.

> In fact the total and delta counter mechanisms are identical; only their observation periods set them apart. ie the difference between them is due to time. So I think the definition should capture that.

again, _in the exemplar design you use to reason about the protocol_ yes, but the exact implementation of these counters is (rightly) left out of the protocol.

Which, indeed, the more neutral language I proposed above fails to do (it captures the concepts of "reset" and "expiration"). How about:

A delta counter counts only observations made since the last export of a Flow Record for a given Flow.

Cheers,

Brian