Subject: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Mar 2011 16:56:51 +0100

Please find below the AD review of
draft-ietf-ipfix-structured-data-04.txt. 

The document is in pretty good shape. However I would suggest that the
authors address the questions and issues in this review and issue a
revised I-D if necessary before proceeding to IETF Last Call. 

The comments are divided in Technical (T) and Editorial (E). 

T1. What is the use case of the "undefined" semantics defined in 4.4.1.
Different collecting processes may interpret differently the data type.

T2. The definitions of what needs to be included in the Semantic field
of the IPFIX data types is not clear. For example in 4.5.1 - how is the
relationship among the different Information Element values within the
Structured Data Information Element encoded? etc. need to point to the
new semantics and registry defined in the IANA consideration section. 

T3. Need to mention in what units the length in all Element Length data
types encoding is expressed
(the above can be deducted from 5101 or from the examples but there is
no reason not to mention these in section 4.5)

T4. The following paragraph in section 8 may raise questions: 

> Typically new Information Elements based on the basicList data 
     type make sense.  For example, bgpPathList, bgpSequenceList and 
     bgpSetList, of abstract types and semantics basicList/ordered, 
     basicList/ordered, and basicList/exactlyOneOf respectively would 
     define the complete semantic of the list.  However, the community 
     needs some more research and feedback before starting to specify 
     new Information Elements based on the subTemplateList and 
     subTemplateMultiList data types.  So this specification doesn't 
     specify any new Information Elements beyond the ones in Section 
     4.3. 
      
People may ask what kind of research and feedback is still needed, and
if research is still needed why does this specification go to Standards
Track rather than Experimental? Does anything prevent us from saying
that it is expected that such new IE's be standardized in the future
based on implementations made first on vendors space? 

T5. Section 11.1 - Can new abstract data types be added to the newly
created abstract data types registry? If so what is the policy? 

T6. I think that also the Security Considerations of [RFC5102] apply.

E1. Idnits complain about: 

== The copyright year in the IETF Trust and authors Copyright Line does
not
     match the current year

E2. All examples are IPv4. This is not a problem by itself, but gives
the impression of an IPv4 centric document. Any reason not to provide at
least one example that uses IPv6 addresses? Or at least a note that
despite the fact that all examples use IPv4 addresses, the document
applies for IPv6 as well.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 04 Mar 2011 10:17:31 +0100

Hi Dan,

Thanks for your review.
Inline.
> Different collecting processes may interpret differently the data type.
The use case is when none of the other semantics apply.
An example is an IPFIX Mediator that translates from RFC5101 to IPFIX 
structured data. The Collecting Process (part of the IPFIX Mediator) 
doesn't know what the semantic is (it can only guess), so it should use 
"undefined" when re-exporting. Typical example, a Flow Record received 
with 2 output interfaces in the RFC5101 style.
> new semantics and registry defined in the IANA consideration section.
OLD:

       Semantic

           The Semantic field indicates the relationship among the
           different Information Element values within this Structured
           Data Information Element.

NEW:

       Semantic

           A numeric value that represents the relationship among the
           different Information Element values within this Structured
           Data Information Element. Refer to IANA's IPFIX "structured
           data types semantics registry.

> no reason not to mention these in section 4.5)
Section 4.5.1
OLD:

       Element Length

           The Element Length field indicates the length of each list
           element specified by Field ID, or contains the value 0xFFFF if
           the length is encoded as a variable-length Information Element
           at the start of the basicList Content, per Section 7 of
           [RFC5101].

           The Element Length field is effectively part of the header, so
           even in the case of a zero-element list, it MUST NOT be
           omitted.

NEW:

       Element Length

           _Per Section 7 of [RFC 5101],_  the Element Length field indicates
           the length,_in octets,_of each list element specified by Field ID,
           or contains the value 0xFFFF if the length is encoded as a variable-length
           Information Element at the start of the basicList Content.

           The Element Length field is effectively part of the header, so
           even in the case of a zero-element list, it MUST NOT be
           omitted.

> based on implementations made first on vendors space?
OLD:

NEW:

     The authors anticipate the creation of both enterprise-specific and 
IANA Information Elements based
     on the IPFIX structured data types. For example, bgpPathList, 
bgpSequenceList and bgpSetList,
     of abstract types and semantics basicList/ordered, 
basicList/ordered, and basicList/exactlyOneOf respectively
     would define the complete semantic of the list. This specification 
doesn't specify any new Information Elements
     beyond the ones in Section 4.3.
> created abstract data types registry? If so what is the policy?
Actually, you discovered a problem with the IANA section.

      11.1. New Abstract Data Types

       Section 4.1  <http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-4.1>. of this document specifies several new IPFIX abstract
       data types.  PerSection 6  <http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-6>  of the IPFIX information model
       [RFC5102  <http://tools.ietf.org/html/rfc5102>], new abstract data types can be added to the IPFIX
       information model.  This requires creation of a new IPFIX
       "abstract data types" registry at
       http://www.iana.org/assignments/ipfix.  This registry should
       include all the abstract data types fromSection 3.1 of [RFC5102]  <http://tools.ietf.org/html/rfc5102#section-3.1>.

       Abstract data types to be added to the IPFIX "abstract data types"
       registry are listed below.

However, this old text is not valid any more.
In the mean time, this "abstract data types" registry has been created 
already, 
http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes, 
as the outcome of the RFC5610 publication.

New section

      11.1. New Abstract Data Types

       Section 4.1  <http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-4.1>. of this document specifies several new IPFIX abstract
       data types.  PerSection 6  <http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-6>  of the IPFIX information model
       [RFC5102  <http://tools.ietf.org/html/rfc5102>], new abstract data types can be added to the IPFIX
       information model, in the IPFIX Information Element Data Types registry.

       Abstract data types to be added to the IPFIX "Information Element Data Types"
       registry are listed below.

       EDITOR'S NOTE: IANA, please pick the number three values in the
       http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes
       for the basicList, subTemplateList, and subTemplateMultiList

Dan, to answer you question about the process to add data types, the above sentence "
PerSection 6  <http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-6>  of the IPFIX information model [RFC5102  <http://tools.ietf.org/html/rfc5102>]" should do the trick.

> T6. I think that also the Security Considerations of [RFC5102] apply.
OLD:

Section 12. Security Considerations

     The same security considerations as for the IPFIX Protocol
     [RFC5101 <http://tools.ietf.org/html/rfc5101>] apply.

NEW:

12. Security Considerations

     The same security considerations as for the IPFIX Protocol
     [RFC5101 <http://tools.ietf.org/html/rfc5101>] and the IPFIX 
information model [RFC5102] apply.
> == The copyright year in the IETF Trust and authors Copyright Line does
Done.
> applies for IPv6 as well.
We will change one example with IPv6.

Are you fine with the answers?
Shall we post the new version?

Regards, Benoit
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 4 Mar 2011 17:40:50 +0100

Hi Benoit,
 
Thank you for your answers. They all seem reasonable to me with two
observations: 
 
T1: can you clarify with text what you explained in your answer? other
people may have the same question
 
T3: the clarification about the length applies not only to 4.5.1 but
also to other sections in 4.5. You need either to make the clarification
global at the start of the section or to include it in all length field
definitions where needed 
 
Please issue the new version with these changes and we can proceed to
IETF Last Call. 
 
Regards,
 
Dan

________________________________

	From: Benoit Claise [mailto:[email-masked]] 
	Sent: Friday, March 04, 2011 11:18 AM
	To: Romascanu, Dan (Dan)
	Cc: [email-masked]
	Subject: Re: [IPFIX] AD review of
draft-ietf-ipfix-structured-data-04.txt

	Hi Dan,
	
	Thanks for your review.
	Inline.

		The document is in pretty good shape. However I would
suggest that the
		authors address the questions and issues in this review
and issue a
		revised I-D if necessary before proceeding to IETF Last
Call. 
		
		The comments are divided in Technical (T) and Editorial
(E). 
		
		T1. What is the use case of the "undefined" semantics
defined in 4.4.1.
		Different collecting processes may interpret differently
the data type.

	The use case is when none of the other semantics apply.
	An example is an IPFIX Mediator that translates from RFC5101 to
IPFIX structured data. The Collecting Process (part of the IPFIX
Mediator) doesn't know what the semantic is (it can only guess), so it
should use "undefined" when re-exporting. Typical example, a Flow Record
received with 2 output interfaces in the RFC5101 style.

		T2. The definitions of what needs to be included in the
Semantic field
		of the IPFIX data types is not clear. For example in
4.5.1 - how is the
		relationship among the different Information Element
values within the
		Structured Data Information Element encoded? etc. need
to point to the
		new semantics and registry defined in the IANA
consideration section. 

	OLD:
	
	      Semantic
	     
	          The Semantic field indicates the relationship among
the
	          different Information Element values within this
Structured
	          Data Information Element.
	NEW:
	
	      Semantic
	     
	          A numeric value that represents the relationship among
the
	          different Information Element values within this
Structured
	          Data Information Element. Refer to IANA's IPFIX
"structured 
	          data types semantics registry. 

		T3. Need to mention in what units the length in all
Element Length data
		types encoding is expressed
		(the above can be deducted from 5101 or from the
examples but there is
		no reason not to mention these in section 4.5)

	Section 4.5.1
	OLD:
	
	      Element Length
	     
	          The Element Length field indicates the length of each
list
	          element specified by Field ID, or contains the value
0xFFFF if
	          the length is encoded as a variable-length Information
Element    
	          at the start of the basicList Content, per Section 7
of
	          [RFC5101].
	     
	          The Element Length field is effectively part of the
header, so
	          even in the case of a zero-element list, it MUST NOT
be
	          omitted.
	NEW:

	      Element Length
	     
	          Per Section 7 of [RFC 5101], the Element Length field
indicates 
	          the length, in octets, of each list element specified
by Field ID, 
	          or contains the value 0xFFFF if the length is encoded
as a variable-length 
	          Information Element at the start of the basicList
Content.
	
	          The Element Length field is effectively part of the
header, so
	          even in the case of a zero-element list, it MUST NOT
be
	          omitted.

		T4. The following paragraph in section 8 may raise
questions: 

			Typically new Information Elements based on the
basicList data 

		     type make sense.  For example, bgpPathList,
bgpSequenceList and 
		     bgpSetList, of abstract types and semantics
basicList/ordered, 
		     basicList/ordered, and basicList/exactlyOneOf
respectively would 
		     define the complete semantic of the list.  However,
the community 
		     needs some more research and feedback before
starting to specify 
		     new Information Elements based on the
subTemplateList and 
		     subTemplateMultiList data types.  So this
specification doesn't 
		     specify any new Information Elements beyond the
ones in Section 
		     4.3. 
		      
		People may ask what kind of research and feedback is
still needed, and
		if research is still needed why does this specification
go to Standards
		Track rather than Experimental? Does anything prevent us
from saying
		that it is expected that such new IE's be standardized
in the future
		based on implementations made first on vendors space? 

	OLD:

	     Typically new Information Elements based on the basicList
data 
	     type make sense.  For example, bgpPathList, bgpSequenceList
and 
	     bgpSetList, of abstract types and semantics
basicList/ordered, 
	     basicList/ordered, and basicList/exactlyOneOf respectively
would 
	     define the complete semantic of the list.  However, the
community 
	     needs some more research and feedback before starting to
specify 
	     new Information Elements based on the subTemplateList and 
	     subTemplateMultiList data types.  So this specification
doesn't 
	     specify any new Information Elements beyond the ones in
Section 
	     4.3. 

	NEW:
	
	    The authors anticipate the creation of both
enterprise-specific and IANA Information Elements based 
	    on the IPFIX structured data types. For example,
bgpPathList, bgpSequenceList and bgpSetList,
	    of abstract types and semantics basicList/ordered,
basicList/ordered, and basicList/exactlyOneOf respectively
	    would define the complete semantic of the list. This
specification doesn't specify any new Information Elements
	    beyond the ones in Section 4.3. 

		T5. Section 11.1 - Can new abstract data types be added
to the newly
		created abstract data types registry? If so what is the
policy? 

	      Section 4.1
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-
4.1> . of this document specifies several new IPFIX abstract
	      data types.  Per Section 6
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-
6>  of the IPFIX information model
	      [RFC5102 <http://tools.ietf.org/html/rfc5102> ], new
abstract data types can be added to the IPFIX
	      information model.  This requires creation of a new IPFIX
	      "abstract data types" registry at
	      http://www.iana.org/assignments/ipfix.  This registry
should
	      include all the abstract data types from Section 3.1 of
[RFC5102] <http://tools.ietf.org/html/rfc5102#section-3.1> .
	     
	      Abstract data types to be added to the IPFIX "abstract
data types"
	      registry are listed below.
	However, this old text is not valid any more.
	In the mean time, this "abstract data types" registry has been
created already,
http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTy
pes, as the outcome of the RFC5610 publication.
	
	New section 

	      Section 4.1
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-
4.1> . of this document specifies several new IPFIX abstract
	      data types.  Per Section 6
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-
6>  of the IPFIX information model
	      [RFC5102 <http://tools.ietf.org/html/rfc5102> ], new
abstract data types can be added to the IPFIX
	      information model, in the IPFIX Information Element Data
Types registry.
	     
	      Abstract data types to be added to the IPFIX "Information
Element Data Types"
	      registry are listed below.
	
	      EDITOR'S NOTE: IANA, please pick the number three values
in the 
	
http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTy
pes
	      for the basicList, subTemplateList, and
subTemplateMultiList

	Dan, to answer you question about the process to add data types,
the above sentence "
	Per Section 6
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-04#section-
6>  of the IPFIX information model [RFC5102
<http://tools.ietf.org/html/rfc5102> ]" should do the trick.

		T6. I think that also the Security Considerations of
[RFC5102] apply.

	OLD:

	    The same security considerations as for the IPFIX Protocol
	    [RFC5101 <http://tools.ietf.org/html/rfc5101> ] apply.
	
	NEW:

	    The same security considerations as for the IPFIX Protocol
	    [RFC5101 <http://tools.ietf.org/html/rfc5101> ] and the
IPFIX information model [RFC5102] apply.

		
		== The copyright year in the IETF Trust and authors
Copyright Line does
		not
		     match the current year

	Done.

		E2. All examples are IPv4. This is not a problem by
itself, but gives
		the impression of an IPv4 centric document. Any reason
not to provide at
		least one example that uses IPv6 addresses? Or at least
a note that
		despite the fact that all examples use IPv4 addresses,
the document
		applies for IPv6 as well. 

	
	Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 04 Mar 2011 23:25:26 +0100

Hi Dan,

Your comments make sense
Let me produce a new version of the draft, including them.

Regards, Benoit.
> also to other sections in 4.5. You need either to make the 
> clarification global at the start of the section or to include it in 
> all length field definitions where needed
>     ------------------------------------------------------------------------
>     *From:* Benoit Claise [mailto:[email-masked]]
>     *Sent:* Friday, March 04, 2011 11:18 AM
>     *To:* Romascanu, Dan (Dan)
>     *Cc:* [email-masked]
>     *Subject:* Re: [IPFIX] AD review of
>     Mediator) doesn't know what the semantic is (it can only guess),
>     so it should use "undefined" when re-exporting. Typical example, a
>     Flow Record received with 2 output interfaces in the RFC5101 style.