RE: Gen-ART LC review of draft-claise-export-application-info-in-ipfix-05

["Roni Even" <ron.even.tlv@xxxxxxxxx>]

Hi Benoit,

Thanks, see in-line

Roni

 

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Please resolve these comments along with any other Last Call comments you may receive.

 

Document: draft-claise-export-application-info-in-ipfix-05

Reviewer: Roni Even

Review Date:2012–4–7

IETF LC End Date: 2012–4–17

IESG Telechat date:

 

Summary: This draft is almost ready for publication as an Informational RFC.

 

Major issues:

 

Minor issues:

 

In sections 2, 4.1 (PANA-L7), 5, 6.5 the draft points to information in Cisco web page. I could not locate and information that is referenced. The link is to the main Cisco web page. For example in section 6.5 it lists the selectorID as 10000, where is this value located?

The exact URsL are http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/presentation_c96-629396.html
and http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/product_bulletin_c25-627831.html
As you can see from the URLs, there is a chance that those might change.
Stephen Farrell had the same comment.

 

RE: My concern was that going to Cisco web page I tried to search for the information using the search window and could not find it so I think that this link is not helpful for finding the information.

For the definition of Classification engine IDs in section 4.1 for the non standard values like PANA-L3, PANA-L4, PANA-L7, PANA-L2, is there a requirement that the selector IDs will be publically available?

Yes. Also, they would be exported with an IPFIX Options Template Record.
An example of PANA-L3 was the IPFIX port, 4739, which was pre-reserved by IANA, 3 years before RFC5101 was published.

 

RE: OK

In section 4.2 “However, an IANA L3 protocol encoding may encoded with 3 bytes.” When is it encoded in 3 bytes, also figure 2 is not reflecting this example, I expected to see a 32 bit value according to the text and not a general figure. (small nit in the above sentence “may be” instead of “may”.

Will be corrected.

 

RE:OK

In section 7 I noticed that ”p2pTechnology, tunnelTechnology, and encryptedTechnology” are already assigned in the IANA IPFIX Information elements so why assign them again as new?

from RFC5102:

   The value of these identifiers is in the range of 1-32767.  Within

   this range, Information Element identifier values in the sub-range of

   1-127 are compatible with field types used by NetFlow version 9

   [RFC3954].

So basically, if Cisco has assigned those numbers already, they can reused in IANA.

 

RE: The question is if you want the existing assignment to be used without change than why have this information in the IANA consideration in the first place.

 

In section 7 I noticed that you request that the  applicationDescription, applicationId, applicationName, classificationEngineId will receive elementid values from the range 0-127. My reading from section 4.2 is this is not required, maybe add text that will explain this request.

See my previous remark.

 

RE:  OK, even though it should be clear that this applies to these specific selectors since you want them to be compatible with NetFlow version 9 and it is not a general request for using specific sub range for all selectors.

In the security section are there additional considerations when the applicationid information is coming from a proprietary classification engine about authentication of the information source?

Not as far as I know.
Maybe I'm missing something. Can you please elaborate.

RE: No, this is OK for me.

 

Nits/editorial comments:

 

1.  In section 4.1 last sentence what is the meaning of “by theses specifications” , I did not understand the context.

2.  In section 6.6 “to determine whether or the default HTTP port” delete the “or”

In section 6.6 “The Classification Engine ID is 2” should be “3”.

will be corrected.

Thanks again.

Regards, Benoit.