From bclaise@cisco.com Thu Jan 3 07:41:42 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15621F8CBC for ; Thu, 3 Jan 2013 07:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYd8OohUSmoC for ; Thu, 3 Jan 2013 07:41:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 62E8E21F868B for ; Thu, 3 Jan 2013 07:41:36 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r03FfZc1019959 for ; Thu, 3 Jan 2013 16:41:35 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r03FfYpG000015 for ; Thu, 3 Jan 2013 16:41:34 +0100 (CET) Message-ID: <50E5A6AE.7090905@cisco.com> Date: Thu, 03 Jan 2013 16:41:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <50E594B0.9030603@cisco.com> In-Reply-To: <50E594B0.9030603@cisco.com> X-Forwarded-Message-Id: <50E594B0.9030603@cisco.com> Content-Type: multipart/alternative; boundary="------------010605020606070803070308" Subject: [IPFIX] AD review for draft-ietf-ipfix-information-model-rfc5102bis-08 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:41:42 -0000 This is a multi-part message in MIME format. --------------010605020606070803070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is our AD review regarding draft-ietf-ipfix-information-model-rfc5102bis-08 Regards, Ron and Benoit 1. We see in http://tools.ietf.org/html/rfc5102 "Updated by: 6313". What happens to this relationship? In other words, what is the relationship with RFC 6313? Don't you have to say a few words about it? 2. IANA considerations section and the new Revision and Date columns. You need to mention to IANA that they have to create these two new columns. The only text I see is: [NOTE to IANA: on publication of this document, please set the Revision of all existing Information Elements to 0.] [NOTE to IANA: on publication of this document, please set the Date of all existing Information Elements to the publication date of this document.] 3. IANA Considerations 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 ]; Information Element identifiers in this range MUST NOT be assigned unless the Information Element is compatible with the NetFlow version 9 protocol. Such Information Elements may ONLY be requested by a NetFlow v9 expert, to be designated by the IESG. First of all, the MUST NOT should be "must not". Then, we ought be careful about sort-of "promoting" bits of a vendor-specific informational RFC (3954) even if in this case that's not a controversial thing to do. This issue is with "may ONLY be requested" Finally, you should have this information in the IANA Considerations section. 4. IANA Considerations New assignments for IPFIX Information Elements are administered by IANA through Expert Review [RFC5226 ], i.e., review by one of a group of experts designated by the IESG. Add an IANA note that says an internal mailing list should be created to communicate with the experts (including NetFlow Version 9) .....but not mention it as text in the document. 5. IANA Considerations New assignments for IPFIX Information Elements are administered by IANA through Expert Review [RFC5226 ], i.e., review by one of a_group of experts designated by the IESG_. ... When IANA receives a request to add, revise, or deprecate an Information Element in the IPFIX Information Elements Registry, it forwards the request to the_IE-DOCTORS experts_ for review. It's not clear if we speak with one set or two different sets of experts. Multiple changes in the IANA considerations section. 6. Section 2.2. Scope of Information Elements By default, most Information Elements have a scope specified in their definitions. o The Information Elements listed in Sections5.2 and5.3 , and similar Information Elements in [IPFIX-IANA ], have a default of "a specific Metering Process" or of "a specific Exporting Process", respectively. o The Information Elements listed in Sections5.4 -5.11 , and similar Information Elements in [IPFIX-IANA ], have a scope of "a specific Flow". The section 5.X don't exist any longer. _EDITORIAL_ 1. The canonical reference for IPFIX Information Elements the IANA IPFIX Information Element registry [IPFIX-IANA ]; the initial values for this registry were provided by [RFC5102 ]. Aren't you missing a verb? 2. OLD: The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444 ]. The IPFIX information model does not specify relationships between Information Elements. NEW: The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444 ]: the IPFIX information model does not specify relationships between Information Elements. Justification: otherwise it's not clear whether the next sentence (It also does not specify a concrete encoding of Information Elements) fits into "not fully in line with the definition of the term in RFC 3444". Actually, this sentence is in line with RFC 3444 --------------010605020606070803070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is our AD review regarding draft-ietf-ipfix-information-model-rfc5102bis-08

Regards, Ron and Benoit

1.
We see in http://tools.ietf.org/html/rfc5102 "Updated by: 6313". What happens to this relationship?  In other words, what is the relationship with RFC 6313? Don't you have to say a few words about it?

2. IANA considerations section and the new Revision and Date columns.
You need to mention to IANA that they have to create these two new columns.
The only text I see is:
[NOTE to IANA: on publication of this document, please set the Revision
of all existing Information Elements to 0.]

[NOTE to IANA: on publication of this document, please set the Date of
all existing Information Elements to the publication date of this
document.]
3. IANA Considerations

   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]; Information Element identifiers in this range MUST NOT be
   assigned unless the Information Element is compatible with the
   NetFlow version 9 protocol. Such Information Elements may ONLY be
   requested by a NetFlow v9 expert, to be designated by the IESG.
First of all, the MUST NOT should be "must not".
Then, we ought be careful about sort-of "promoting" bits of a vendor-specific informational RFC (3954) even if in this case that's not a controversial thing to do. This issue is with "may ONLY be requested"
Finally, you should have this information in the IANA Considerations section.


4. IANA Considerations
New assignments for IPFIX Information Elements are administered by IANA
through Expert Review [RFC5226], i.e., review by one of a group of
experts designated by the IESG.
Add an IANA note that says an internal mailing list should be created to communicate with the experts (including NetFlow Version 9) …..but not mention it as text in the document.

5. IANA Considerations
New assignments for IPFIX Information Elements are administered by IANA
through Expert Review [RFC5226], i.e., review by one of a group of
experts designated by the IESG.
...
When IANA receives a request to add, revise, or deprecate an Information
Element in the IPFIX Information Elements Registry, it forwards the
request to the IE-DOCTORS experts for review.
It's not clear if we speak with one set or two different sets of experts.
Multiple changes in the IANA considerations section.

6.
Section 2.2.  Scope of Information Elements

   By default, most Information Elements have a scope specified in their
   definitions.

   o  The Information Elements listed in Sections 5.2 and 5.3, and
      similar Information Elements in [IPFIX-IANA], have a default of "a
      specific Metering Process" or of "a specific Exporting Process",
      respectively.

   o  The Information Elements listed in Sections 5.4-5.11, and similar
      Information Elements in [IPFIX-IANA], have a scope of "a specific
      Flow".

The section 5.X don't exist any longer.


EDITORIAL

1.
   The canonical reference for IPFIX Information Elements the IANA IPFIX
   Information Element registry [IPFIX-IANA]; the initial values for
   this registry were provided by [RFC5102].

Aren't you missing a verb?

2.

OLD:

   The use of the term 'information model' is not fully in line with the
   definition of this term in [RFC3444]. The IPFIX information model
   does not specify relationships between Information Elements.
NEW:
   The use of the term 'information model' is not fully in line with the
   definition of this term in [RFC3444]: the IPFIX information model
   does not specify relationships between Information Elements. 

Justification: otherwise it's not clear whether the next sentence (It also
does not specify a concrete encoding of Information Elements) fits into "not fully in line with the definition of the term in RFC 3444".
Actually, this sentence is in line with RFC 3444









--------------010605020606070803070308-- From trammell@tik.ee.ethz.ch Thu Jan 3 08:31:31 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8A521F88F1 for ; Thu, 3 Jan 2013 08:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCzLOkm99MOy for ; Thu, 3 Jan 2013 08:31:31 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0D55921F86C1 for ; Thu, 3 Jan 2013 08:31:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8FE36D930A; Thu, 3 Jan 2013 17:31:27 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fKdAdNQkgFdy; Thu, 3 Jan 2013 17:31:27 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 65ECBD9309; Thu, 3 Jan 2013 17:31:27 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <50E5A6AE.7090905@cisco.com> Date: Thu, 3 Jan 2013 17:31:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50E594B0.9030603@cisco.com> <50E5A6AE.7090905@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1283) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] AD review for draft-ietf-ipfix-information-model-rfc5102bis-08 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:31:31 -0000 Hi, Benoit, Ron, all, One reply inline; executive summary: expect a -09 soon addressing these = concerns. Cheers, Brian On 3 Jan 2013, at 16:41 , Benoit Claise wrote: > Dear all, >=20 > Here is our AD review regarding = draft-ietf-ipfix-information-model-rfc5102bis-08 >=20 > Regards, Ron and Benoit >=20 > 1. > We see in http://tools.ietf.org/html/rfc5102 "Updated by: 6313". What = happens to this relationship? In other words, what is the relationship = with RFC 6313? Don't you have to say a few words about it? I'd suggest adding new subsections of 3.1 for the abstract data types = from 6313, referring (normatively) to 6313 for their definitions. From internet-drafts@ietf.org Fri Jan 4 08:19:56 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8063121F8960; Fri, 4 Jan 2013 08:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFPAJkxC3lM1; Fri, 4 Jan 2013 08:19:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBE621F875C; Fri, 4 Jan 2013 08:19:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130104161956.13448.23930.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2013 08:19:56 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 16:19:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Operation of the IP Flow Information Export (IPFIX) Prot= ocol on IPFIX Mediators Author(s) : Benoit Claise Atsushi Kobayashi Brian Trammell Filename : draft-ietf-ipfix-mediation-protocol-03.txt Pages : 27 Date : 2013-01-04 Abstract: This document specifies the the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Fri Jan 4 08:25:38 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2111B21F8756 for ; Fri, 4 Jan 2013 08:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6kTJxM2HHWh for ; Fri, 4 Jan 2013 08:25:37 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7D22521F855D for ; Fri, 4 Jan 2013 08:25:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B899DD94B3 for ; Fri, 4 Jan 2013 17:25:29 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WtmGqzGErbv9 for ; Fri, 4 Jan 2013 17:25:29 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8A17AD94B0 for ; Fri, 4 Jan 2013 17:25:29 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Brian Trammell In-Reply-To: <20130104161956.13448.23930.idtracker@ietfa.amsl.com> Date: Fri, 4 Jan 2013 17:25:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130104161956.13448.23930.idtracker@ietfa.amsl.com> To: "ipfix@ietf.org Working Group" X-Mailer: Apple Mail (2.1283) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 16:25:38 -0000 Greetings, all, This revision of the mediator protocol draft updates external = references; there are no further content changes. We expect to submit a = further revision to this document after the completion of work on = RFC5101/5102bis. Best regards, Brian On 4 Jan 2013, at 17:19 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : Operation of the IP Flow Information Export = (IPFIX) Protocol on IPFIX Mediators > Author(s) : Benoit Claise > Atsushi Kobayashi > Brian Trammell > Filename : draft-ietf-ipfix-mediation-protocol-03.txt > Pages : 27 > Date : 2013-01-04 >=20 > Abstract: > This document specifies the the operation of the IP Flow Information > Export (IPFIX) protocol specific to IPFIX Mediators, including > Template and Observation Point management, timing considerations, = and > other Mediator-specific concerns. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Mon Jan 7 01:15:34 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E365021F86A1; Mon, 7 Jan 2013 01:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DpB4BIOof9d; Mon, 7 Jan 2013 01:15:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333E421F856C; Mon, 7 Jan 2013 01:15:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107091533.15325.1225.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 01:15:33 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:15:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Information Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-09.txt Pages : 22 Date : 2013-01-07 Abstract: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc51= 02bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Mon Jan 7 01:30:24 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3721F868E for ; Mon, 7 Jan 2013 01:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OldgWmai0Rp4 for ; Mon, 7 Jan 2013 01:30:23 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A193321F84F6 for ; Mon, 7 Jan 2013 01:30:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A11DFD930B for ; Mon, 7 Jan 2013 10:30:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8HqlvOMjcGMP for ; Mon, 7 Jan 2013 10:30:22 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5DE20D9308 for ; Mon, 7 Jan 2013 10:30:22 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <20130107091533.15325.1225.idtracker@ietfa.amsl.com> Date: Mon, 7 Jan 2013 10:30:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <084F3F88-FE01-4F9E-9EE2-3603A119C703@tik.ee.ethz.ch> References: <20130107091533.15325.1225.idtracker@ietfa.amsl.com> To: ipfix@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:30:24 -0000 Greetings, all. This revision of rfc5102bis addresses AD review comments. Best regards, Brian On Jan 7, 2013, at 10:15 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : Information Model for IP Flow Information = eXport (IPFIX) > Author(s) : Benoit Claise > Brian Trammell > Filename : = draft-ietf-ipfix-information-model-rfc5102bis-09.txt > Pages : 22 > Date : 2013-01-07 >=20 > Abstract: > This document provides an overview of the information model for the IP > Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX > Information Element Registry. It is used by the IPFIX Protocol for > encoding measured traffic information and information related to the > traffic Observation Point, the traffic Metering Process, and the > Exporting Process. Although developed for the IPFIX Protocol, the = model > is defined in an open way that easily allows using it in other > protocols, interfaces, and applications. This document obsoletes RFC > 5102. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc510= 2bis >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-0= 9 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc5= 102bis-09 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Mon Jan 7 01:37:45 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D191121F8550 for ; Mon, 7 Jan 2013 01:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyC+j6vwch99 for ; Mon, 7 Jan 2013 01:37:45 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACA521F854D for ; Mon, 7 Jan 2013 01:37:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r079bhQo018300; Mon, 7 Jan 2013 10:37:43 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r079bhEC006787; Mon, 7 Jan 2013 10:37:43 +0100 (CET) Message-ID: <50EA9766.5010701@cisco.com> Date: Mon, 07 Jan 2013 10:37:42 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <20130107091533.15325.1225.idtracker@ietfa.amsl.com> <084F3F88-FE01-4F9E-9EE2-3603A119C703@tik.ee.ethz.ch> In-Reply-To: <084F3F88-FE01-4F9E-9EE2-3603A119C703@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:37:45 -0000 Brian, Thanks. One small editorial comments in Section 7.4 OLD: (e.g. section 7.2, below) NEW: (e.g. section 7.2) Please treat this as an IETF LC comment. Regards, Benoit > Greetings, all. > > This revision of rfc5102bis addresses AD review comments. > > Best regards, > > Brian > > On Jan 7, 2013, at 10:15 AM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Flow Information Export Working Group of the IETF. >> >> Title : Information Model for IP Flow Information eXport (IPFIX) >> Author(s) : Benoit Claise >> Brian Trammell >> Filename : draft-ietf-ipfix-information-model-rfc5102bis-09.txt >> Pages : 22 >> Date : 2013-01-07 >> >> Abstract: >> This document provides an overview of the information model for the IP >> Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX >> Information Element Registry. It is used by the IPFIX Protocol for >> encoding measured traffic information and information related to the >> traffic Observation Point, the traffic Metering Process, and the >> Exporting Process. Although developed for the IPFIX Protocol, the model >> is defined in an open way that easily allows using it in other >> protocols, interfaces, and applications. This document obsoletes RFC >> 5102. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-information-model-rfc5102bis-09 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From trammell@tik.ee.ethz.ch Mon Jan 7 01:40:17 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6EB21F867D for ; Mon, 7 Jan 2013 01:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmksr173hyKK for ; Mon, 7 Jan 2013 01:40:17 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 46CF821F8585 for ; Mon, 7 Jan 2013 01:40:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1DDA7D9307; Mon, 7 Jan 2013 10:40:16 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eUkxSJ7PoETJ; Mon, 7 Jan 2013 10:40:15 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C4F98D9304; Mon, 7 Jan 2013 10:40:15 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50EA9766.5010701@cisco.com> Date: Mon, 7 Jan 2013 10:40:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA1B085-C29D-4E8D-906E-8C6157D4917F@tik.ee.ethz.ch> References: <20130107091533.15325.1225.idtracker@ietfa.amsl.com> <084F3F88-FE01-4F9E-9EE2-3603A119C703@tik.ee.ethz.ch> <50EA9766.5010701@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1499) Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:40:18 -0000 hi Benoit, thanks, missed that one. (Also missed on post-submission review: this document expires in July as = per the header, not in March as per page 1.) Best regards, Brian On Jan 7, 2013, at 10:37 AM, Benoit Claise wrote: > Brian, >=20 > Thanks. > One small editorial comments in Section 7.4 > OLD: > (e.g. section 7.2, below) > NEW: > (e.g. section 7.2) >=20 > Please treat this as an IETF LC comment. >=20 > Regards, Benoit >> Greetings, all. >>=20 >> This revision of rfc5102bis addresses AD review comments. >>=20 >> Best regards, >>=20 >> Brian >>=20 >> On Jan 7, 2013, at 10:15 AM, internet-drafts@ietf.org wrote: >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >>>=20 >>> Title : Information Model for IP Flow Information = eXport (IPFIX) >>> Author(s) : Benoit Claise >>> Brian Trammell >>> Filename : = draft-ietf-ipfix-information-model-rfc5102bis-09.txt >>> Pages : 22 >>> Date : 2013-01-07 >>>=20 >>> Abstract: >>> This document provides an overview of the information model for the = IP >>> Flow Information eXport (IPFIX) protocol, as defined in the IANA = IPFIX >>> Information Element Registry. It is used by the IPFIX Protocol for >>> encoding measured traffic information and information related to the >>> traffic Observation Point, the traffic Metering Process, and the >>> Exporting Process. Although developed for the IPFIX Protocol, the = model >>> is defined in an open way that easily allows using it in other >>> protocols, interfaces, and applications. This document obsoletes RFC >>> 5102. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc510= 2bis >>>=20 >>> There's also a htmlized version available at: >>> = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-0= 9 >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc5= 102bis-09 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >>=20 From trammell@tik.ee.ethz.ch Mon Jan 7 02:54:01 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F30221F870A for ; Mon, 7 Jan 2013 02:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09KxEdFiJHOk for ; Mon, 7 Jan 2013 02:54:00 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C08E221F8703 for ; Mon, 7 Jan 2013 02:54:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 07720D930B; Mon, 7 Jan 2013 11:53:54 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GNH71-f3VoIU; Mon, 7 Jan 2013 11:53:53 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C1837D9307; Mon, 7 Jan 2013 11:53:53 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50C65ACC.20505@net.in.tum.de> Date: Mon, 7 Jan 2013 11:53:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FDA9233-6B89-4B5B-A421-BFCD7963C8B5@tik.ee.ethz.ch> References: <50AEF1D1.9010809@auckland.ac.nz> <50C65ACC.20505@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1499) Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 10:54:01 -0000 Hi, Gerhard, Thanks for your comments; sorry for missing them in the last revision of = 5101bis. I'm applying these to a -05 revision now. One comments inline = (as always, points without comment are accepted into the revision = without discussion)... On Dec 10, 2012, at 10:57 PM, Gerhard Muenz wrote: > Still in 8.1, I do not think that this paragraph applies to UDP where = we now also allow TWM (as far as I understand): > "If a Collecting Process receives a new Template Record or Options = Template Record for an already-allocated Template ID, without having = received a withdrawal, it MUST ignore the new Template Record and = discard the old Template Record for the allocated ID; it SHOULD log the = error." Per the discussion we had last year about the tradeoff between code = reuse among transport protocols and interoperability between 5101 and = 5101bis, template withdrawals are now no longer specified as allowed on = UDP. See also the new (in -04) language on template management errors. As the = 5101 language is basically not self-interoperable (collectors are = forbidden from attempting to recover from errors which, depending on = interpretation, can only result from badly implemented or malicious = exporters), the final three paragraphs of section 8.1 are the current = suggestion for resolving this situation; do you see any issue with this = arrangement? Many thanks, best regards, Brian From muenz@net.in.tum.de Mon Jan 7 12:42:01 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994DE21F84F0 for ; Mon, 7 Jan 2013 12:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEfeAhr6r+Rh for ; Mon, 7 Jan 2013 12:42:01 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74621F84E0 for ; Mon, 7 Jan 2013 12:42:00 -0800 (PST) Received: from [192.168.2.36] (g230149133.adsl.alicedsl.de [92.230.149.133]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 6BA78188DF78; Mon, 7 Jan 2013 21:41:58 +0100 (CET) Message-ID: <50EB3318.6090607@net.in.tum.de> Date: Mon, 07 Jan 2013 21:42:00 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Trammell References: <50AEF1D1.9010809@auckland.ac.nz> <50C65ACC.20505@net.in.tum.de> <4FDA9233-6B89-4B5B-A421-BFCD7963C8B5@tik.ee.ethz.ch> In-Reply-To: <4FDA9233-6B89-4B5B-A421-BFCD7963C8B5@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:42:01 -0000 Brian, Thanks for the clarification. In 8.4, you write about Templates which are "expired" at the Exporting Process. Is it clear to the reader what "expiration" means in the context of Templates? Particularly, I do not understand what the EP is supposed to do in order to "allow the old Template to expire" as written in this sentence: "Template IDs MAY be reused by Exporting Processes by simply allowing the old Template to expire and exporting a new Template for the Template ID." My suggestion is to look for another wording and to avoid "expire". You could replace all occurrences of "expir*" in 8.4. and write about Templates which are no longer used by the Exporting Process. Apart from this minor issue, the spec is clear. Regards, Gerhard On 07.01.2013 11:53, Brian Trammell wrote: > Hi, Gerhard, > > Thanks for your comments; sorry for missing them in the last revision of 5101bis. I'm applying these to a -05 revision now. One comments inline (as always, points without comment are accepted into the revision without discussion)... > > On Dec 10, 2012, at 10:57 PM, Gerhard Muenz wrote: > >> Still in 8.1, I do not think that this paragraph applies to UDP where we now also allow TWM (as far as I understand): >> "If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, without having received a withdrawal, it MUST ignore the new Template Record and discard the old Template Record for the allocated ID; it SHOULD log the error." > > Per the discussion we had last year about the tradeoff between code reuse among transport protocols and interoperability between 5101 and 5101bis, template withdrawals are now no longer specified as allowed on UDP. > > See also the new (in -04) language on template management errors. As the 5101 language is basically not self-interoperable (collectors are forbidden from attempting to recover from errors which, depending on interpretation, can only result from badly implemented or malicious exporters), the final three paragraphs of section 8.1 are the current suggestion for resolving this situation; do you see any issue with this arrangement? > > Many thanks, best regards, > > Brian > > From trammell@tik.ee.ethz.ch Mon Jan 7 13:21:33 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD68221F88F1 for ; Mon, 7 Jan 2013 13:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdg8rOAQnYtJ for ; Mon, 7 Jan 2013 13:21:33 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B910F21F854D for ; Mon, 7 Jan 2013 13:21:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 353A4D9308; Mon, 7 Jan 2013 22:21:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g8QaSGvsFhTx; Mon, 7 Jan 2013 22:21:22 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id DD97ED9304; Mon, 7 Jan 2013 22:21:21 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50EB3318.6090607@net.in.tum.de> Date: Mon, 7 Jan 2013 22:21:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50AEF1D1.9010809@auckland.ac.nz> <50C65ACC.20505@net.in.tum.de> <4FDA9233-6B89-4B5B-A421-BFCD7963C8B5@tik.ee.ethz.ch> <50EB3318.6090607@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1499) Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:21:33 -0000 Hi, Gerhard, Many thanks for the comment; agreed, the change in language does make = template lifetime handling in UDP more clear. -05 to follow shortly. Best regards, Brian On Jan 7, 2013, at 9:42 PM, Gerhard Muenz wrote: > Brian, >=20 > Thanks for the clarification. >=20 > In 8.4, you write about Templates which are "expired" at the Exporting = Process. >=20 > Is it clear to the reader what "expiration" means in the context of = Templates? >=20 > Particularly, I do not understand what the EP is supposed to do in = order to "allow the old Template to expire" as written in this sentence: > "Template IDs MAY be reused by Exporting Processes by simply allowing = the old Template to expire and exporting a new Template for the Template = ID." >=20 > My suggestion is to look for another wording and to avoid "expire". = You could replace all occurrences of "expir*" in 8.4. and write about = Templates which are no longer used by the Exporting Process. >=20 > Apart from this minor issue, the spec is clear. >=20 > Regards, > Gerhard >=20 >=20 > On 07.01.2013 11:53, Brian Trammell wrote: >> Hi, Gerhard, >>=20 >> Thanks for your comments; sorry for missing them in the last revision = of 5101bis. I'm applying these to a -05 revision now. One comments = inline (as always, points without comment are accepted into the revision = without discussion)... >>=20 >> On Dec 10, 2012, at 10:57 PM, Gerhard Muenz = wrote: >>=20 >>> Still in 8.1, I do not think that this paragraph applies to UDP = where we now also allow TWM (as far as I understand): >>> "If a Collecting Process receives a new Template Record or Options = Template Record for an already-allocated Template ID, without having = received a withdrawal, it MUST ignore the new Template Record and = discard the old Template Record for the allocated ID; it SHOULD log the = error." >>=20 >> Per the discussion we had last year about the tradeoff between code = reuse among transport protocols and interoperability between 5101 and = 5101bis, template withdrawals are now no longer specified as allowed on = UDP. >>=20 >> See also the new (in -04) language on template management errors. As = the 5101 language is basically not self-interoperable (collectors are = forbidden from attempting to recover from errors which, depending on = interpretation, can only result from badly implemented or malicious = exporters), the final three paragraphs of section 8.1 are the current = suggestion for resolving this situation; do you see any issue with this = arrangement? >>=20 >> Many thanks, best regards, >>=20 >> Brian >>=20 >>=20 From internet-drafts@ietf.org Mon Jan 7 13:27:55 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F36C21F88FB; Mon, 7 Jan 2013 13:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXWP7sztKB9v; Mon, 7 Jan 2013 13:27:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F118F21F88C4; Mon, 7 Jan 2013 13:27:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107212754.6580.74055.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 13:27:54 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:27:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Specification of the IP Flow Information eXport (IPFIX) = Protocol for the Exchange of Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-05.txt Pages : 67 Date : 2013-01-07 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Mon Jan 7 13:43:10 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4031321F881A for ; Mon, 7 Jan 2013 13:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytV70E5Hu6OH for ; Mon, 7 Jan 2013 13:43:09 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8021F880B for ; Mon, 7 Jan 2013 13:43:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E6C52D9308 for ; Mon, 7 Jan 2013 22:42:58 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GJ8cNuSRH1gc for ; Mon, 7 Jan 2013 22:42:58 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A8AADD9304 for ; Mon, 7 Jan 2013 22:42:58 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <20130107212754.6580.74055.idtracker@ietfa.amsl.com> Date: Mon, 7 Jan 2013 22:42:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <948E90ED-FDF4-4C41-8598-8EF86AACA0CC@tik.ee.ethz.ch> References: <20130107212754.6580.74055.idtracker@ietfa.amsl.com> To: ipfix@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:43:10 -0000 Greetings, all, This revision should address the last of the WGLC comments; thanks to = all who reviewed for your excellent feedback! It is ready for write-up = and AD review. Best regards, Brian On Jan 7, 2013, at 10:27 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : Specification of the IP Flow Information = eXport (IPFIX) Protocol for the Exchange of Flow Information > Author(s) : Benoit Claise > Brian Trammell > Filename : draft-ietf-ipfix-protocol-rfc5101bis-05.txt > Pages : 67 > Date : 2013-01-07 >=20 > Abstract: > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting Traffic Flow information over > the network. In order to transmit Traffic Flow information from an > Exporting Process to an information Collecting Process, a common > representation of flow data and a standard means of communicating > them is required. This document describes how the IPFIX Data and > Template Records are carried over a number of transport protocols > from an IPFIX Exporting Process to an IPFIX Collecting Process. = This > document obsoletes RFC 5101. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-05 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-05= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From iesg-secretary@ietf.org Wed Jan 9 08:02:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35021F858E; Wed, 9 Jan 2013 08:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAC42h5qCaoa; Wed, 9 Jan 2013 08:02:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9321F8507; Wed, 9 Jan 2013 08:02:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130109160203.21770.46393.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 08:02:03 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Information Model for IP Flow Information eXport (IPFIX)) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 16:02:04 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Information Model for IP Flow Information eXport (IPFIX)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis/ballot/ No IPR declarations have been submitted directly on this I-D. From n.brownlee@auckland.ac.nz Thu Jan 10 13:44:31 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65421F8834 for ; Thu, 10 Jan 2013 13:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF4+ALsYZmke for ; Thu, 10 Jan 2013 13:44:30 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5C23721F8831 for ; Thu, 10 Jan 2013 13:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1357854270; x=1389390270; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ay2HyYInAd4SsmdbqDSpGUrVfglimgIJc/uqzgaYt7Y=; b=nkRgW8s2lUHL+ZrOd0lcAlcKVybfHuFTUaWGlPRo4mqvPxhZZ39APxVO 5nUBQgY2U7pLe1NpJqrylkDNhQnq+R8Slw0+0wfis0Du4+z0IsCcQFJJN YOPXSSMAE60vbpVMSdvpEOemJspL61OE7TK6mPM3SxtfeF6r+yFaRjrlL 4=; X-IronPort-AV: E=Sophos;i="4.84,447,1355050800"; d="scan'208";a="165612760" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 11 Jan 2013 10:44:28 +1300 Message-ID: <50EF363B.400@auckland.ac.nz> Date: Fri, 11 Jan 2013 10:44:27 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Trammell References: <20130107212754.6580.74055.idtracker@ietfa.amsl.com> <948E90ED-FDF4-4C41-8598-8EF86AACA0CC@tik.ee.ethz.ch> In-Reply-To: <948E90ED-FDF4-4C41-8598-8EF86AACA0CC@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix Working Group Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:44:31 -0000 Hi Brian: Happy new year! Thanks for all the work you've put into 5101bis. I see Ben Laurie's security review of 5102bis, pointing out that IPFIX "doesn't say anything about authenticating a requester, nor about access control." That made me wonder whether 5102bis should do so; what do you think? Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Thu Jan 10 15:08:58 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185C421F8678 for ; Thu, 10 Jan 2013 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftqLY6KO0FnZ for ; Thu, 10 Jan 2013 15:08:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CB7EC21F841D for ; Thu, 10 Jan 2013 15:08:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 32795D930A; Fri, 11 Jan 2013 00:08:51 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4RrrtTF9DQCs; Fri, 11 Jan 2013 00:08:50 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D8CD6D9307; Fri, 11 Jan 2013 00:08:50 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50EF363B.400@auckland.ac.nz> Date: Fri, 11 Jan 2013 00:08:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53954D1B-AEE0-4755-97E9-6A64DB306D71@tik.ee.ethz.ch> References: <20130107212754.6580.74055.idtracker@ietfa.amsl.com> <948E90ED-FDF4-4C41-8598-8EF86AACA0CC@tik.ee.ethz.ch> <50EF363B.400@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1499) Cc: ipfix Working Group Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 23:08:58 -0000 Hi, Nevil, I don't think 5102bis should discuss protocol-level security = considerations at all -- these are for 5101bis. I'm still reviewing = Ben's comments (which do indeed seem to apply to 5101bis), and will copy = the ipfix list on my comments/questions thereon, probably tomorrow = (well, later today, technically, CET). Cheers, Brian On Jan 10, 2013, at 10:44 PM, Nevil Brownlee = wrote: > Hi Brian: >=20 > Happy new year! Thanks for all the work you've put into 5101bis. >=20 > I see Ben Laurie's security review of 5102bis, pointing out that > IPFIX "doesn't say anything about authenticating a requester, nor > about access control." That made me wonder whether 5102bis should > do so; what do you think? >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Fri Jan 11 01:24:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6773221F873E; Fri, 11 Jan 2013 01:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E-FlJprZzUE; Fri, 11 Jan 2013 01:24:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9526C21F8629; Fri, 11 Jan 2013 01:24:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5B97FD930A; Fri, 11 Jan 2013 10:24:06 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IFp6uvcpHGFP; Fri, 11 Jan 2013 10:24:06 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 14CF8D9307; Fri, 11 Jan 2013 10:24:06 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: Date: Fri, 11 Jan 2013 10:24:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch> References: To: Ben Laurie X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org, The IESG , "ipfix@ietf.org Working Group" , secdir@ietf.org Subject: Re: [IPFIX] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:24:14 -0000 Hi, Ben, Many thanks for the review. Comments/questions thereon inline. On Jan 10, 2013, at 12:55 PM, Ben Laurie wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Summary: this document is part of a series of documents describing the > protocol, and only deals with data elements. As such, most security > considerations are dealt with elsewhere. (I'll address the following as comments on 5101 / 5101bis, specifically = section 11, which I assume you're referring to...) > However, I note that whilst a > good deal of attention is paid to integrity and authentication of the > data in those other documents, as far as I can see nothing is said > about authentication of the requester, As IPFIX is a push protocol designed for operation within a network = management infrastructure there is no "requester" per se. There are only = exporters and collectors, the former configured (out of band) to send = information to the latter, the latter to accept information from the = former. Section 11.3 of rfc5101(-bis) addresses authentication of = exporters and collectors.... > nor about access control. ...however, while the intention of section 11.3 of RFC5101(-bis) was to = state that collectors/exporters should only establish sessions with = peers that they could authenticate using TLS mutual authentication, on = rereading I see that this isn't explicitly stated in that section. We = should fix that. Section 11 is also a little outdated (at least with respect to = terminology for doing DNS-ID lookups) and appears to be needlessly = restrictive (e.g., TLS-PSK is not allowed although it would be useful in = this case). We should review this as well. > Given > that flow information is potentially quite sensitive, this is > surprising. The document itself seems OK, with nits. > Nits: >=20 > "3.1.14. string >=20 > The type "string" represents a finite-length string of valid > characters from the Unicode character encoding set > [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and = many > other international character sets to be used." >=20 > RFC 5610 says this is encoded using UTF-8. UTF-8 can have security > issues, e.g. sending a string with an incomplete UTF-8 encoded > character, which then swallows part of a following string, or causes > errors in parsers. Although this document may not be the right place > for it, it is unfortunate this potential problem is not mentioned. This is good point. Would you know of an existing description of this = problem, ideally with mitigation strategies at the receiver, that we = could reference here? Again, I think this would be something to address = in 5101bis, as 5102bis is concerned with _abstract_ data types, and = 5101bis presents the IPFIX-compatible encoding of those data types. Best regards, Brian= From benl@google.com Fri Jan 11 02:33:37 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD521F88EA for ; Fri, 11 Jan 2013 02:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdhuGu4czU5x for ; Fri, 11 Jan 2013 02:33:36 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEA921F88BD for ; Fri, 11 Jan 2013 02:33:32 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id r6so779511wey.10 for ; Fri, 11 Jan 2013 02:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PzisIdnmyfKCd0xSPFSM8/C8RaB1ljnvtrgdAr0CgEY=; b=lAW4Px7hIL26skOkHg9DHzhGH1bUR5IHK6IGr0yqA1I2+fHHL7T36OhvtLv8CM2NoT aLJs7r/MSEX0E1/hyae1d39wGKLq3LDe5zgOTmoRZ1iu9LEDMsswkKqSGMfx0XlFakQW qE9m4XHAN1RwLR0p+ftVEp96K4A3kig7f+AQXyHVkH5I9pbYa5QBz/nZnUVYTx/20cCj fM3u6s+rDwDuIEvHGa3Ija71w0VD4yv81rWfZWzyPnT9CpQGSCuhf+R/XhnBy3UcYNiU OEyQSkrYf74MlyMqolkJP4eNVSZ2SHorYwj5//vSRA0b30v1QAbZNJM6D0CiGVpYuJJ9 6PQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=PzisIdnmyfKCd0xSPFSM8/C8RaB1ljnvtrgdAr0CgEY=; b=em9ssxd46jlXjdLkO70Srxk0juoqmarp3zD49bLuyr3IVddFGK2bFOjIyntvnivRId 0q5GEQDwofRmmfgLzcscPDxeXTckpvJahgPxtPfnYHdpBkbgRol6X6d6Nw5oOctbBg7o +BqApoubV8SvBOW4Rpk67Pr1b0ZQX5jM20aCoeWB1E3Sj9EeHrTdrhSqkNl8DnepC7UF D2tfWOLd8k7SfxP+6b7eyJQNyJ2dXkTxzThsXccsTlpjpjcsKA9IgpfNm5njIauFmXoP MxqxpGGaiy5VShhELNyI2J7luoJdRJ8U06Gbl4rGoDM+suzf8u8+FvOlmSE19D83Fo3l F0pg== MIME-Version: 1.0 Received: by 10.180.77.68 with SMTP id q4mr14470656wiw.10.1357900411497; Fri, 11 Jan 2013 02:33:31 -0800 (PST) Received: by 10.194.234.134 with HTTP; Fri, 11 Jan 2013 02:33:31 -0800 (PST) In-Reply-To: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch> References: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch> Date: Fri, 11 Jan 2013 10:33:31 +0000 Message-ID: From: Ben Laurie To: Brian Trammell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmdtdYzBlhMKCxQURlArH4m7/7uco3vv+OELNAP4/uKaKxhP+kfw37p7INENUmw7g5XxzOQPhVc8Isc0FptmJ7b85VGq3Jq3WbsJLH3XH8WttzyoOE+P7uTw0HFgryam85u+k0UeJhsgGvjEA2DDfDKtqZF8I+soPck/rmVR+VJcqd46bdbQ9Uba9ii9kFynPROCQhI X-Mailman-Approved-At: Fri, 11 Jan 2013 02:59:09 -0800 Cc: draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org, The IESG , "ipfix@ietf.org Working Group" , secdir@ietf.org Subject: Re: [IPFIX] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:33:37 -0000 On 11 January 2013 09:24, Brian Trammell wrote: > Hi, Ben, > > Many thanks for the review. Comments/questions thereon inline. > > On Jan 10, 2013, at 12:55 PM, Ben Laurie wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Summary: this document is part of a series of documents describing the >> protocol, and only deals with data elements. As such, most security >> considerations are dealt with elsewhere. > > (I'll address the following as comments on 5101 / 5101bis, specifically s= ection 11, which I assume you're referring to...) Right. > >> However, I note that whilst a >> good deal of attention is paid to integrity and authentication of the >> data in those other documents, as far as I can see nothing is said >> about authentication of the requester, > > As IPFIX is a push protocol designed for operation within a network manag= ement infrastructure there is no "requester" per se. There are only exporte= rs and collectors, the former configured (out of band) to send information = to the latter, the latter to accept information from the former. Section 11= .3 of rfc5101(-bis) addresses authentication of exporters and collectors...= . Ah, that was not clear to me, thanks for the explanation. It might be nice to at least mention that the out of band configuration is also security sensitive (and perhaps mention the push nature of the protocol in the security considerations to make it clearer for the non-expert). > >> nor about access control. > > ...however, while the intention of section 11.3 of RFC5101(-bis) was to s= tate that collectors/exporters should only establish sessions with peers th= at they could authenticate using TLS mutual authentication, on rereading I = see that this isn't explicitly stated in that section. We should fix that. > > Section 11 is also a little outdated (at least with respect to terminolog= y for doing DNS-ID lookups) and appears to be needlessly restrictive (e.g.,= TLS-PSK is not allowed although it would be useful in this case). We shoul= d review this as well. I didn;t intend to review 5101 as well, but anyway re-reading this section raises some questions 1. What is meant by "Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates" is a little unclear - does it mean the cert must match an authorized cert, or that it must chain from one? 2. There's a requirement to match the DNS name - but the server end of the connection may not have access to the client's (relevant) DNS name. Presumably there's some more complex process involving DNS lookups you have in mind here? (And if you introduce PSK, there's no cert). 3. As it stands it would be perfectly OK for an exporter to connect to a collector and then send it data for flows it is not configured to send (but are expected from another exporter). > > >> Given >> that flow information is potentially quite sensitive, this is >> surprising. The document itself seems OK, with nits. > >> Nits: >> >> "3.1.14. string >> >> The type "string" represents a finite-length string of valid >> characters from the Unicode character encoding set >> [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many >> other international character sets to be used." >> >> RFC 5610 says this is encoded using UTF-8. UTF-8 can have security >> issues, e.g. sending a string with an incomplete UTF-8 encoded >> character, which then swallows part of a following string, or causes >> errors in parsers. Although this document may not be the right place >> for it, it is unfortunate this potential problem is not mentioned. > > This is good point. Would you know of an existing description of this pro= blem, ideally with mitigation strategies at the receiver, that we could ref= erence here? Again, I think this would be something to address in 5101bis, = as 5102bis is concerned with _abstract_ data types, and 5101bis presents th= e IPFIX-compatible encoding of those data types. "Unicode Security Considerations" (http://www.unicode.org/reports/tr36/#UTF-8_Exploit) has a good discussion. From ramk@Brocade.com Fri Jan 18 12:06:36 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2D721F874A for ; Fri, 18 Jan 2013 12:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEvBWXs7+42Q for ; Fri, 18 Jan 2013 12:06:36 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1960B21F870A for ; Fri, 18 Jan 2013 12:06:36 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r0IK2Unv031897 for ; Fri, 18 Jan 2013 12:06:35 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 19yakyr367-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 18 Jan 2013 12:06:35 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 18 Jan 2013 12:06:35 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 18 Jan 2013 12:06:34 -0800 From: ramki Krishnan To: "ipfix@ietf.org" Date: Fri, 18 Jan 2013 12:06:25 -0800 Thread-Topic: test message - please ignore - EOM Thread-Index: Ac31t0tvsFlzX2P/SvW+BrNok69boA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1EA48HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=3 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301180202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-18_06:2013-01-18, 2013-01-18, 1970-01-01 signatures=0 Subject: [IPFIX] test message - please ignore - EOM X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:06:36 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1EA48HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1EA48HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

<= /html>= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1EA48HQ1EXCH01corp_--