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

"Roni Even" <> Wed, 23 May 2012 07:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F61C21F8587; Wed, 23 May 2012 00:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.293
X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vl8N91RWfaUn; Wed, 23 May 2012 00:14:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C29B121F8596; Wed, 23 May 2012 00:14:04 -0700 (PDT)
Received: by werb13 with SMTP id b13so3849212wer.31 for <multiple recipients>; Wed, 23 May 2012 00:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=i0uIYONZ23Pp3We4GBrw/scoeu3XMXvXaS1hp9fbhcE=; b=kcgTJf35t25E4XeWZUU9/yGmCzAK1EEpUwHaKDP6j3lcSNnGJsMEeJewbmgkJ56xGH RAmlm3V3gYGzfMRAQT7iEayub1nRN+kzxUhlXLEhqhV3/ONLLchsIa17vNRJVgHsapG4 5uTH0Q6+4xXMdcKMJ1Ecu/VBFfKuaku55c/ZlmMLYibRaKtRRxtrvE128i6jdjiOgPQe BXJiHBeTmFtFvYZPr6oExKD2xKnm1JW/2BbPPw2bPm7nYIAQtp+Aiv/6Ai1RvekyaqDW kCE4zu8ZYmQRIVD/on2Tx2BTaTL5+sZ6ooFQtzyaF/dY/wZNIK0dbDIyGm3MxQwZd3U6 pNig==
Received: by with SMTP id ek9mr43318051wib.7.1337757243756; Wed, 23 May 2012 00:14:03 -0700 (PDT)
Received: from windows8d787f9 ( []) by with ESMTPS id gb9sm38468117wib.8.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 May 2012 00:14:03 -0700 (PDT)
From: Roni Even <>
To: 'Benoit Claise' <>
References: <> <>
In-Reply-To: <>
Date: Wed, 23 May 2012 10:11:50 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CD38CC.7A29B550"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac04cuj+nPaJQ4f7Ra6W4Tdvse+fBgAPFb+g
Content-Language: en-us
Cc:, 'IETF' <>,
Subject: Re: [Gen-art] Gen-ART LC review of draft-claise-export-application-info-in-ipfix-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2012 07:14:08 -0000

Hi Benoit,

Thanks, see in-line



I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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
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.



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.



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


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.