Re: [Gen-art] Gen-ART LC review of draft-claise-export-application-info-in-ipfix-05

[Benoit Claise <[e-mail]>]

Hi Roni,

Thanks for your review.
See in-line.
>
> 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:
>
> 1.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.
>
> 2.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.

> 3.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.
>
> 4.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  <http://tools.ietf.org/html/rfc3954>].


So basically, if Cisco has assigned those numbers already, they can 
reused in IANA.
>
> 5.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.
>
> 6.In the security section arethere 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.
>
> 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"
>
> 3.In section 6.6 "The Classification Engine ID is 2" should be "3".
>

will be corrected.

Thanks again.

Regards, Benoit.
>