Re: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-07.txt

Hi, Andrew,

I recall this thread, but had completely missed the resolution to it; apologies, and thanks for bringing it back up.

Rereading the descriptions and the approved revision of ie-doctors, there are two problems with the draft text:

(1) the assumed semantics are incorrect; and

(2) initiatorOctets doesn't actually duplicate octetTotalCount (since it counts from the end of the L4 payload as opposed to the beginning of the L3 header).

The following problems still exist with these IEs:

(3) initiatorPackets still appears to duplicate packetTotalCount, unless...

(3a) the definition of initiatorPackets is interpreted in a certain way. As it is, it's still ambiguous to the point of not being implementable: "The total number of layer 4 packets in a flow from the initiator"... What is a "layer 4 packet"? Is this a packet containing payload beyond the layer 4 header? containing content that will be delivered to the application (which may be different, depending on which layer 4)? a packet containing a layer 4 header known to the MP?

(4) responder{Octets/Packets} still duplicate the RFC 5103 reversed versions of initiatorOctets and initiatorPackets using "initiator" biflowDirection, which goes against the general rule to reuse IEs when necessary.

From a process standpoint, I'm not sure what the right thing to do is, as IE-DOCTORS is now in the RFC-EDITOR queue. I believe the point made by this paragraph (the second in section 4.9) to be a necessary one, but the examples given are clearly in error. The meaning of the text is conveyed by the first sentence, which does not require update; the example is non-normative. I believe that the problem is therefore editorial, and would propose an RFC-EDITOR note like the following during AUTH48:

OLD:

   Before registering a new Information Element, it must be determined
   that it would be sufficiently unique within the IANA IE registry.
   This evaluation has not always been done in the past, and the
   existence of the Information Elements defined without this evaluation
   should not be taken as an example that such Information Element
   definition practices should be followed in the future.  Specific
   examples of such Information Elements include initiatorOctets and
   responderOctets (which duplicate octetDeltaCount and its reverse per
   [RFC5103]) and initiatorPackets and responderPackets (the same, for
   packetDeltaCount).

NEW:

   Before registering a new Information Element, it must be determined
   that it would be sufficiently unique within the IANA IE registry.
   This evaluation has not always been done in the past, and the
   existence of the Information Elements defined without this evaluation
   should not be taken as an example that such Information Element
   definition practices should be followed in the future.  Specific
   examples of such Information Elements include initiatorPackets and
   responderPackets (which appear to duplicate packetTotalCount and 
   its reverse per [RFC5103]).

However, I'd like a ruling from our Friendly Area Directors as to whether this an acceptable resolution at this stage.

Separate from this, issue (3a) above concerning the ambiguity of initiatorPackets and responderPackets should be handled with a revision to the Information Element definitions.

Cheers,

Brian

On 4 Dec 2012, at 5:18, Andrew Feren <[email protected]> wrote:

> Hi Brian,
> 
> I haven't reread this entire draft, but happened to notice that this
> version still has 
> 
> "Specific
>   examples of such Information Elements include initiatorOctets and
>   responderOctets (which duplicate octetDeltaCount and its reverse per
>   [RFC5103 <http://tools.ietf.org/html/rfc5103>]) and initiatorPackets
> and responderPackets (the same, for
>   packetDeltaCount)."
> 
> 
> Which is not correct
> 
> Earlier discussion at
> 
> http://www.ietf.org/mail-archive/web/ipfix/current/msg06451.html
> 
> http://www.ietf.org/mail-archive/web/ipfix/current/msg06456.html
> 
> 
> -Andrew
> 
> On 10/3/12 10:47 AM, "[email protected]" <[email protected]>
> wrote:
> 
>> 
>> 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           : Guidelines for Authors and Reviewers of IPFIX
>> Information Elements
>> 	Author(s)       : Brian Trammell
>>                         Benoit Claise
>> 	Filename        : draft-ietf-ipfix-ie-doctors-07.txt
>> 	Pages           : 33
>> 	Date            : 2012-10-03
>> 
>> Abstract:
>>  This document provides guidelines for how to write definitions of new
>>  Information Elements for the IP Flow Information Export (IPFIX)
>>  protocol.  It provides instructions on using the proper conventions
>>  for Information Elements to be registered in the IANA IPFIX
>>  Information Element registry, and provides guidelines for expert
>>  reviewers to evaluate new registrations.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-07
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-ie-doctors-07
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
> 

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix