Re: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-07.txt
Nevil Brownlee <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
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 <[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
>
--
---------------------------------------------------------------------
Nevil Brownlee Computer Science Department | ITS
Phone: +64 9 373 7599 x88941 The University of Auckland
FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix