Re: [IPFIX] WG Last call for draft-ietf-ipfix-mediation-protocol-06.txt

Hi Nevil, all,

I missed last call, but as no one else has posted anything here are my 
comments.

First, I think something like this document is needed, but I'd prefer 
the language to be a bit more general in a number of places.  I also 
have a number of specific issues.

An IPFIX Mediator converts a record stream to IPFIX and a record stream 
can be "IPFIX Data Records or any other format", but other than those 
points in the Terminology section this document seems to assume IPFIX input.

For example:
    Original Exporter:   An Original Exporter is an IPFIX Device that
       hosts the Observation Points where the metered IP packets are
       observed.

I have a need for something very much like originalExporterIPv4Address 
except that my data source(s) fall under that "any other format" 
umbrella and are not IPFIX devices. I'd prefer to see 
originalSenderIPv4Address (or some such) rather than an IE for each 
non-IPFIX source.

If there is a need to know that the original source was IPFIX or 
something else I'd prefer an additional IE for originalSenderFormat.  
Probably with a registry of known formats. I don't have a use case for 
this IE at the moment, but perhaps there is a need.

In section 3 "Note that the format is compatible
    with the IPFIX Message Header defined in
    [I-D.ietf-ipfix-protocol-rfc5101bis], with some field definitions
    (for the example, the Export Time) updated in the context of the
    IPFIX Mediator."

I don't like this at all.  Does an exporter send IPFIX or something 
compatible with IPFIX?

For example Export Time "MAY use the export time received from the 
incoming Transport Session".  I think I understand the motivation behind 
this, but at the collector I have no way to know which export time is 
being used.  How do I know if the time applies to the original or 
mediator?  I'd rather not see this exception unless someone can explain 
how it is useful.

The text for sequence number doesn't match 5101bis.  More generally I 
think it is confusing to include all that copy paste text in this 
document.  I'd rather see a reference to 5101bis followed by a list of 
special circumstances.

Something like
      The format of the IPFIX Message Header as exported by an IPFIX
      Mediator is the same as  [RFC5102bis].

       See Section 4.1 for special considerations for Observation Domain
       management while passing unmodified templates through an IPFIX
       Mediator, and Section 5 for guidelines for preservation of
       original Observation Domain information at an IPFIX Mediator.

That makes it obvious what is special or different(*shudder*) relative 
to IPFIX.

Section 4.1 and 4.3 discuss two situations when a Mediator MUST NOT 
reorder and fields in a record.  Additionally, if an IE occurs more than 
once in a template that order also MUST NOT be modified.  I would think 
that this situation should also be treated similarly to unknown IEs 
either resend all or none.

4.2 starts with "The second case".  I'm not entirely sure what was first.

In section 4.3

" Depending on application requirements, Mediators which do not
    generate new Records SHOULD re-export values for unknown Information
    Elements, whether enterprise-specific Information Elements or
    Information Elements in the IPFIX Information Element registry
    [iana-ipfix-assignments]. added since the Mediator was implemented or
    updated."

That sentence seems a bit long and complicated.  At the very least I 
think the '.' before added needs to be removed.  Although I'd prefer to 
simplify it.  I think it is enough to state that "An IE is considered 
unknown if its data type and semantics are not known to the Mediator."  
Trying to list the reasons it might not be known just complicates things 
IMO.


I didn't fully grok Section 5, but "[RFC6313] MUST be used" bothers me.  
Mostly because from a collector perspective I really don't like 6313 at 
all and subTemplateMultiList in particular.  Is 6313 really the only way 
to export this data?  Why?

Section 7 timing constraints refers to relative timestamps as "difficult 
to manage".  I think "impossible to manage" is closer to the mark.  A 
collector can get sysUpTime from a v9 header.  For IPFIX I'm no sure 
where I get sysUpTime from.  Perhaps there needs to be a requirement for 
Mediators converting v9 to IPFIX to translate relative times to absolute 
times.

Better late than never I guess,
-Andrew

On 08/26/2013 11:32 PM, Nevil Brownlee wrote:
>
> Hi all:
>
> This WGLC has finished, with no comments at all on the list.
> I need at least a few "looks OK to me" or "I can live with that"
> responses before I can put together its Shepherd writeup!
>
> Cheers, Nevil
>
>
> On 8/08/13 10:12 AM, Nevil Brownlee wrote:
>>
>> Hi all:
>>
>> The -06 version of IPFIX Mediation Protocol was published last week,
>> now it's time for its WG Last Call.
>>
>> The WGLC starts now, and will run until Friday, 23 August.
>>
>> Please read the draft and send your comments/suggestions to the list.
>> Actual reviews of the draft would be much appreciated, but a brief
>> comment saying "I read it, it's fine" is useful too!
>>
>> Cheers, Nevil
>

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