Re: [IPFIX] rfc5103 lite

Hi, Andrew,

I'm okay making it clear that 4.10 describes IEs you shouldn't imitate when desiging new IEs, not IEs you shouldn't use. It seems little weird to me to stick a specific exception for a non-IETF protocol (3954 is Informational) in a document about extending an IETF protocol.

In the previous paragraph (new sentence on 3rd and 4th lines):

        However, for reasons of history, there
        are several Information Elements within the IANA registry which do not
        follow best practices in Information Element design. These Information
        Elements are not necessarily so flawed so as to require deprecation,
        but they should be explicitly ignored when looking for guidance as to
        whether a new Information Element should be added.

I think the paragraph you cite, though, is pretty clear that these IEs are being called out because they duplicate existing IEs. 

That said... I'm a little confused as to how initiator/responderOctets/Packets allow 5103-lite in a V9-compatible way: they're allocated in IPFIX number space, not in v9 space. Can NetFlow V9 export such IEs? Are these exporters really using IPFIX without any IPFIX features (i.e., V9 with IPFIX message headers)? Or is it V9-heavy (V9 with new IPFIX IEs)?

As for semantics, yep. We need to do a complete semantics review as part of the 5102-bis effort. Thanks for pointing out yet another place where these are inconsistent, though; we have our work cut out for us. :)

Thanks, and cheers,

Brian

On Mar 6, 2012, at 5:54 PM, Andrew Feren wrote:

> While reviewing the ie-doctors draft part of "4.10.  Avoiding Bad Ideas in Information Element Design" caught my attention.
> 
> "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)."
> 
> I agree that the initiatorOctets and initiatorPackets are redundant.  I also agree that in the context of IPFIX that responderOctets and responderPackets are made redundant by RFC 5103.  However, I think there is a valid use for the responderOctets and responderPackets IEs.
> 
> I see a lot of interest in implementing biflows, but many exporters are still exporting NetFlow v9 (RFC 3954).  The IEs for responderOctets and responderPackets allow a limited version of 5103     to be exported until the exporter can support IPFIX.  I'm not sure we want to paint these two IEs with the "bad idea" brush.  Maybe we could add a couple sentences to clarify the situation.
> 
> Something along the lines of
> For 3954 use of responderOctets and responderPackets is OK, but don't expect new responder/reverse IEs to be added.  If you need more reverse IEs then IPFIX and 5103 should be implemented.
> 
> We should also fix initiatorPackets and responderPackets to not have "identifier" semantics.
> 
> -Andrew
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

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