Subject: RE: [ipfix-protocol] IPFIX protocol draft: list of issues

From: "Jeff Meyer" <[email-masked]>
Date: Fri, 13 Feb 2004 16:02:34 -0800

Benoit,

  Regarding [Proto-2] I'd recommend Field Id over Field Type.  The word 
"type" seems overloaded to me, does type refer to unsigned int, time, etc.  
Or does it refer a specific field definition (via a numeric identifier).  
From its usage it would seem that this portion of the protocol message is 
holding an identifier, not a type.

-- Jeff

>From: Benoit Claise <[email-masked]>
>To: [email-masked]
>Subject: [ipfix-protocol] IPFIX protocol draft: list of issues
>Date: Fri, 13 Feb 2004 01:05:30 +0100
>
>Dear all,
>
>I will be posting a new version 03 of the protocol draft at the latest 
>during the weekend.
>In the mean time, here is a list of issues that have been identified.
>	1. all the issues from the previous drafts.
>	2. issues from the mailing list.
>	3. issues from various discussions. 	  That's the reasons why there are 
>sometimes proposals from the authors.
>I hope I'm covering all of them. If not, feel free to update this list and 
>assign a new number to your issue.
>
>When discussing one issue on the mailing list, please always insert the 
>PROTO-<number> in the Subject: it will ease everybody live.
>As always, let's try to discuss one issue at the time.
>
>The goal is not to try to solve all the issue before posting the new draft 
>this weekend ;), but to discuss on the mailing list or at the next IETF 
>meeting.
>Note that this list will be updated in the version 03 of the protocol 
>draft.
>
>
>
>Issues in the Terminology section
>
>PROTO-1: Is flowset the right term to use?
>    - leave as is
>    - Record Set
>    - Record Array
>    - Record Collection
>    - Record List
>PROTO-2: Some discrepancies between data types, field type and Information
>    Element terminology.
>    - field type (IPFIX-PROTO) conflicts with field ID (IPFIX-INFO)
>    - suggestion: use field type instead of field Id in IPFIX-INFO
>    - rename 'type' to 'data type' and 'info elements' to 'fields'
>       in IPFIX-INFO
>PROTO-3: IP encapsulated packet
>    - IP Traffic Flow definition speaks of IP packets
>    - Metering Process definitions say:      Input to the metering process 
>are packets    - We don't want to limit ourselves to IPv4 and IPv6
>
>Issues in the Transport Protocol section
>
>PROTO-4: TCP and UDP are is not yet covered
>PROTO-5: Error recovery, for example what to do if a collector receives a 
>message it
>    can't decode.
>    Per protocol issue, ie TCP reset the session because it's a stream 
>protocol
>    and can't recover.
>PROTO-6: Section 5.2.3.3, Association: What happens if the Exporter gets no 
>response
>    from any Collector?
>    I think we should specify a (not-too-aggressive) retry algorithm.
>PROTO-7: Dropping data before export: What to do with sequence numbers?
>PROTO-8: Why having a stream per SID?
>PROTO-9: IPFIX message should have MTU size.
>PROTO-10: How to re-establish a lost connection? Procedure per transport 
>protocol?
>
>Issues in the Failover section
>
>PROTO-11: (initial version required) Section needs to be written
>    If we tackle reliability/failover a state diagram is needed.
>
>Issues in the Message Layout section
>
>PROTO-12: Do we need the IETF exclusive template flowset format?
>    suggested solution:
>    - reserve flowset ID 0 & 1 for compatibility with NFv9
>    - try to make flowset ID 2 & 3 definition fully compatible with NFv9
>    - add note that if you implement ID 2/3 correctly, you can also process 
>ID 0/1.
>PROTO-13: How to distinguish IETF field IDs from vendor field IDs
>    - Specify method for detecting the difference in section 8.
>    - Add a note that there is a common ID space for for field types used 
>in
>      data templates and option templates
>    - (Editorial) make clear that Section 8.2 also applies to option 
>templates
>PROTO-14: Why do we need padding? Should we shift it to MAY?
>    limit the size of the padding? Yes
>    solution:
>    - padding shorter than actual Record Length
>    - fill with 0
>    - only at end of flowset
>    - applies to all flowsets
>    - padding is OPTIONAL (MAY) , not RECOMMENDED (SHOULD)
>
>Issues in the IPFIX Message Format section
>
>PROTO-15: Remove Reserved 2 octets in Vendor specific option template 
>flowset
>    and add padding at the end
>PROTO-16: relationship between several different scopes in one record
>PROTO-17: redefine scope values?
>    - 1 System
>      2 IP interface
>      3 observation domain (SID) (preciously called line card)
>      4 reserved (previously used for cache)
>      5 template
>      6 metering process?
>      7 flow recording process?
>      8 exporting process?
>      9 observation point?
>PROTO-18: Can we have an optional length of 0 bytes for the scope section
>    in the option template?
>PROTO-19: Do we really need different templates formats for flows and 
>options?
>PROTO-20 Do we really need different record formats for flows and options?
>
>Issues in the Specific Reporting Requirement section
>
>PROTO-21: Do we need to define some mandatory content of the metering 
>process
>    statistics option template?
>    - Maurizio suggested text on the mailing list
>PROTO-22: Exporter ID (ie IP address of exporter)
>
>Issues in the Export Packet "Export Time" Computation and Flow Record Time 
>section
>
>PROTO-23: Finalize the time details
>
>Issues in the Linkage with the Information Model section
>
>PROTO-24: Section 11 "Linkage with the information model" must be completed 
>with
>    types used in [IPFIX-INFO]
>
>Issues in the Template Management section
>
>PROTO-25: The section 11 "Template Management" will have to updated
>    according to the transport protocol.
>    - For example, the point 2 of the section "Template Management".
>      Remark: the template management will vary with TCP, SCTP, etc...
>      Must have both sections updated: transport updated and template
>      management sections (BTW, this is the same for the failover
>      section).
>  Issues in the IANA section
>
>PROTO-26: IANA considerations section to be updated: have a look at RFC 
>2434,
>     which sets out guidelines for IANA Considerations.
>     Also, searching the RFCs for 'IANA Considerations' brings
>     up quite a few RFCs to look at as models.
>
>Issues - Miscellaneous
>
>PROTO-27: Need an example with the Vendor Specified Information Element
>PROTO-28: Packet Sampling.  This is mentioned in both the Requirements I-D
>     and the AS I-D.  We need to decide how it should be covered in the
>     IPFIX drafts.
>
>
>ACTION
>
>PROTO-29: number all the figures
>PROTO-30: Review the requirements draft to see what we miss, once it's an 
>I-RFC
>
>
>Regards, Benoit.
>
>
>
>
>
>
>--
>Help        mailto:[email-masked] and say "help" in message 
>body
>Unsubscribe mailto:[email-masked] and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/

_________________________________________________________________
Keep up with high-tech trends here at "Hook'd on Technology." 
http://special.msn.com/msnbc/hookedontech.armx

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Feb 2004 09:47:24 +0000

Jeff Meyer wrote:

> "type" seems overloaded to me, does type refer to unsigned int, time, 
> etc.  Or does it refer a specific field definition (via a numeric 
> identifier). 
> 

Isn't it holding a type identifier?

It's a codepoint that identifies the type of the field that will be
contained in the corresponding field in the data message.

That would suggest that the name should be field type identifier (FTI)
or perhaps field type codepoint (FTC).

- Stewart