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

[Nevil Brownlee <[e-mail]>]

Hi Brian:

Since we agree that your proposed change is purely editorial,
making the change at AUTH48 is the right way to do it.
Benoit, I think these things need AD approval, is that right?

Cheers, Nevil


On 4/12/12 10:44 PM, Brian Trammell wrote:
> 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 <[e-mail]> 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, "[e-mail]" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix
>


-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: [phone] x88941             The University of Auckland
  FAX: [phone]   Private Bag 92019, Auckland 1142, New Zealand