From ipfix-bounces@ietf.org Wed Jun 4 14:59:24 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AD73A6D37; Wed, 4 Jun 2008 14:59:24 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7D23A6D3F for ; Wed, 4 Jun 2008 14:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpyt7n9Gm-Uw for ; Wed, 4 Jun 2008 14:59:21 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 4FD393A6D15 for ; Wed, 4 Jun 2008 14:58:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6397118E1C for ; Thu, 5 Jun 2008 09:59:00 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7cxYCQlGYCg for ; Thu, 5 Jun 2008 09:59:00 +1200 (NZST) Received: from [130.216.38.130] (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A2D318ECF for ; Thu, 5 Jun 2008 09:59:00 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <33030B25-F008-4258-9DCB-115DC92C5075@auckland.ac.nz> To: IETF IPFIX Working Group From: Nevil Brownlee Date: Thu, 5 Jun 2008 09:58:59 +1200 X-Mailer: Apple Mail (2.753.1) Subject: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: draft-ietf-ipfix-exporting-type-01.txt was published back in February; this version resolved all issues raised in earlier versions, and there's been no discussion on the IPFIX list since. Its Working Group Last Call starts now (5 June 08), and will finish on Friday 20 June 08. Please read it one more time - I need some reviews so that I can prepare the Shepherd Document for it. And of course, please send any or all your comments/feedback to the IPFIX list. Cheers, Nevil IPFIX Co-Chair --------------------------------------------------------------------- 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jun 4 14:59:24 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AD73A6D37; Wed, 4 Jun 2008 14:59:24 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7D23A6D3F for ; Wed, 4 Jun 2008 14:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpyt7n9Gm-Uw for ; Wed, 4 Jun 2008 14:59:21 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 4FD393A6D15 for ; Wed, 4 Jun 2008 14:58:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6397118E1C for ; Thu, 5 Jun 2008 09:59:00 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7cxYCQlGYCg for ; Thu, 5 Jun 2008 09:59:00 +1200 (NZST) Received: from [130.216.38.130] (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A2D318ECF for ; Thu, 5 Jun 2008 09:59:00 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <33030B25-F008-4258-9DCB-115DC92C5075@auckland.ac.nz> To: IETF IPFIX Working Group From: Nevil Brownlee Date: Thu, 5 Jun 2008 09:58:59 +1200 X-Mailer: Apple Mail (2.753.1) Subject: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: draft-ietf-ipfix-exporting-type-01.txt was published back in February; this version resolved all issues raised in earlier versions, and there's been no discussion on the IPFIX list since. Its Working Group Last Call starts now (5 June 08), and will finish on Friday 20 June 08. Please read it one more time - I need some reviews so that I can prepare the Shepherd Document for it. And of course, please send any or all your comments/feedback to the IPFIX list. Cheers, Nevil IPFIX Co-Chair --------------------------------------------------------------------- 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfis@mail.com Wed Jun 11 16:49:44 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DCB3A699B for ; Wed, 11 Jun 2008 16:49:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -20.906 X-Spam-Level: X-Spam-Status: No, score=-20.906 tagged_above=-999 required=5 tests=[BAYES_80=2, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6hLiOs5xFl6 for ; Wed, 11 Jun 2008 16:49:44 -0700 (PDT) Received: from chello089077205198.chello.pl (chello089077205198.chello.pl [89.77.205.198]) by core3.amsl.com (Postfix) with SMTP id 7C6B63A68F1 for ; Wed, 11 Jun 2008 16:49:43 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080612025009.10112.qmail@chello089077205198.chello.pl> To: Subject: Dear ipfix-archive@lists.ietf.org June 84% 0FF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2008 16:49:43 -0700 (PDT)
Click Here!

©2007 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From ipfix-bounces@ietf.org Thu Jun 12 06:29:45 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCCF28C12F; Thu, 12 Jun 2008 06:29:45 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7465F28C12B for ; Thu, 12 Jun 2008 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGv6w2Z7PqTf for ; Thu, 12 Jun 2008 06:29:43 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 1D2563A6915 for ; Thu, 12 Jun 2008 06:29:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CDU7U13556; Thu, 12 Jun 2008 15:30:07 +0200 (CEST) Received: from [10.61.98.75] (dhcp-10-61-98-75.cisco.com [10.61.98.75]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CDTxA20496; Thu, 12 Jun 2008 15:30:07 +0200 (CEST) Message-ID: <485124D1.9050209@cisco.com> Date: Thu, 12 Jun 2008 15:29:53 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gerhard Muenz References: <48186300.8000104@informatik.uni-tuebingen.de> In-Reply-To: <48186300.8000104@informatik.uni-tuebingen.de> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0927988711==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0927988711== Content-Type: multipart/alternative; boundary="------------030609050005070905050606" This is a multi-part message in MIME format. --------------030609050005070905050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Dear all, > > The IPFIX-MIB specifies: > > ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "On Exporters this object contains the number of packets > after which IPFIX Templates MUST be resent by the > Exporter. > > On Collectors this object contains the lifetime in number > of packets after which a Template becomes invalid when it > is not received again within this lifetime. > > This object is only valid if ipfixTransportSessionProtocol > has the value 17 (UDP). In all other cases the value MUST > be 0." > DEFVAL { 0 } > ::= { ipfixTransportSessionEntry 11 } > > > (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) > > Isn't the description ambiguous? > "On Exporters this object contains the number of packets after which > IPFIX Templates MUST be resent by the Exporter." > What is meant by "packets" in this context? > - packets observed? > - packets accounted? > > I assume it is the number of IPFIX Messages exported, right? > On the Exporter, correct. On the collector side, this is "exported" as well (just for the case of UDP loses some packets). So we must look at the "Sequence Number" Regards, Benoit. > Then, the description should be changed accordingly. > > Regards, > Gerhard > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------030609050005070905050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Dear all,

The IPFIX-MIB specifies:

  ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "On Exporters this object contains the number of packets
          after which IPFIX Templates MUST be resent by the
          Exporter.

          On Collectors this object contains the lifetime in number
          of packets after which a Template becomes invalid when it
          is not received again within this lifetime.

          This object is only valid if ipfixTransportSessionProtocol
          has the value 17 (UDP). In all other cases the value MUST
          be 0."
      DEFVAL      { 0 }
      ::= { ipfixTransportSessionEntry 11 }


(similarly for ipfixTransportSessionOptionTemplateRefreshPacket)

Isn't the description ambiguous?
"On Exporters this object contains the number of packets after which
IPFIX Templates MUST be resent by the Exporter."
What is meant by "packets" in this context?
- packets observed?
- packets accounted?

I assume it is the number of IPFIX Messages exported, right?
On the Exporter, correct.
On the collector side, this is "exported" as well (just for the case of UDP loses some packets). So we must look at the "Sequence Number"

Regards, Benoit.
Then, the description should be changed accordingly.

Regards,
Gerhard

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------030609050005070905050606-- --===============0927988711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0927988711==-- From ipfix-bounces@ietf.org Thu Jun 12 06:29:45 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCCF28C12F; Thu, 12 Jun 2008 06:29:45 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7465F28C12B for ; Thu, 12 Jun 2008 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGv6w2Z7PqTf for ; Thu, 12 Jun 2008 06:29:43 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 1D2563A6915 for ; Thu, 12 Jun 2008 06:29:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CDU7U13556; Thu, 12 Jun 2008 15:30:07 +0200 (CEST) Received: from [10.61.98.75] (dhcp-10-61-98-75.cisco.com [10.61.98.75]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CDTxA20496; Thu, 12 Jun 2008 15:30:07 +0200 (CEST) Message-ID: <485124D1.9050209@cisco.com> Date: Thu, 12 Jun 2008 15:29:53 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gerhard Muenz References: <48186300.8000104@informatik.uni-tuebingen.de> In-Reply-To: <48186300.8000104@informatik.uni-tuebingen.de> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0927988711==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0927988711== Content-Type: multipart/alternative; boundary="------------030609050005070905050606" This is a multi-part message in MIME format. --------------030609050005070905050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Dear all, > > The IPFIX-MIB specifies: > > ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "On Exporters this object contains the number of packets > after which IPFIX Templates MUST be resent by the > Exporter. > > On Collectors this object contains the lifetime in number > of packets after which a Template becomes invalid when it > is not received again within this lifetime. > > This object is only valid if ipfixTransportSessionProtocol > has the value 17 (UDP). In all other cases the value MUST > be 0." > DEFVAL { 0 } > ::= { ipfixTransportSessionEntry 11 } > > > (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) > > Isn't the description ambiguous? > "On Exporters this object contains the number of packets after which > IPFIX Templates MUST be resent by the Exporter." > What is meant by "packets" in this context? > - packets observed? > - packets accounted? > > I assume it is the number of IPFIX Messages exported, right? > On the Exporter, correct. On the collector side, this is "exported" as well (just for the case of UDP loses some packets). So we must look at the "Sequence Number" Regards, Benoit. > Then, the description should be changed accordingly. > > Regards, > Gerhard > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------030609050005070905050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Dear all,

The IPFIX-MIB specifies:

  ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "On Exporters this object contains the number of packets
          after which IPFIX Templates MUST be resent by the
          Exporter.

          On Collectors this object contains the lifetime in number
          of packets after which a Template becomes invalid when it
          is not received again within this lifetime.

          This object is only valid if ipfixTransportSessionProtocol
          has the value 17 (UDP). In all other cases the value MUST
          be 0."
      DEFVAL      { 0 }
      ::= { ipfixTransportSessionEntry 11 }


(similarly for ipfixTransportSessionOptionTemplateRefreshPacket)

Isn't the description ambiguous?
"On Exporters this object contains the number of packets after which
IPFIX Templates MUST be resent by the Exporter."
What is meant by "packets" in this context?
- packets observed?
- packets accounted?

I assume it is the number of IPFIX Messages exported, right?
On the Exporter, correct.
On the collector side, this is "exported" as well (just for the case of UDP loses some packets). So we must look at the "Sequence Number"

Regards, Benoit.
Then, the description should be changed accordingly.

Regards,
Gerhard

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------030609050005070905050606-- --===============0927988711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0927988711==-- From ipfix-bounces@ietf.org Thu Jun 12 06:45:32 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5885E3A6AAA; Thu, 12 Jun 2008 06:45:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059513A6AAA for ; Thu, 12 Jun 2008 06:45:31 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2G-GG-uC45q for ; Thu, 12 Jun 2008 06:45:25 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 659F13A6818 for ; Thu, 12 Jun 2008 06:45:20 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K6n7X-0003dF-IK; Thu, 12 Jun 2008 15:45:43 +0200 Message-ID: <4851288E.1050602@informatik.uni-tuebingen.de> Date: Thu, 12 Jun 2008 15:45:50 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Benoit Claise References: <48186300.8000104@informatik.uni-tuebingen.de> <485124D1.9050209@cisco.com> In-Reply-To: <485124D1.9050209@cisco.com> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977677174==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0977677174== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030703090209070402050100" This is a cryptographically signed message in MIME format. --------------ms030703090209070402050100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, I do not know if you got my point. I wanted to say that "number of packets" should be replaced by "number of IPFIX Messages" because packets could be interpreted as packets observed at the OP. Regards, Gerhard Benoit Claise wrote: > Gerhard, >> Dear all, >> >> The IPFIX-MIB specifies: >> >> ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE >> SYNTAX Unsigned32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "On Exporters this object contains the number of packets >> after which IPFIX Templates MUST be resent by the >> Exporter. >> >> On Collectors this object contains the lifetime in number >> of packets after which a Template becomes invalid when it >> is not received again within this lifetime. >> >> This object is only valid if ipfixTransportSessionProtocol >> has the value 17 (UDP). In all other cases the value MUST >> be 0." >> DEFVAL { 0 } >> ::=3D { ipfixTransportSessionEntry 11 } >> >> >> (similarly for ipfixTransportSessionOptioFrom ipfix-bounces@ietf.org Thu Jun 12 06:45:32 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5885E3A6AAA; Thu, 12 Jun 2008 06:45:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059513A6AAA for ; Thu, 12 Jun 2008 06:45:31 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2G-GG-uC45q for ; Thu, 12 Jun 2008 06:45:25 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 659F13A6818 for ; Thu, 12 Jun 2008 06:45:20 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K6n7X-0003dF-IK; Thu, 12 Jun 2008 15:45:43 +0200 Message-ID: <4851288E.1050602@informatik.uni-tuebingen.de> Date: Thu, 12 Jun 2008 15:45:50 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Benoit Claise References: <48186300.8000104@informatik.uni-tuebingen.de> <485124D1.9050209@cisco.com> In-Reply-To: <485124D1.9050209@cisco.com> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977677174==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0977677174== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030703090209070402050100" This is a cryptographically signed message in MIME format. --------------ms030703090209070402050100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, I do not know if you got my point. I wanted to say that "number of packets" should be replaced by "number of IPFIX Messages" because packets could be interpreted as packets observed at the OP. Regards, Gerhard Benoit Claise wrote: > Gerhard, >> Dear all, >> >> The IPFIX-MIB specifies: >> >> ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE >> SYNTAX Unsigned32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "On Exporters this object contains the number of packets >> after which IPFIX Templates MUST be resent by the >> Exporter. >> >> On Collectors this object contains the lifetime in number >> of packets after which a Template becomes invalid when it >> is not received again within this lifetime. >> >> This object is only valid if ipfixTransportSessionProtocol >> has the value 17 (UDP). In all other cases the value MUST >> be 0." >> DEFVAL { 0 } >> ::=3D { ipfixTransportSessionEntry 11 } >> >> >> (similarly for ipfixTransportSessionOptionTnTemplateRefreshPacket) >> >> Isn't the description ambiguous? >> "On Exporters this object contains the number of packets after which >> IPFIX Templates MUST be resent by the Exporter." >> What is meant by "packets" in this context? >> - packets observed? >> - packets accounted? >> >> I assume it is the number of IPFIX Messages exported, right? >> =20 > On the Exporter, correct. > On the collector side, this is "exported" as well (just for the case of= > UDP loses some packets). So we must look at the "Sequence Number" >=20 > Regards, Benoit. >> Then, the description should be changed accordingly. >> >> Regards, >> Gerhard >> >> =20 >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> =20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030703090209070402050100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWemplateRefreshPacket) >> >> Isn't the description ambiguous? >> "On Exporters this object contains the number of packets after which >> IPFIX Templates MUST be resent by the Exporter." >> What is meant by "packets" in this context? >> - packets observed? >> - packets accounted? >> >> I assume it is the number of IPFIX Messages exported, right? >> =20 > On the Exporter, correct. > On the collector side, this is "exported" as well (just for the case of= > UDP loses some packets). So we must look at the "Sequence Number" >=20 > Regards, Benoit. >> Then, the description should be changed accordingly. >> >> Regards, >> Gerhard >> >> =20 >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> =20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030703090209070402050100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0x0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxMjEzNDU1MFowIwYJKoZIhvcNAQkEMRYEFKVtnE3WhX0s 1/2qdbVkS1LH5mhuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCdjE5AfudRTiK5oPCO74qWTQ87sgT6JZYAcdMOl+jTPX30v9RvWxz73/Ya i8GE0/cmWqnR8ZMWZ2lKgNoN1LdYEbFSkPM98mSXYEwnADx3DvxZfb3RdvW3ES5l2QtrhM/m 6nTVABGX1fivgOo/JTakDpZVPbH4TFjScBlOw5IhbzuNzZV2b5AGzOdqV1v8wTescK7EOpC4 Lf0aO3QrMyDJjAJ6Htj6h/E9LF1b39TtL8xGLOkIEdUUewkHRpWntBlyzrBDH69i+aq/bXjV M5t+L/N16d+Q73GpXBDtwM6DBpVWA+7hnDgXlmauKygyE7kpd2Cz4IT4qLUYTyXX6RbcAAAA AAAA --------------ms030703090209070402050100-- --===============0977677174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0977677174==-- aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxMjEzNDU1MFowIwYJKoZIhvcNAQkEMRYEFKVtnE3WhX0s 1/2qdbVkS1LH5mhuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCdjE5AfudRTiK5oPCO74qWTQ87sgT6JZYAcdMOl+jTPX30v9RvWxz73/Ya i8GE0/cmWqnR8ZMWZ2lKgNoN1LdYEbFSkPM98mSXYEwnADx3DvxZfb3RdvW3ES5l2QtrhM/m 6nTVABGX1fivgOo/JTakDpZVPbH4TFjScBlOw5IhbzuNzZV2b5AGzOdqV1v8wTescK7EOpC4 Lf0aO3QrMyDJjAJ6Htj6h/E9LF1b39TtL8xGLOkIEdUUewkHRpWntBlyzrBDH69i+aq/bXjV M5t+L/N16d+Q73GpXBDtwM6DBpVWA+7hnDgXlmauKygyE7kpd2Cz4IT4qLUYTyXX6RbcAAAA AAAA --------------ms030703090209070402050100-- --===============0977677174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0977677174==-- From ipfix-bounces@ietf.org Thu Jun 12 08:09:50 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BCD3A6AFE; Thu, 12 Jun 2008 08:09:50 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906A63A686D for ; Thu, 12 Jun 2008 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OYqGk4YtG7o for ; Thu, 12 Jun 2008 08:09:45 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 0D3CF3A6AFE for ; Thu, 12 Jun 2008 08:09:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CFADq24345; Thu, 12 Jun 2008 17:10:13 +0200 (CEST) Received: from [10.61.98.75] (dhcp-10-61-98-75.cisco.com [10.61.98.75]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CFACA19735; Thu, 12 Jun 2008 17:10:12 +0200 (CEST) Message-ID: <48513C4C.5030606@cisco.com> Date: Thu, 12 Jun 2008 17:10:04 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gerhard Muenz References: <48186300.8000104@informatik.uni-tuebingen.de> <485124D1.9050209@cisco.com> <4851288E.1050602@informatik.uni-tuebingen.de> In-Reply-To: <4851288E.1050602@informatik.uni-tuebingen.de> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0893123128==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0893123128== Content-Type: multipart/alternative; boundary="------------070301070800020102000804" This is a multi-part message in MIME format. --------------070301070800020102000804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, I think I got your point, but took a shortcut in the answer. My fault. I see two issues in this email. First, "number of packets" should be replaced by "number of IPFIX Messages". Yes, definitively Second, which IPFIX Messages: observed? accounted? exported? And this answer is "exported", both in the Exporters and Collector sentences So it should become something such as "On Exporters this object contains the number of exported IPFIX Messages after which IPFIX Templates MUST be resent by the Exporter. On Collectors this object contains the lifetime in number of exported IPFIX Messages after which a Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be 0." Do we agree? Regards, Benoit. > Benoit, > > I do not know if you got my point. > > I wanted to say that "number of packets" should be replaced by > "number of IPFIX Messages" because packets could be interpreted as > packets observed at the OP. > > Regards, > Gerhard > > > Benoit Claise wrote: > >> Gerhard, >> >>> Dear all, >>> >>> The IPFIX-MIB specifies: >>> >>> ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE >>> SYNTAX Unsigned32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "On Exporters this object contains the number of packets >>> after which IPFIX Templates MUST be resent by the >>> Exporter. >>> >>> On Collectors this object contains the lifetime in number >>> of packets after which a Template becomes invalid when it >>> is not received again within this lifetime. >>> >>> This object is only valid if ipfixTransportSessionProtocol >>> has the value 17 (UDP). In all other cases the value MUST >>> be 0." >>> DEFVAL { 0 } >>> ::= { ipfixTransportSessionEntry 11 } >>> >>> >>> (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) >>> >>> Isn't the description ambiguous? >>> "On Exporters this object contains the number of packets after which >>> IPFIX Templates MUST be resent by the Exporter." >>> What is meant by "packets" in this context? >>> - packets observed? >>> - packets accounted? >>> >>> I assume it is the number of IPFIX Messages exported, right? >>> >>> >> On the Exporter, correct. >> On the collector side, this is "exported" as well (just for the case of >> UDP loses some packets). So we must look at the "Sequence Number" >> >> Regards, Benoit. >> >>> Then, the description should be changed accordingly. >>> >>> Regards, >>> Gerhard >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> > > --------------070301070800020102000804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

I think I got your point, but took a shortcut in the answer. My fault.
I see two issues in this email.
First, "number of packets" should be replaced by "number of IPFIX Messages". Yes, definitively
Second, which IPFIX Messages: observed? accounted? exported? And this answer is "exported", both in the Exporters and Collector sentences

So it should become something such as
          "On Exporters this object contains the number of exported IPFIX Messages
          after which IPFIX Templates MUST be resent by the
          Exporter.

          On Collectors this object contains the lifetime in number
          of exported IPFIX Messages after which a Template becomes invalid when it
          is not received again within this lifetime. 

          This object is only valid if ipfixTransportSessionProtocol
          has the value 17 (UDP). In all other cases the value MUST
          be 0."

Do we agree?
Regards, Benoit.

Benoit,

I do not know if you got my point.

I wanted to say that  "number of packets"  should be replaced by
"number of IPFIX Messages"  because packets could be interpreted as
packets observed at the OP.

Regards,
Gerhard


Benoit Claise wrote:
  
Gerhard,
    
Dear all,

The IPFIX-MIB specifies:

  ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "On Exporters this object contains the number of packets
          after which IPFIX Templates MUST be resent by the
          Exporter.

          On Collectors this object contains the lifetime in number
          of packets after which a Template becomes invalid when it
          is not received again within this lifetime.

          This object is only valid if ipfixTransportSessionProtocol
          has the value 17 (UDP). In all other cases the value MUST
          be 0."
      DEFVAL      { 0 }
      ::= { ipfixTransportSessionEntry 11 }


(similarly for ipfixTransportSessionOptionTemplateRefreshPacket)

Isn't the description ambiguous?
"On Exporters this object contains the number of packets after which
IPFIX Templates MUST be resent by the Exporter."
What is meant by "packets" in this context?
- packets observed?
- packets accounted?

I assume it is the number of IPFIX Messages exported, right?
  
      
On the Exporter, correct.
On the collector side, this is "exported" as well (just for the case of
UDP loses some packets). So we must look at the "Sequence Number"

Regards, Benoit.
    
Then, the description should be changed accordingly.

Regards,
Gerhard

  
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------070301070800020102000804-- --===============0893123128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0893123128==-- From ipfix-bounces@ietf.org Thu Jun 12 08:09:50 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BCD3A6AFE; Thu, 12 Jun 2008 08:09:50 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906A63A686D for ; Thu, 12 Jun 2008 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OYqGk4YtG7o for ; Thu, 12 Jun 2008 08:09:45 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 0D3CF3A6AFE for ; Thu, 12 Jun 2008 08:09:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CFADq24345; Thu, 12 Jun 2008 17:10:13 +0200 (CEST) Received: from [10.61.98.75] (dhcp-10-61-98-75.cisco.com [10.61.98.75]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5CFACA19735; Thu, 12 Jun 2008 17:10:12 +0200 (CEST) Message-ID: <48513C4C.5030606@cisco.com> Date: Thu, 12 Jun 2008 17:10:04 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gerhard Muenz References: <48186300.8000104@informatik.uni-tuebingen.de> <485124D1.9050209@cisco.com> <4851288E.1050602@informatik.uni-tuebingen.de> In-Reply-To: <4851288E.1050602@informatik.uni-tuebingen.de> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0893123128==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0893123128== Content-Type: multipart/alternative; boundary="------------070301070800020102000804" This is a multi-part message in MIME format. --------------070301070800020102000804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, I think I got your point, but took a shortcut in the answer. My fault. I see two issues in this email. First, "number of packets" should be replaced by "number of IPFIX Messages". Yes, definitively Second, which IPFIX Messages: observed? accounted? exported? And this answer is "exported", both in the Exporters and Collector sentences So it should become something such as "On Exporters this object contains the number of exported IPFIX Messages after which IPFIX Templates MUST be resent by the Exporter. On Collectors this object contains the lifetime in number of exported IPFIX Messages after which a Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be 0." Do we agree? Regards, Benoit. > Benoit, > > I do not know if you got my point. > > I wanted to say that "number of packets" should be replaced by > "number of IPFIX Messages" because packets could be interpreted as > packets observed at the OP. > > Regards, > Gerhard > > > Benoit Claise wrote: > >> Gerhard, >> >>> Dear all, >>> >>> The IPFIX-MIB specifies: >>> >>> ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE >>> SYNTAX Unsigned32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "On Exporters this object contains the number of packets >>> after which IPFIX Templates MUST be resent by the >>> Exporter. >>> >>> On Collectors this object contains the lifetime in number >>> of packets after which a Template becomes invalid when it >>> is not received again within this lifetime. >>> >>> This object is only valid if ipfixTransportSessionProtocol >>> has the value 17 (UDP). In all other cases the value MUST >>> be 0." >>> DEFVAL { 0 } >>> ::= { ipfixTransportSessionEntry 11 } >>> >>> >>> (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) >>> >>> Isn't the description ambiguous? >>> "On Exporters this object contains the number of packets after which >>> IPFIX Templates MUST be resent by the Exporter." >>> What is meant by "packets" in this context? >>> - packets observed? >>> - packets accounted? >>> >>> I assume it is the number of IPFIX Messages exported, right? >>> >>> >> On the Exporter, correct. >> On the collector side, this is "exported" as well (just for the case of >> UDP loses some packets). So we must look at the "Sequence Number" >> >> Regards, Benoit. >> >>> Then, the description should be changed accordingly. >>> >>> Regards, >>> Gerhard >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> > > --------------070301070800020102000804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

I think I got your point, but took a shortcut in the answer. My fault.
I see two issues in this email.
First, "number of packets" should be replaced by "number of IPFIX Messages". Yes, definitively
Second, which IPFIX Messages: observed? accounted? exported? And this answer is "exported", both in the Exporters and Collector sentences

So it should become something such as
          "On Exporters this object contains the number of exported IPFIX Messages
          after which IPFIX Templates MUST be resent by the
          Exporter.

          On Collectors this object contains the lifetime in number
          of exported IPFIX Messages after which a Template becomes invalid when it
          is not received again within this lifetime. 

          This object is only valid if ipfixTransportSessionProtocol
          has the value 17 (UDP). In all other cases the value MUST
          be 0."

Do we agree?
Regards, Benoit.

Benoit,

I do not know if you got my point.

I wanted to say that  "number of packets"  should be replaced by
"number of IPFIX Messages"  because packets could be interpreted as
packets observed at the OP.

Regards,
Gerhard


Benoit Claise wrote:
  
Gerhard,
    
Dear all,

The IPFIX-MIB specifies:

  ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "On Exporters this object contains the number of packets
          after which IPFIX Templates MUST be resent by the
          Exporter.

          On Collectors this object contains the lifetime in number
          of packets after which a Template becomes invalid when it
          is not received again within this lifetime.

          This object is only valid if ipfixTransportSessionProtocol
          has the value 17 (UDP). In all other cases the value MUST
          be 0."
      DEFVAL      { 0 }
      ::= { ipfixTransportSessionEntry 11 }


(similarly for ipfixTransportSessionOptionTemplateRefreshPacket)

Isn't the description ambiguous?
"On Exporters this object contains the number of packets after which
IPFIX Templates MUST be resent by the Exporter."
What is meant by "packets" in this context?
- packets observed?
- packets accounted?

I assume it is the number of IPFIX Messages exported, right?
  
      
On the Exporter, correct.
On the collector side, this is "exported" as well (just for the case of
UDP loses some packets). So we must look at the "Sequence Number"

Regards, Benoit.
    
Then, the description should be changed accordingly.

Regards,
Gerhard

  
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------070301070800020102000804-- --===============0893123128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0893123128==-- From ipfix-bounces@ietf.org Thu Jun 12 12:44:27 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F613A69E4; Thu, 12 Jun 2008 12:44:27 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EC03A69E4 for ; Thu, 12 Jun 2008 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o473a5MsnGzu for ; Thu, 12 Jun 2008 12:44:23 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 3AF8B3A686D for ; Thu, 12 Jun 2008 12:44:23 -0700 (PDT) Received: from u-173-c251.cs.uni-tuebingen.de (u-173-c251.cs.uni-tuebingen.de [134.2.173.251]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m5CJilhv016635; Thu, 12 Jun 2008 21:44:47 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=www.ri.uni-tuebingen.de ident=www-data) by u-173-c251.cs.uni-tuebingen.de with esmtp (Exim 4.50) id 1K6skf-0005P1-Il; Thu, 12 Jun 2008 21:46:29 +0200 Received: from 195.4.205.55 (SquirrelMail authenticated user muenz) by www.ri.uni-tuebingen.de with HTTP; Thu, 12 Jun 2008 21:46:29 +0200 (CEST) Message-ID: <61117.195.4.205.55.1213299989.squirrel@www.ri.uni-tuebingen.de> In-Reply-To: <48513C4C.5030606@cisco.com> References: <48186300.8000104@informatik.uni-tuebingen.de> <485124D1.9050209@cisco.com> <4851288E.1050602@informatik.uni-tuebingen.de> <48513C4C.5030606@cisco.com> Date: Thu, 12 Jun 2008 21:46:29 +0200 (CEST) From: "Gerhard Muenz" To: "Benoit Claise" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.55; VDF: 7.0.4.186; host: mx05) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Thu, June 12, 2008 17:10, Benoit Claise said: > I think I got your point, but took a shortcut in the answer. My fault. > I see two issues in this email. > First, "number of packets" should be replaced by "number of IPFIX > Messages". Yes, definitively > Second, which IPFIX Messages: observed? accounted? exported? And this > answer is "exported", both in the Exporters and Collector sentences > > So it should become something such as > > "On Exporters this object contains the number of exported IPFIX > Messages > after which IPFIX Templates MUST be resent by the > Exporter. > > On Collectors this object contains the lifetime in number > of exported IPFIX Messages after which a Template becomes > invalid when it > is not received again within this lifetime. > > This object is only valid if ipfixTransportSessionProtocol > has the value 17 (UDP). In all other cases the value MUST > be 0." > > Do we agree? Yes, that's fine. Regards, Gerhard > > Regards, Benoit. > >> Benoit, >> >> I do not know if you got my point. >> >> I wanted to say that "number of packets" should be replaced by >> "number of IPFIX Messages" because packets could be interpreted as >> packets observed at the OP. >> >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >> >>> Gerhard, >>> >>>> Dear all, >>>> >>>> The IPFIX-MIB specifies: >>>> >>>> ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE >>>> SYNTAX Unsigned32 >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "On Exporters this object contains the number of packets >>>> after which IPFIX Templates MUST be resent by the >>>> Exporter. >>>> >>>> On Collectors this object contains the lifetime in number >>>> of packets after which a Template becomes invalid when it >>>> is not received again within this lifetime. >>>> >>>> This object is only valid if ipfixTransportSessionProtocol >>>> has the value 17 (UDP). In all other cases the value MUST >>>> be 0." >>>> DEFVAL { 0 } >>>> ::=3D { ipfixTransportSessionEntry 11 } >>>> >>>> >>>> (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) >>>> >>>> Isn't the description ambiguous? >>>> "On Exporters this object contains the number of packets after which >>>> IPFIX Templates MUST be resent by the Exporter." >>>> What is meant by "packets" in this context? >>>> - packets observed? >>>> - packets accounted? >>>> >>>> I assume it is the number of IPFIX Messages exported, right? >>>> >>>> >>> On the Exporter, correct. >>> On the collector side, this is "exported" as well (just for the case of >>> UDP loses some packets). So we must look at the "Sequence Number" >>> >>> Regards, Benoit. >>> >>>> Then, the description should be changed accordingly. >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> ----------------------------------------------------------------------= -- >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> >>>> >> >> > > -- = Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jun 12 12:44:27 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F613A69E4; Thu, 12 Jun 2008 12:44:27 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EC03A69E4 for ; Thu, 12 Jun 2008 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o473a5MsnGzu for ; Thu, 12 Jun 2008 12:44:23 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 3AF8B3A686D for ; Thu, 12 Jun 2008 12:44:23 -0700 (PDT) Received: from u-173-c251.cs.uni-tuebingen.de (u-173-c251.cs.uni-tuebingen.de [134.2.173.251]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m5CJilhv016635; Thu, 12 Jun 2008 21:44:47 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=www.ri.uni-tuebingen.de ident=www-data) by u-173-c251.cs.uni-tuebingen.de with esmtp (Exim 4.50) id 1K6skf-0005P1-Il; Thu, 12 Jun 2008 21:46:29 +0200 Received: from 195.4.205.55 (SquirrelMail authenticated user muenz) by www.ri.uni-tuebingen.de with HTTP; Thu, 12 Jun 2008 21:46:29 +0200 (CEST) Message-ID: <61117.195.4.205.55.1213299989.squirrel@www.ri.uni-tuebingen.de> In-Reply-To: <48513C4C.5030606@cisco.com> References: <48186300.8000104@informatik.uni-tuebingen.de> <485124D1.9050209@cisco.com> <4851288E.1050602@informatik.uni-tuebingen.de> <48513C4C.5030606@cisco.com> Date: Thu, 12 Jun 2008 21:46:29 +0200 (CEST) From: "Gerhard Muenz" To: "Benoit Claise" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.55; VDF: 7.0.4.186; host: mx05) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: TemplateRefreshPackets? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Thu, June 12, 2008 17:10, Benoit Claise said: > I think I got your point, but took a shortcut in the answer. My fault. > I see two issues in this email. > First, "number of packets" should be replaced by "number of IPFIX > Messages". Yes, definitively > Second, which IPFIX Messages: observed? accounted? exported? And this > answer is "exported", both in the Exporters and Collector sentences > > So it should become something such as > > "On Exporters this object contains the number of exported IPFIX > Messages > after which IPFIX Templates MUST be resent by the > Exporter. > > On Collectors this object contains the lifetime in number > of exported IPFIX Messages after which a Template becomes > invalid when it > is not received again within this lifetime. > > This object is only valid if ipfixTransportSessionProtocol > has the value 17 (UDP). In all other cases the value MUST > be 0." > > Do we agree? Yes, that's fine. Regards, Gerhard > > Regards, Benoit. > >> Benoit, >> >> I do not know if you got my point. >> >> I wanted to say that "number of packets" should be replaced by >> "number of IPFIX Messages" because packets could be interpreted as >> packets observed at the OP. >> >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >> >>> Gerhard, >>> >>>> Dear all, >>>> >>>> The IPFIX-MIB specifies: >>>> >>>> ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE >>>> SYNTAX Unsigned32 >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "On Exporters this object contains the number of packets >>>> after which IPFIX Templates MUST be resent by the >>>> Exporter. >>>> >>>> On Collectors this object contains the lifetime in number >>>> of packets after which a Template becomes invalid when it >>>> is not received again within this lifetime. >>>> >>>> This object is only valid if ipfixTransportSessionProtocol >>>> has the value 17 (UDP). In all other cases the value MUST >>>> be 0." >>>> DEFVAL { 0 } >>>> ::=3D { ipfixTransportSessionEntry 11 } >>>> >>>> >>>> (similarly for ipfixTransportSessionOptionTemplateRefreshPacket) >>>> >>>> Isn't the description ambiguous? >>>> "On Exporters this object contains the number of packets after which >>>> IPFIX Templates MUST be resent by the Exporter." >>>> What is meant by "packets" in this context? >>>> - packets observed? >>>> - packets accounted? >>>> >>>> I assume it is the number of IPFIX Messages exported, right? >>>> >>>> >>> On the Exporter, correct. >>> On the collector side, this is "exported" as well (just for the case of >>> UDP loses some packets). So we must look at the "Sequence Number" >>> >>> Regards, Benoit. >>> >>>> Then, the description should be changed accordingly. >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> ----------------------------------------------------------------------= -- >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> >>>> >> >> > > -- = Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Jun 17 06:15:48 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCF73A6A41; Tue, 17 Jun 2008 06:15:48 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA803A6A41 for ; Tue, 17 Jun 2008 06:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.166 X-Spam-Level: X-Spam-Status: No, score=-4.166 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OrPve19vEoB for ; Tue, 17 Jun 2008 06:15:41 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id B2E513A69F1 for ; Tue, 17 Jun 2008 06:15:39 -0700 (PDT) Received: from [127.0.0.1] (rouen.informatik.uni-tuebingen.de [134.2.11.152]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m5HDGIbI019647 for ; Tue, 17 Jun 2008 15:16:22 +0200 Message-ID: <4857B927.8090801@informatik.uni-tuebingen.de> Date: Tue, 17 Jun 2008 15:16:23 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: IETF IPFIX Working Group References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> In-Reply-To: <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> X-Enigmail-Version: 0.95.6 X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.55; VDF: 7.0.4.209; host: mx05) Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1369122409==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1369122409== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070709030404090800080000" This is a cryptographically signed message in MIME format. --------------ms070709030404090800080000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, Nevil Brownlee wrote: > draft-ietf-ipfix-exporting-type-01.txt was published back in February; > this version resolved all issues raised in earlier versions, and there'= s > been no discussion on the IPFIX list since. > > Its Working Group Last Call starts now (5 June 08), and will finish > on Friday 20 June 08. > > Please read it one more time - I need some reviews so that I can prepar= e > the Shepherd Document for it. And of course, please send any or all > your comments/feedback to the IPFIX list. Please find my review comments below. Regards, Gerhard > 1.1. IPFIX Documents Overview Maybe stress relevant relationships to this document: RFC 5102: specifies abstract data types and additional data type semantic= s RFC 5101: specifies the encoding of the data types > 3.1. informationElementDataType Maybe change to informationElementAbstractDataType to be more precise. > Description: A description of the storage type of an IPFIX > information element. These correspond to the abstract data types= You introduce a new term "storage type". What is it? Is it necessary to use this term instead of "abstract data type"? > defined in section 3.1 of the IPFIX Information Model [RFC5102]; > see that section for more information on the types described > below. This field may take the following values: > 3.6. informationElementSemantics Maybe call this informationElementDataTypeSemantic? >=20 > Description: A description of the semantics of an IPFIX informatio= n > element. These correspond to the data type semantics defined in Why do these semantics "correspond" to the data type semantics in RFC 5102? They "are" the data type semantics. =3D> A description of the data type semantics of an IPFIX information element. > section 3.2 of the IPFIX Information Model [RFC5102]; see that > section for more information on the types described below. This > field may take the following values; the special value 0x00 (none= ) > is used to note that no semantics apply to the field; it cannot b= e > manipulated by a Collecting Process or File Reader that does not > understand it a priori. > 3.8. privateEnterpriseNumber >=20 > Description: A private enterprise number used to scope an > informationElementID, as would appear in an IPFIX Template Record= =2E > This element can be used to scope properties to a specific > Information Element. If the Enterprise ID bit of the What is "Enterprise ID bit"? Do you mean "Enterprise bit" as in RFC 5101? > corresponding Information Element is cleared (has the value 0), > this IE should be set to 0. The presence of a non-zero value in > this IE implies that the Enterprise ID bit of the corresponding > Information Element is set (has the value 1). How does this map to the example in the appendix? 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 257 | Length =3D 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEN 6871 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE 14 |0x01 unsigned8 |0x05 flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here, the Enterprise bit is not set (14=3D0x000E), but the PEN is not zer= o. > 3.9. Information Element Type Options Template > Similarly, for security reasons, type information for a given > Information Element MUST NOT be re-defined by Information Element > type records, and a Collecting Process MUST NOT allow an Information= > Element type record to replace its own internal definition of an > Information Element. Information Element type records SHOULD NOT be= > duplicated within a Transport Session, but once an Information > Element type record has been exported for a given Information Elemen= t > within a given Transport Session, all subsequent type records for > that Information Element MUST be identical. Conflicting semantic or= > type information MUST be ignored by a Collecting Process. Maybe repeat the scope of these restrictions: Transport Session + OD. > +-------------------------------+-----------------------------------= + > | IE | Description = | > +-------------------------------+-----------------------------------= + > | informationElementID | The Information Element = | > | | identifier of the Information = | > | | Element within the specified = | > | | Template this record describes. = | Does the record describe the IE or the record? Rephrasing suggested. > | | This Information Element MUST be = | > | | defined as a Scope Field. See = | > | | the PSAMP Information Model = | > | | [I-D.ietf-psamp-info] for a = | > | | definition of this field. = | > | privateEnterpriseNumber | The Private Enterprise number of = | > | | the Information Element within = | > | | the specified Template this = | > | | record describes. This = | same as before > | | Information Element MUST be = | > | | defined as a Scope Field. = | > 3.10. Data Type and Semantics Restrictions >=20 > Note that the informationElementSemantics values are primarily > intended to differentiate semantic interpretation of numeric values,= > and that not all combinations of the informationElementDataType and > informationElementSemantics Information Elements are valid; e.g., a > counter cannot be encoded as an IPv4 address. Any > informationElementSemantics value is valid for unsigned > informationElementDataType values ("unsigned8", "unsigned16", > "unsigned32", or "unsigned64"). Any informationElementSemantics > value except flags is valid for signed informationElementDataType > values ("signed8", "signed16", "signed32", or "signed64"). Any > informationElementSemantics value except "identifier" or "flags" is > valid for floating-point informationElementDataType values ("float32= " > or "float64"). Only the informationElementSemantics value "none" is= > valid for all other other informationElementDataType values > ("octetArray", "boolean", "macAddress", "string", "dateTimeSeconds",= > "dateTimeMilliseconds", "dateTimeMicroseconds", > "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). Add reference to RFC 5102 section 3.2 where these limitations are already specified. > Appendix A. Examples See comment to section 3.8. --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070709030404090800080000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxNzEzMTYyM1owIwYJKoZIhvcNAQkEMRYEFDrzHDnb0zhF +LeWInha4CYunmeUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBylRovtgHHL4u3PuhZcEimGFfXOg/kilaKWrI6hE80oixxG93rz1tnMPu6 ymmezyKLh8U7Z45TYKAJtUFhyv5sI/B4+y3GX/yQwVeZ5uO0htgrEZ7CgzuSQvdLy0o7/KZy aTL9WclBuGLUNnY8FlvDE72UcMzV43qFPrJ6m5h/BEfuZmjkaWpoQ0jh5H0x//d2mlU3v+yq f4RgOpGW8AAzVaaErh2IWxDoKR2kq4PJM+zEj2wIcxcp1Dsiv3R3zHEg1VMeXhFrt9DkNoa+ oTeWy2iliHjXU1nhrey0jGoipLbr5yC/JWryoE3GUJucO1cV9VttoXT/LRnwZL/nByRtAAAA AAAA --------------ms070709030404090800080000-- --===============1369122409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1369122409==-- From ipfix-bounces@ietf.org Tue Jun 17 06:15:48 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCF73A6A41; Tue, 17 Jun 2008 06:15:48 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA803A6A41 for ; Tue, 17 Jun 2008 06:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.166 X-Spam-Level: X-Spam-Status: No, score=-4.166 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OrPve19vEoB for ; Tue, 17 Jun 2008 06:15:41 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id B2E513A69F1 for ; Tue, 17 Jun 2008 06:15:39 -0700 (PDT) Received: from [127.0.0.1] (rouen.informatik.uni-tuebingen.de [134.2.11.152]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m5HDGIbI019647 for ; Tue, 17 Jun 2008 15:16:22 +0200 Message-ID: <4857B927.8090801@informatik.uni-tuebingen.de> Date: Tue, 17 Jun 2008 15:16:23 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: IETF IPFIX Working Group References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> In-Reply-To: <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> X-Enigmail-Version: 0.95.6 X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.55; VDF: 7.0.4.209; host: mx05) Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1369122409==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1369122409== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070709030404090800080000" This is a cryptographically signed message in MIME format. --------------ms070709030404090800080000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, Nevil Brownlee wrote: > draft-ietf-ipfix-exporting-type-01.txt was published back in February; > this version resolved all issues raised in earlier versions, and there'= s > been no discussion on the IPFIX list since. > > Its Working Group Last Call starts now (5 June 08), and will finish > on Friday 20 June 08. > > Please read it one more time - I need some reviews so that I can prepar= e > the Shepherd Document for it. And of course, please send any or all > your comments/feedback to the IPFIX list. Please find my review comments below. Regards, Gerhard > 1.1. IPFIX Documents Overview Maybe stress relevant relationships to this document: RFC 5102: specifies abstract data types and additional data type semantic= s RFC 5101: specifies the encoding of the data types > 3.1. informationElementDataType Maybe change to informationElementAbstractDataType to be more precise. > Description: A description of the storage type of an IPFIX > information element. These correspond to the abstract data types= You introduce a new term "storage type". What is it? Is it necessary to use this term instead of "abstract data type"? > defined in section 3.1 of the IPFIX Information Model [RFC5102]; > see that section for more information on the types described > below. This field may take the following values: > 3.6. informationElementSemantics Maybe call this informationElementDataTypeSemantic? >=20 > Description: A description of the semantics of an IPFIX informatio= n > element. These correspond to the data type semantics defined in Why do these semantics "correspond" to the data type semantics in RFC 5102? They "are" the data type semantics. =3D> A description of the data type semantics of an IPFIX information element. > section 3.2 of the IPFIX Information Model [RFC5102]; see that > section for more information on the types described below. This > field may take the following values; the special value 0x00 (none= ) > is used to note that no semantics apply to the field; it cannot b= e > manipulated by a Collecting Process or File Reader that does not > understand it a priori. > 3.8. privateEnterpriseNumber >=20 > Description: A private enterprise number used to scope an > informationElementID, as would appear in an IPFIX Template Record= =2E > This element can be used to scope properties to a specific > Information Element. If the Enterprise ID bit of the What is "Enterprise ID bit"? Do you mean "Enterprise bit" as in RFC 5101? > corresponding Information Element is cleared (has the value 0), > this IE should be set to 0. The presence of a non-zero value in > this IE implies that the Enterprise ID bit of the corresponding > Information Element is set (has the value 1). How does this map to the example in the appendix? 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 257 | Length =3D 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEN 6871 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE 14 |0x01 unsigned8 |0x05 flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here, the Enterprise bit is not set (14=3D0x000E), but the PEN is not zer= o. > 3.9. Information Element Type Options Template > Similarly, for security reasons, type information for a given > Information Element MUST NOT be re-defined by Information Element > type records, and a Collecting Process MUST NOT allow an Information= > Element type record to replace its own internal definition of an > Information Element. Information Element type records SHOULD NOT be= > duplicated within a Transport Session, but once an Information > Element type record has been exported for a given Information Elemen= t > within a given Transport Session, all subsequent type records for > that Information Element MUST be identical. Conflicting semantic or= > type information MUST be ignored by a Collecting Process. Maybe repeat the scope of these restrictions: Transport Session + OD. > +-------------------------------+-----------------------------------= + > | IE | Description = | > +-------------------------------+-----------------------------------= + > | informationElementID | The Information Element = | > | | identifier of the Information = | > | | Element within the specified = | > | | Template this record describes. = | Does the record describe the IE or the record? Rephrasing suggested. > | | This Information Element MUST be = | > | | defined as a Scope Field. See = | > | | the PSAMP Information Model = | > | | [I-D.ietf-psamp-info] for a = | > | | definition of this field. = | > | privateEnterpriseNumber | The Private Enterprise number of = | > | | the Information Element within = | > | | the specified Template this = | > | | record describes. This = | same as before > | | Information Element MUST be = | > | | defined as a Scope Field. = | > 3.10. Data Type and Semantics Restrictions >=20 > Note that the informationElementSemantics values are primarily > intended to differentiate semantic interpretation of numeric values,= > and that not all combinations of the informationElementDataType and > informationElementSemantics Information Elements are valid; e.g., a > counter cannot be encoded as an IPv4 address. Any > informationElementSemantics value is valid for unsigned > informationElementDataType values ("unsigned8", "unsigned16", > "unsigned32", or "unsigned64"). Any informationElementSemantics > value except flags is valid for signed informationElementDataType > values ("signed8", "signed16", "signed32", or "signed64"). Any > informationElementSemantics value except "identifier" or "flags" is > valid for floating-point informationElementDataType values ("float32= " > or "float64"). Only the informationElementSemantics value "none" is= > valid for all other other informationElementDataType values > ("octetArray", "boolean", "macAddress", "string", "dateTimeSeconds",= > "dateTimeMilliseconds", "dateTimeMicroseconds", > "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). Add reference to RFC 5102 section 3.2 where these limitations are already specified. > Appendix A. Examples See comment to section 3.8. --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070709030404090800080000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxNzEzMTYyM1owIwYJKoZIhvcNAQkEMRYEFDrzHDnb0zhF +LeWInha4CYunmeUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBylRovtgHHL4u3PuhZcEimGFfXOg/kilaKWrI6hE80oixxG93rz1tnMPu6 ymmezyKLh8U7Z45TYKAJtUFhyv5sI/B4+y3GX/yQwVeZ5uO0htgrEZ7CgzuSQvdLy0o7/KZy aTL9WclBuGLUNnY8FlvDE72UcMzV43qFPrJ6m5h/BEfuZmjkaWpoQ0jh5H0x//d2mlU3v+yq f4RgOpGW8AAzVaaErh2IWxDoKR2kq4PJM+zEj2wIcxcp1Dsiv3R3zHEg1VMeXhFrt9DkNoa+ oTeWy2iliHjXU1nhrey0jGoipLbr5yC/JWryoE3GUJucO1cV9VttoXT/LRnwZL/nByRtAAAA AAAA --------------ms070709030404090800080000-- --===============1369122409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1369122409==-- From ipfix-bounces@ietf.org Wed Jun 18 01:18:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D370328C109; Wed, 18 Jun 2008 01:18:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DA43A6A5D for ; Wed, 18 Jun 2008 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-2.055, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSxsL2lg+QLC for ; Wed, 18 Jun 2008 01:18:00 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 2933B3A68A4 for ; Wed, 18 Jun 2008 01:17:58 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K8ssC-0006tB-Lr for ipfix@ietf.org; Wed, 18 Jun 2008 10:18:32 +0200 Message-ID: <4858C4DD.8040304@informatik.uni-tuebingen.de> Date: Wed, 18 Jun 2008 10:18:37 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: IETF IPFIX Working Group References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: <4857B927.8090801@informatik.uni-tuebingen.de> Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697623999==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0697623999== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000308090406030101070907" This is a cryptographically signed message in MIME format. --------------ms000308090406030101070907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, I forgot two more things in my review: In RFC 5102, abstract data types and data type semantics are explained in subsequent sections. Therefore, I would also move the definition of informationElementSemantics IE right after the definition of informationElementDataType IE: 3.1. informationElementDataType 3.6. =3D> 3.2 informationElementSemantics Secondly, the definition of the privateEnterpriseNumber IE allows zero values although type information must not be exported for non-enterprise IEs. Is this because the definition of privateEnterpriseNumber is to be generic and not restricted to the usage of type information export? If so, I would add a note that in the context of this draft, privateEnterpriseNumber must From ipfix-bounces@ietf.org Wed Jun 18 01:18:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D370328C109; Wed, 18 Jun 2008 01:18:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DA43A6A5D for ; Wed, 18 Jun 2008 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-2.055, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSxsL2lg+QLC for ; Wed, 18 Jun 2008 01:18:00 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 2933B3A68A4 for ; Wed, 18 Jun 2008 01:17:58 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K8ssC-0006tB-Lr for ipfix@ietf.org; Wed, 18 Jun 2008 10:18:32 +0200 Message-ID: <4858C4DD.8040304@informatik.uni-tuebingen.de> Date: Wed, 18 Jun 2008 10:18:37 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: IETF IPFIX Working Group References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: <4857B927.8090801@informatik.uni-tuebingen.de> Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697623999==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0697623999== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000308090406030101070907" This is a cryptographically signed message in MIME format. --------------ms000308090406030101070907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, I forgot two more things in my review: In RFC 5102, abstract data types and data type semantics are explained in subsequent sections. Therefore, I would also move the definition of informationElementSemantics IE right after the definition of informationElementDataType IE: 3.1. informationElementDataType 3.6. =3D> 3.2 informationElementSemantics Secondly, the definition of the privateEnterpriseNumber IE allows zero values although type information must not be exported for non-enterprise IEs. Is this because the definition of privateEnterpriseNumber is to be generic and not restricted to the usage of type information export? If so, I would add a note that in the context of this draft, privateEnterpriseNumber musnot be zero. Regards, Gerhard Gerhard Muenz wrote: > Dear all, >=20 > Nevil Brownlee wrote: >> draft-ietf-ipfix-exporting-type-01.txt was published back in February;= >> this version resolved all issues raised in earlier versions, and there= 's >> been no discussion on the IPFIX list since. >> >> Its Working Group Last Call starts now (5 June 08), and will finish >> on Friday 20 June 08. >> >> Please read it one more time - I need some reviews so that I can prepa= re >> the Shepherd Document for it. And of course, please send any or all >> your comments/feedback to the IPFIX list. >=20 > Please find my review comments below. >=20 > Regards, > Gerhard >=20 >=20 >> 1.1. IPFIX Documents Overview >=20 > Maybe stress relevant relationships to this document: > RFC 5102: specifies abstract data types and additional data type semant= ics > RFC 5101: specifies the encoding of the data types >=20 >> 3.1. informationElementDataType >=20 > Maybe change to informationElementAbstractDataType to be more precise. >=20 >> Description: A description of the storage type of an IPFIX >> information element. These correspond to the abstract data type= s >=20 > You introduce a new term "storage type". What is it? Is it necessary to= > use this term instead of "abstract data type"? >=20 >> defined in section 3.1 of the IPFIX Information Model [RFC5102];= >> see that section for more information on the types described >> below. This field may take the following values: >=20 >> 3.6. informationElementSemantics >=20 > Maybe call this informationElementDataTypeSemantic? >=20 >> Description: A description of the semantics of an IPFIX informati= on >> element. These correspond to the data type semantics defined in= >=20 > Why do these semantics "correspond" to the data type semantics in RFC > 5102? They "are" the data type semantics. > =3D> A description of the data type semantics of an IPFIX information > element. >=20 >> section 3.2 of the IPFIX Information Model [RFC5102]; see that >> section for more information on the types described below. This= >> field may take the following values; the special value 0x00 (non= e) >> is used to note that no semantics apply to the field; it cannot = be >> manipulated by a Collecting Process or File Reader that does not= >> understand it a priori. >=20 >> 3.8. privateEnterpriseNumber >> >> Description: A private enterprise number used to scope an >> informationElementID, as would appear in an IPFIX Template Recor= d. >> This element can be used to scope properties to a specific >> Information Element. If the Enterprise ID bit of the >=20 > What is "Enterprise ID bit"? > Do you mean "Enterprise bit" as in RFC 5101? >=20 >> corresponding Information Element is cleared (has the value 0), >> this IE should be set to 0. The presence of a non-zero value in= >> this IE implies that the Enterprise ID bit of the corresponding >> Information Element is set (has the value 1). >=20 > How does this map to the example in the appendix? >=20 > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID =3D 257 | Length =3D 50 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PEN 6871 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 14 |0x01 unsigned8 |0x05 flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Here, the Enterprise bit is not set (14=3D0x000E), but the PEN is not z= ero. >=20 >> 3.9. Information Element Type Options Template >=20 >> Similarly, for security reasons, type information for a given >> Information Element MUST NOT be re-defined by Information Element >> type records, and a Collectingt not be zero. Regards, Gerhard Gerhard Muenz wrote: > Dear all, >=20 > Nevil Brownlee wrote: >> draft-ietf-ipfix-exporting-type-01.txt was published back in February;= >> this version resolved all issues raised in earlier versions, and there= 's >> been no discussion on the IPFIX list since. >> >> Its Working Group Last Call starts now (5 June 08), and will finish >> on Friday 20 June 08. >> >> Please read it one more time - I need some reviews so that I can prepa= re >> the Shepherd Document for it. And of course, please send any or all >> your comments/feedback to the IPFIX list. >=20 > Please find my review comments below. >=20 > Regards, > Gerhard >=20 >=20 >> 1.1. IPFIX Documents Overview >=20 > Maybe stress relevant relationships to this document: > RFC 5102: specifies abstract data types and additional data type semant= ics > RFC 5101: specifies the encoding of the data types >=20 >> 3.1. informationElementDataType >=20 > Maybe change to informationElementAbstractDataType to be more precise. >=20 >> Description: A description of the storage type of an IPFIX >> information element. These correspond to the abstract data type= s >=20 > You introduce a new term "storage type". What is it? Is it necessary to= > use this term instead of "abstract data type"? >=20 >> defined in section 3.1 of the IPFIX Information Model [RFC5102];= >> see that section for more information on the types described >> below. This field may take the following values: >=20 >> 3.6. informationElementSemantics >=20 > Maybe call this informationElementDataTypeSemantic? >=20 >> Description: A description of the semantics of an IPFIX informati= on >> element. These correspond to the data type semantics defined in= >=20 > Why do these semantics "correspond" to the data type semantics in RFC > 5102? They "are" the data type semantics. > =3D> A description of the data type semantics of an IPFIX information > element. >=20 >> section 3.2 of the IPFIX Information Model [RFC5102]; see that >> section for more information on the types described below. This= >> field may take the following values; the special value 0x00 (non= e) >> is used to note that no semantics apply to the field; it cannot = be >> manipulated by a Collecting Process or File Reader that does not= >> understand it a priori. >=20 >> 3.8. privateEnterpriseNumber >> >> Description: A private enterprise number used to scope an >> informationElementID, as would appear in an IPFIX Template Recor= d. >> This element can be used to scope properties to a specific >> Information Element. If the Enterprise ID bit of the >=20 > What is "Enterprise ID bit"? > Do you mean "Enterprise bit" as in RFC 5101? >=20 >> corresponding Information Element is cleared (has the value 0), >> this IE should be set to 0. The presence of a non-zero value in= >> this IE implies that the Enterprise ID bit of the corresponding >> Information Element is set (has the value 1). >=20 > How does this map to the example in the appendix? >=20 > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID =3D 257 | Length =3D 50 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PEN 6871 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 14 |0x01 unsigned8 |0x05 flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Here, the Enterprise bit is not set (14=3D0x000E), but the PEN is not z= ero. >=20 >> 3.9. Information Element Type Options Template >=20 >> Similarly, for security reasons, type information for a given >> Information Element MUST NOT be re-defined by Information Element >> type records, and a Collecti Process MUST NOT allow an Informatio= n >> Element type record to replace its own internal definition of an >> Information Element. Information Element type records SHOULD NOT b= e >> duplicated within a Transport Session, but once an Information >> Element type record has been exported for a given Information Eleme= nt >> within a given Transport Session, all subsequent type records for >> that Information Element MUST be identical. Conflicting semantic o= r >> type information MUST be ignored by a Collecting Process. >=20 > Maybe repeat the scope of these restrictions: Transport Session + OD. >=20 >> +-------------------------------+----------------------------------= -+ >> | IE | Description = | >> +-------------------------------+----------------------------------= -+ >> | informationElementID | The Information Element = | >> | | identifier of the Information = | >> | | Element within the specified = | >> | | Template this record describes. = | >=20 > Does the record describe the IE or the record? Rephrasing suggested. >=20 >> | | This Information Element MUST be = | >> | | defined as a Scope Field. See = | >> | | the PSAMP Information Model = | >> | | [I-D.ietf-psamp-info] for a = | >> | | definition of this field. = | >> | privateEnterpriseNumber | The Private Enterprise number of = | >> | | the Information Element within = | >> | | the specified Template this = | >> | | record describes. This = | >=20 > same as before >=20 >> | | Information Element MUST be = | >> | | defined as a Scope Field. = | >=20 >> 3.10. Data Type and Semantics Restrictions >> >> Note that the informationElementSemantics values are primarily >> intended to differentiate semantic interpretation of numeric values= , >> and that not all combinations of the informationElementDataType and= >> informationElementSemantics Information Elements are valid; e.g., a= >> counter cannot be encoded as an IPv4 address. Any >> informationElementSemantics value is valid for unsigned >> informationElementDataType values ("unsigned8", "unsigned16", >> "unsigned32", or "unsigned64"). Any informationElementSemantics >> value except flags is valid for signed informationElementDataType >> values ("signed8", "signed16", "signed32", or "signed64"). Any >> informationElementSemantics value except "identifier" or "flags" is= >> valid for floating-point informationElementDataType values ("float3= 2" >> or "float64"). Only the informationElementSemantics value "none" i= s >> valid for all other other informationElementDataType values >> ("octetArray", "boolean", "macAddress", "string", "dateTimeSeconds"= , >> "dateTimeMilliseconds", "dateTimeMicroseconds", >> "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). >=20 > Add reference to RFC 5102 section 3.2 where these limitations are > already specified. >=20 >> Appendix A. Examples >=20 > See comment to section 3.8. >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uning Process MUST NOT allow an Informatio= n >> Element type record to replace its own internal definition of an >> Information Element. Information Element type records SHOULD NOT b= e >> duplicated within a Transport Session, but once an Information >> Element type record has been exported for a given Information Eleme= nt >> within a given Transport Session, all subsequent type records for >> that Information Element MUST be identical. Conflicting semantic o= r >> type information MUST be ignored by a Collecting Process. >=20 > Maybe repeat the scope of these restrictions: Transport Session + OD. >=20 >> +-------------------------------+----------------------------------= -+ >> | IE | Description = | >> +-------------------------------+----------------------------------= -+ >> | informationElementID | The Information Element = | >> | | identifier of the Information = | >> | | Element within the specified = | >> | | Template this record describes. = | >=20 > Does the record describe the IE or the record? Rephrasing suggested. >=20 >> | | This Information Element MUST be = | >> | | defined as a Scope Field. See = | >> | | the PSAMP Information Model = | >> | | [I-D.ietf-psamp-info] for a = | >> | | definition of this field. = | >> | privateEnterpriseNumber | The Private Enterprise number of = | >> | | the Information Element within = | >> | | the specified Template this = | >> | | record describes. This = | >=20 > same as before >=20 >> | | Information Element MUST be = | >> | | defined as a Scope Field. = | >=20 >> 3.10. Data Type and Semantics Restrictions >> >> Note that the informationElementSemantics values are primarily >> intended to differentiate semantic interpretation of numeric values= , >> and that not all combinations of the informationElementDataType and= >> informationElementSemantics Information Elements are valid; e.g., a= >> counter cannot be encoded as an IPv4 address. Any >> informationElementSemantics value is valid for unsigned >> informationElementDataType values ("unsigned8", "unsigned16", >> "unsigned32", or "unsigned64"). Any informationElementSemantics >> value except flags is valid for signed informationElementDataType >> values ("signed8", "signed16", "signed32", or "signed64"). Any >> informationElementSemantics value except "identifier" or "flags" is= >> valid for floating-point informationElementDataType values ("float3= 2" >> or "float64"). Only the informationElementSemantics value "none" i= s >> valid for all other other informationElementDataType values >> ("octetArray", "boolean", "macAddress", "string", "dateTimeSeconds"= , >> "dateTimeMilliseconds", "dateTimeMicroseconds", >> "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). >=20 > Add reference to RFC 5102 section 3.2 where these limitations are > already specified. >=20 >> Appendix A. Examples >=20 > See comment to section 3.8. >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms000308090406030101070907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxODA4MTgzN1owIwYJKoZIhvcNAQkEMRYEFJs9alsE0XVZ 5Jqvke/DHRSP6R2WMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAY4Hy/Ugx/qXrZBwA/3aZFMOkeK+BBVEtYsrEYaqvTx8ziGvTcjoBAB0X9 ujzikCtcES2yJyKt+7J1j9GqPsSosu4UX6Q+VLFiDRaaNkZyTI8EK4xSusfoM0f8J/tQl49i +AuydmdriwvKnrz9elLpApni8ITMH/GjCXkoyMgZqumGuu8OuboB8Bq79Xh5QlgxblTHwkxv Su8H+c/4ei5lHgk4wz+PkP9WJ2pioDLaP8USzb9mdxX44dSXzBL9SgDE+haaFccQIuJwXgZJ MiEjTUNOPDev2ON7ErjFAbmF+WrdmbHzk0RP+QeEo1AcwIXcOPpYhUx3ebWqHMeMgkX2AAAA AAAA --------------ms000308090406030101070907-- --===============0697623999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0697623999==-- -tuebingen.de/~muenz --------------ms000308090406030101070907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxODA4MTgzN1owIwYJKoZIhvcNAQkEMRYEFJs9alsE0XVZ 5Jqvke/DHRSP6R2WMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAY4Hy/Ugx/qXrZBwA/3aZFMOkeK+BBVEtYsrEYaqvTx8ziGvTcjoBAB0X9 ujzikCtcES2yJyKt+7J1j9GqPsSosu4UX6Q+VLFiDRaaNkZyTI8EK4xSusfoM0f8J/tQl49i +AuydmdriwvKnrz9elLpApni8ITMH/GjCXkoyMgZqumGuu8OuboB8Bq79Xh5QlgxblTHwkxv Su8H+c/4ei5lHgk4wz+PkP9WJ2pioDLaP8USzb9mdxX44dSXzBL9SgDE+haaFccQIuJwXgZJ MiEjTUNOPDev2ON7ErjFAbmF+WrdmbHzk0RP+QeEo1AcwIXcOPpYhUx3ebWqHMeMgkX2AAAA AAAA --------------ms000308090406030101070907-- --===============0697623999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0697623999==-- From ipfix-bounces@ietf.org Thu Jun 19 05:34:58 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7172E3A6902; Thu, 19 Jun 2008 05:34:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CB33A6902 for ; Thu, 19 Jun 2008 05:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAMQNZ+YcIS7 for ; Thu, 19 Jun 2008 05:34:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 41F283A683B for ; Thu, 19 Jun 2008 05:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C6AD1D9303; Thu, 19 Jun 2008 14:35:41 +0200 (MEST) 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 ZDrGqTVxbOih; Thu, 19 Jun 2008 14:35:41 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 790F4D9384; Thu, 19 Jun 2008 14:35:41 +0200 (MEST) In-Reply-To: <4857B927.8090801@informatik.uni-tuebingen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Thu, 19 Jun 2008 14:35:39 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Thank you for the review! Comments inline; additional comments follow in a subsequent message. Regards, Brian On Jun 17, 2008, at 3:16 PM, Gerhard Muenz wrote: > > Dear all, > > Nevil Brownlee wrote: >> draft-ietf-ipfix-exporting-type-01.txt was published back in >> February; >> this version resolved all issues raised in earlier versions, and >> there's >> been no discussion on the IPFIX list since. >> >> Its Working Group Last Call starts now (5 June 08), and will finish >> on Friday 20 June 08. >> >> Please read it one more time - I need some reviews so that I can >> prepare >> the Shepherd Document for it. And of course, please send any or all >> your comments/feedback to the IPFIX liFrom ipfix-bounces@ietf.org Thu Jun 19 05:34:58 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7172E3A6902; Thu, 19 Jun 2008 05:34:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CB33A6902 for ; Thu, 19 Jun 2008 05:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAMQNZ+YcIS7 for ; Thu, 19 Jun 2008 05:34:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 41F283A683B for ; Thu, 19 Jun 2008 05:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C6AD1D9303; Thu, 19 Jun 2008 14:35:41 +0200 (MEST) 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 ZDrGqTVxbOih; Thu, 19 Jun 2008 14:35:41 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 790F4D9384; Thu, 19 Jun 2008 14:35:41 +0200 (MEST) In-Reply-To: <4857B927.8090801@informatik.uni-tuebingen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Thu, 19 Jun 2008 14:35:39 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Thank you for the review! Comments inline; additional comments follow in a subsequent message. Regards, Brian On Jun 17, 2008, at 3:16 PM, Gerhard Muenz wrote: > > Dear all, > > Nevil Brownlee wrote: >> draft-ietf-ipfix-exporting-type-01.txt was published back in >> February; >> this version resolved all issues raised in earlier versions, and >> there's >> been no discussion on the IPFIX list since. >> >> Its Working Group Last Call starts now (5 June 08), and will finish >> on Friday 20 June 08. >> >> Please read it one more time - I need some reviews so that I can >> prepare >> the Shepherd Document for it. And of course, please send any or all >> your comments/feedback to the IPFIX st. > > Please find my review comments below. > > Regards, > Gerhard > > >> 1.1. IPFIX Documents Overview > > Maybe stress relevant relationships to this document: > RFC 5102: specifies abstract data types and additional data type > semantics > RFC 5101: specifies the encoding of the data types Agree. I've made this change in a working -02. >> 3.1. informationElementDataType > > Maybe change to informationElementAbstractDataType to be more precise. > >> Description: A description of the storage type of an IPFIX >> information element. These correspond to the abstract data >> types > > You introduce a new term "storage type". What is it? Is it > necessary to > use this term instead of "abstract data type"? Nope. Sorry. I wrote this paragraph, and "storage type" is a bit of terminology from an somewhat related system I used to work on, which must have crept over to IPFIX in my brain. Fixed. >> defined in section 3.1 of the IPFIX Information Model >> [RFC5102]; >> see that section for more information on the types described >> below. This field may take the following values: > >> 3.6. informationElementSemantics > > Maybe call this informationElementDataTypeSemantic? This was considered, as I recall, and we shortened explicitly because as an information element name, informationElementDataTypeSemantics is simply too long, and shares a large initial substring with informationElementDataType, with which it should not be confused. >> >> Description: A description of the semantics of an IPFIX >> information >> element. These correspond to the data type semantics >> defined in > > Why do these semantics "correspond" to the data type semantics in RFC > 5102? They "are" the data type semantics. > => A description of the data type semantics of an IPFIX information > element. Hm. Right. This makes sense. I've made a parallel change for informationElementDataType. > >> section 3.2 of the IPFIX Information Model [RFC5102]; see that >> section for more information on the types described below. >> This >> field may take the following values; the special value 0x00 >> (none) >> is used to note that no semantics apply to the field; it >> cannot be >> manipulated by a Collecting Process or File Reader that does >> not >> understand it a priori. > >> 3.8. privateEnterpriseNumber >> >> Description: A private enterprise number used to scope an >> informationElementID, as would appear in an IPFIX Template >> Record. >> This element can be used to scope properties to a specific >> Information Element. If the Enterprise ID bit of the > > What is "Enterprise ID bit"? > Do you mean "Enterprise bit" as in RFC 5101? Yes. Fixed. >> corresponding Information Element is cleared (has the value 0), >> this IE should be set to 0. The presence of a non-zero >> value in >> this IE implies that the Enterprise ID bit of the corresponding >> Information Element is set (has the value 1). > > How does this map to the example in the appendix? > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 257 | Length = 50 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PEN 6871 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 14 |0x01 unsigned8 |0x05 flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Here, the Enterprise bit is not set (14=0x000E), but the PEN is not > zero. Hm. The intention here is that the informationElementId be the _base_ information element ID, without the enterprise bit; in other words, ((the IE number from the template) & ~0x8000). However, reading section 8.2.3. of the PSAMP Info doculist. > > Please find my review comments below. > > Regards, > Gerhard > > >> 1.1. IPFIX Documents Overview > > Maybe stress relevant relationships to this document: > RFC 5102: specifies abstract data types and additional data type > semantics > RFC 5101: specifies the encoding of the data types Agree. I've made this change in a working -02. >> 3.1. informationElementDataType > > Maybe change to informationElementAbstractDataType to be more precise. > >> Description: A description of the storage type of an IPFIX >> information element. These correspond to the abstract data >> types > > You introduce a new term "storage type". What is it? Is it > necessary to > use this term instead of "abstract data type"? Nope. Sorry. I wrote this paragraph, and "storage type" is a bit of terminology from an somewhat related system I used to work on, which must have crept over to IPFIX in my brain. Fixed. >> defined in section 3.1 of the IPFIX Information Model >> [RFC5102]; >> see that section for more information on the types described >> below. This field may take the following values: > >> 3.6. informationElementSemantics > > Maybe call this informationElementDataTypeSemantic? This was considered, as I recall, and we shortened explicitly because as an information element name, informationElementDataTypeSemantics is simply too long, and shares a large initial substring with informationElementDataType, with which it should not be confused. >> >> Description: A description of the semantics of an IPFIX >> information >> element. These correspond to the data type semantics >> defined in > > Why do these semantics "correspond" to the data type semantics in RFC > 5102? They "are" the data type semantics. > => A description of the data type semantics of an IPFIX information > element. Hm. Right. This makes sense. I've made a parallel change for informationElementDataType. > >> section 3.2 of the IPFIX Information Model [RFC5102]; see that >> section for more information on the types described below. >> This >> field may take the following values; the special value 0x00 >> (none) >> is used to note that no semantics apply to the field; it >> cannot be >> manipulated by a Collecting Process or File Reader that does >> not >> understand it a priori. > >> 3.8. privateEnterpriseNumber >> >> Description: A private enterprise number used to scope an >> informationElementID, as would appear in an IPFIX Template >> Record. >> This element can be used to scope properties to a specific >> Information Element. If the Enterprise ID bit of the > > What is "Enterprise ID bit"? > Do you mean "Enterprise bit" as in RFC 5101? Yes. Fixed. >> corresponding Information Element is cleared (has the value 0), >> this IE should be set to 0. The presence of a non-zero >> value in >> this IE implies that the Enterprise ID bit of the corresponding >> Information Element is set (has the value 1). > > How does this map to the example in the appendix? > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 257 | Length = 50 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PEN 6871 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 14 |0x01 unsigned8 |0x05 flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Here, the Enterprise bit is not set (14=0x000E), but the PEN is not > zero. Hm. The intention here is that the informationElementId be the _base_ information element ID, without the enterprise bit; in other words, ((the IE number from the template) & ~0x8000). However, reading section 8.2.3. of the PSAMP Info doment (which is now in Publication Requested state), such is not stated, because the definition was written, I think, without considering enteprise- specific IEs. So, the privateEnterpriseNumber IE could be defined so as to fix this. If the PEN IE is present, then the high bit in informationElementID is ignored. This would seem to be be the most "be liberal in what you accept" way to address this... >> 3.9. Information Element Type Options Template > >> Similarly, for security reasons, type information for a given >> Information Element MUST NOT be re-defined by Information Element >> type records, and a Collecting Process MUST NOT allow an >> Information >> Element type record to replace its own internal definition of an >> Information Element. Information Element type records SHOULD >> NOT be >> duplicated within a Transport Session, but once an Information >> Element type record has been exported for a given Information >> Element >> within a given Transport Session, all subsequent type records for >> that Information Element MUST be identical. Conflicting >> semantic or >> type information MUST be ignored by a Collecting Process. > > Maybe repeat the scope of these restrictions: Transport Session + OD. Hm. Isn't this implied by 5101? >> +------------------------------- >> +-----------------------------------+ >> | IE | >> Description | >> +------------------------------- >> +-----------------------------------+ >> | informationElementID | The Information >> Element | >> | | identifier of the >> Information | >> | | Element within the >> specified | >> | | Template this record >> describes. | > > Does the record describe the IE or the record? Rephrasing suggested. hmm. the mention of a template here is spurious, too. Will rephrase. >> | | This Information Element MUST >> be | >> | | defined as a Scope Field. >> See | >> | | the PSAMP Information >> Model | >> | | [I-D.ietf-psamp-info] for >> a | >> | | definition of this >> field. | >> | privateEnterpriseNumber | The Private Enterprise number >> of | >> | | the Information Element >> within | >> | | the specified Template >> this | >> | | record describes. >> This | > > same as before likewise. >> | | Information Element MUST >> be | >> | | defined as a Scope >> Field. | > >> 3.10. Data Type and Semantics Restrictions >> >> Note that the informationElementSemantics values are primarily >> intended to differentiate semantic interpretation of numeric >> values, >> and that not all combinations of the informationElementDataType >> and >> informationElementSemantics Information Elements are valid; >> e.g., a >> counter cannot be encoded as an IPv4 address. Any >> informationElementSemantics value is valid for unsigned >> informationElementDataType values ("unsigned8", "unsigned16", >> "unsigned32", or "unsigned64"). Any informationElementSemantics >> value except flags is valid for signed informationElementDataType >> values ("signed8", "signed16", "signed32", or "signed64"). Any >> informationElementSemantics value except "identifier" or >> "flags" is >> valid for floating-point informationElementDataType values >> ("float32" >> or "float64"). Only the informationElementSemantics value >> "none" is >> valid for all other other informationElementDataType values >> ("octetArray", "boolean", "macAddress", "string", >> "dateTimeSeconds", >> cument (which is now in Publication Requested state), such is not stated, because the definition was written, I think, without considering enteprise- specific IEs. So, the privateEnterpriseNumber IE could be defined so as to fix this. If the PEN IE is present, then the high bit in informationElementID is ignored. This would seem to be be the most "be liberal in what you accept" way to address this... >> 3.9. Information Element Type Options Template > >> Similarly, for security reasons, type information for a given >> Information Element MUST NOT be re-defined by Information Element >> type records, and a Collecting Process MUST NOT allow an >> Information >> Element type record to replace its own internal definition of an >> Information Element. Information Element type records SHOULD >> NOT be >> duplicated within a Transport Session, but once an Information >> Element type record has been exported for a given Information >> Element >> within a given Transport Session, all subsequent type records for >> that Information Element MUST be identical. Conflicting >> semantic or >> type information MUST be ignored by a Collecting Process. > > Maybe repeat the scope of these restrictions: Transport Session + OD. Hm. Isn't this implied by 5101? >> +------------------------------- >> +-----------------------------------+ >> | IE | >> Description | >> +------------------------------- >> +-----------------------------------+ >> | informationElementID | The Information >> Element | >> | | identifier of the >> Information | >> | | Element within the >> specified | >> | | Template this record >> describes. | > > Does the record describe the IE or the record? Rephrasing suggested. hmm. the mention of a template here is spurious, too. Will rephrase. >> | | This Information Element MUST >> be | >> | | defined as a Scope Field. >> See | >> | | the PSAMP Information >> Model | >> | | [I-D.ietf-psamp-info] for >> a | >> | | definition of this >> field. | >> | privateEnterpriseNumber | The Private Enterprise number >> of | >> | | the Information Element >> within | >> | | the specified Template >> this | >> | | record describes. >> This | > > same as before likewise. >> | | Information Element MUST >> be | >> | | defined as a Scope >> Field. | > >> 3.10. Data Type and Semantics Restrictions >> >> Note that the informationElementSemantics values are primarily >> intended to differentiate semantic interpretation of numeric >> values, >> and that not all combinations of the informationElementDataType >> and >> informationElementSemantics Information Elements are valid; >> e.g., a >> counter cannot be encoded as an IPv4 address. Any >> informationElementSemantics value is valid for unsigned >> informationElementDataType values ("unsigned8", "unsigned16", >> "unsigned32", or "unsigned64"). Any informationElementSemantics >> value except flags is valid for signed informationElementDataType >> values ("signed8", "signed16", "signed32", or "signed64"). Any >> informationElementSemantics value except "identifier" or >> "flags" is >> valid for floating-point informationElementDataType values >> ("float32" >> or "float64"). Only the informationElementSemantics value >> "none" is >> valid for all other other informationElementDataType values >> ("octetArray", "boolean", "macAddress", "string", >> "dateTimeSeconds", >> "dateTimeMilliseconds", "dateTimeMicroseconds", >> "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). > > Add reference to RFC 5102 section 3.2 where these limitations are > already specified. Hm. These limitations are implied, I think, by the language in 3.2, but not at all explicitly specified... but yes, we could add a reminder ref to the first sentence for readability. Thanks again, and regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix "dateTimeMilliseconds", "dateTimeMicroseconds", >> "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). > > Add reference to RFC 5102 section 3.2 where these limitations are > already specified. Hm. These limitations are implied, I think, by the language in 3.2, but not at all explicitly specified... but yes, we could add a reminder ref to the first sentence for readability. Thanks again, and regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jun 19 05:35:40 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A413A69C9; Thu, 19 Jun 2008 05:35:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89E43A69C9 for ; Thu, 19 Jun 2008 05:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvclytzCVGa4 for ; Thu, 19 Jun 2008 05:35:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 233A43A67CF for ; Thu, 19 Jun 2008 05:35:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4A6B7D9384 for ; Thu, 19 Jun 2008 14:36:26 +0200 (MEST) 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 lLs2Z1CW6p73 for ; Thu, 19 Jun 2008 14:36:25 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id D9041D9303 for ; Thu, 19 Jun 2008 14:36:25 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v753.1) To: IETF IPFIX Working Group Message-Id: <489DEFD7-D084-44C3-B3F9-D4B7C16F7A2D@tik.ee.ethz.ch> References: From: Brian Trammell Date: Thu, 19 Jun 2008 14:36:24 +0200 X-Mailer: Apple Mail (2.753.1) Subject: [IPFIX] Fwd: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0324608917==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0324608917== Content-Type: multipart/alternative; boundary=Apple-Mail-1--651416985 --Apple-Mail-1--651416985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Begin forwarded message: > From: Brian Trammell > Date: June 19, 2008 2:35:55 PM GMT+02:00 > To: Gerhard Muenz > Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft > > > On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote: > >> >> Dear all, >> >> I forgot two more things in my review: >> >> In RFC 5102, abstract data types and data type semantics are =20 >> explained >> in subsequent sections. Therefore, I would also move the =20 >> definition of >> informationElementSemantics IE right after the definition of >> informationElementDataType IE: >> 3.1. informationElementDataType >> 3.6. =3D> 3.2 informationElementSemantics > > The sections are arranged in alphabetical order so as to allow the =20 > IEs to be found by name quickly; the proposed rearrangement would =20 > break tFrom ipfix-bounces@ietf.org Thu Jun 19 05:35:40 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A413A69C9; Thu, 19 Jun 2008 05:35:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89E43A69C9 for ; Thu, 19 Jun 2008 05:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvclytzCVGa4 for ; Thu, 19 Jun 2008 05:35:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 233A43A67CF for ; Thu, 19 Jun 2008 05:35:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4A6B7D9384 for ; Thu, 19 Jun 2008 14:36:26 +0200 (MEST) 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 lLs2Z1CW6p73 for ; Thu, 19 Jun 2008 14:36:25 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id D9041D9303 for ; Thu, 19 Jun 2008 14:36:25 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v753.1) To: IETF IPFIX Working Group Message-Id: <489DEFD7-D084-44C3-B3F9-D4B7C16F7A2D@tik.ee.ethz.ch> References: From: Brian Trammell Date: Thu, 19 Jun 2008 14:36:24 +0200 X-Mailer: Apple Mail (2.753.1) Subject: [IPFIX] Fwd: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0324608917==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0324608917== Content-Type: multipart/alternative; boundary=Apple-Mail-1--651416985 --Apple-Mail-1--651416985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Begin forwarded message: > From: Brian Trammell > Date: June 19, 2008 2:35:55 PM GMT+02:00 > To: Gerhard Muenz > Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft > > > On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote: > >> >> Dear all, >> >> I forgot two more things in my review: >> >> In RFC 5102, abstract data types and data type semantics are =20 >> explained >> in subsequent sections. Therefore, I would also move the =20 >> definition of >> informationElementSemantics IE right after the definition of >> informationElementDataType IE: >> 3.1. informationElementDataType >> 3.6. =3D> 3.2 informationElementSemantics > > The sections are arranged in alphabetical order so as to allow the =20 > IEs to be found by name quickly; the proposed rearrangement would =20 > breakhat. > >> Secondly, the definition of the privateEnterpriseNumber IE allows =20 >> zero >> values although type information must not be exported for non-=20 >> enterprise >> IEs. >> Is this because the definition of privateEnterpriseNumber is to be >> generic and not restricted to the usage of type information export? >> If so, I would add a note that in the context of this draft, >> privateEnterpriseNumber must not be zero. > > This is not a constraint imposed by this document. Within the =20 > context of type information export, the PEN may be zero. > > The only constraint here is in Paragraph 4 of section 2.9 =20 > (Information Element Type OT MUST NOT redefine an IE; CP MUST =20 > ignore redefinitions). This allows the potential to use this =20 > mechanism to improve interoperability between IPFIX implementations =20= > including different versions of the IANA registry. > > Regards, > > Brian > >> >> >> Gerhard Muenz wrote: >>> Dear all, >>> >>> Nevil Brownlee wrote: >>>> draft-ietf-ipfix-exporting-type-01.txt was published back in =20 >>>> February; >>>> this version resolved all issues raised in earlier versions, and =20= >>>> there's >>>> been no discussion on the IPFIX list since. >>>> >>>> Its Working Group Last Call starts now (5 June 08), and will finish >>>> on Friday 20 June 08. >>>> >>>> Please read it one more time - I need some reviews so that I can =20= >>>> prepare >>>> the Shepherd Document for it. And of course, please send any or =20= >>>> all >>>> your comments/feedback to the IPFIX list. >>> >>> Please find my review comments below. >>> >>> Regards, >>> Gerhard >>> >>> >>>> 1.1. IPFIX Documents Overview >>> >>> Maybe stress relevant relationships to this document: >>> RFC 5102: specifies abstract data types and additional data type =20 >>> semantics >>> RFC 5101: specifies the encoding of the data types >>> >>>> 3.1. informationElementDataType >>> >>> Maybe change to informationElementAbstractDataType to be more =20 >>> precise. >>> >>>> Description: A description of the storage type of an IPFIX >>>> information element. These correspond to the abstract =20 >>>> data types >>> >>> You introduce a new term "storage type". What is it? Is it =20 >>> necessary to >>> use this term instead of "abstract data type"? >>> >>>> defined in section 3.1 of the IPFIX Information Model =20 >>>> [RFC5102]; >>>> see that section for more information on the types described >>>> below. This field may take the following values: >>> >>>> 3.6. informationElementSemantics >>> >>> Maybe call this informationElementDataTypeSemantic? >>> >>>> Description: A description of the semantics of an IPFIX =20 >>>> information >>>> element. These correspond to the data type semantics =20 >>>> defined in >>> >>> Why do these semantics "correspond" to the data type semantics in =20= >>> RFC >>> 5102? They "are" the data type semantics. >>> =3D> A description of the data type semantics of an IPFIX = information >>> element. >>> >>>> section 3.2 of the IPFIX Information Model [RFC5102]; see =20 >>>> that >>>> section for more information on the types described =20 >>>> below. This >>>> field may take the following values; the special value =20 >>>> 0x00 (none) >>>> is used to note that no semantics apply to the field; it =20 >>>> cannot be >>>> manipulated by a Collecting Process or File Reader that =20 >>>> does not >>>> understand it a priori. >>> >>>> 3.8. privateEnterpriseNumber >>>> >>>> Description: A private enterprise number used to scope an >>>> informationElementID, as would appear in an IPFIX Template =20= >>>> Record. >>>> This element can be used to scope properties to a specific >>>> Information Element. If the Enterprise ID bit of the >>> >>> What is "Enterprise ID bit"? >>> Do you mean "Enterprise bit" as in RFC 5101? >>> >>>> corresponding Information Element is cleared (has the =20 >>>> value 0), >>>> this IE should be set to 0. The presence of a non-zero =20 >>>> value in >>>> this IE im that. > >> Secondly, the definition of the privateEnterpriseNumber IE allows =20 >> zero >> values although type information must not be exported for non-=20 >> enterprise >> IEs. >> Is this because the definition of privateEnterpriseNumber is to be >> generic and not restricted to the usage of type information export? >> If so, I would add a note that in the context of this draft, >> privateEnterpriseNumber must not be zero. > > This is not a constraint imposed by this document. Within the =20 > context of type information export, the PEN may be zero. > > The only constraint here is in Paragraph 4 of section 2.9 =20 > (Information Element Type OT MUST NOT redefine an IE; CP MUST =20 > ignore redefinitions). This allows the potential to use this =20 > mechanism to improve interoperability between IPFIX implementations =20= > including different versions of the IANA registry. > > Regards, > > Brian > >> >> >> Gerhard Muenz wrote: >>> Dear all, >>> >>> Nevil Brownlee wrote: >>>> draft-ietf-ipfix-exporting-type-01.txt was published back in =20 >>>> February; >>>> this version resolved all issues raised in earlier versions, and =20= >>>> there's >>>> been no discussion on the IPFIX list since. >>>> >>>> Its Working Group Last Call starts now (5 June 08), and will finish >>>> on Friday 20 June 08. >>>> >>>> Please read it one more time - I need some reviews so that I can =20= >>>> prepare >>>> the Shepherd Document for it. And of course, please send any or =20= >>>> all >>>> your comments/feedback to the IPFIX list. >>> >>> Please find my review comments below. >>> >>> Regards, >>> Gerhard >>> >>> >>>> 1.1. IPFIX Documents Overview >>> >>> Maybe stress relevant relationships to this document: >>> RFC 5102: specifies abstract data types and additional data type =20 >>> semantics >>> RFC 5101: specifies the encoding of the data types >>> >>>> 3.1. informationElementDataType >>> >>> Maybe change to informationElementAbstractDataType to be more =20 >>> precise. >>> >>>> Description: A description of the storage type of an IPFIX >>>> information element. These correspond to the abstract =20 >>>> data types >>> >>> You introduce a new term "storage type". What is it? Is it =20 >>> necessary to >>> use this term instead of "abstract data type"? >>> >>>> defined in section 3.1 of the IPFIX Information Model =20 >>>> [RFC5102]; >>>> see that section for more information on the types described >>>> below. This field may take the following values: >>> >>>> 3.6. informationElementSemantics >>> >>> Maybe call this informationElementDataTypeSemantic? >>> >>>> Description: A description of the semantics of an IPFIX =20 >>>> information >>>> element. These correspond to the data type semantics =20 >>>> defined in >>> >>> Why do these semantics "correspond" to the data type semantics in =20= >>> RFC >>> 5102? They "are" the data type semantics. >>> =3D> A description of the data type semantics of an IPFIX = information >>> element. >>> >>>> section 3.2 of the IPFIX Information Model [RFC5102]; see =20 >>>> that >>>> section for more information on the types described =20 >>>> below. This >>>> field may take the following values; the special value =20 >>>> 0x00 (none) >>>> is used to note that no semantics apply to the field; it =20 >>>> cannot be >>>> manipulated by a Collecting Process or File Reader that =20 >>>> does not >>>> understand it a priori. >>> >>>> 3.8. privateEnterpriseNumber >>>> >>>> Description: A private enterprise number used to scope an >>>> informationElementID, as would appear in an IPFIX Template =20= >>>> Record. >>>> This element can be used to scope properties to a specific >>>> Information Element. If the Enterprise ID bit of the >>> >>> What is "Enterprise ID bit"? >>> Do you mean "Enterprise bit" as in RFC 5101? >>> >>>> corresponding Information Element is cleared (has the =20 >>>> value 0), >>>> this IE should be set to 0. The presence of a non-zero =20 >>>> value in >>>> this IE plies that the Enterprise ID bit of the =20 >>>> corresponding >>>> Information Element is set (has the value 1). >>> >>> How does this map to the example in the appendix? >>> >>> 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID =3D 257 | Length =3D 50 = | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PEN 6871 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 14 |0x01 unsigned8 |0x05 flags | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Here, the Enterprise bit is not set (14=3D0x000E), but the PEN is =20= >>> not zero. >>> >>>> 3.9. Information Element Type Options Template >>> >>>> Similarly, for security reasons, type information for a given >>>> Information Element MUST NOT be re-defined by Information =20 >>>> Element >>>> type records, and a Collecting Process MUST NOT allow an =20 >>>> Information >>>> Element type record to replace its own internal definition of an >>>> Information Element. Information Element type records SHOULD =20= >>>> NOT be >>>> duplicated within a Transport Session, but once an Information >>>> Element type record has been exported for a given Information =20= >>>> Element >>>> within a given Transport Session, all subsequent type records =20= >>>> for >>>> that Information Element MUST be identical. Conflicting =20 >>>> semantic or >>>> type information MUST be ignored by a Collecting Process. >>> >>> Maybe repeat the scope of these restrictions: Transport Session + =20= >>> OD. >>> >>>> +-------------------------------=20 >>>> +-----------------------------------+ >>>> | IE | =20 >>>> Description | >>>> +-------------------------------=20 >>>> +-----------------------------------+ >>>> | informationElementID | The Information =20 >>>> Element | >>>> | | identifier of the =20 >>>> Information | >>>> | | Element within the =20 >>>> specified | >>>> | | Template this record =20 >>>> describes. | >>> >>> Does the record describe the IE or the record? Rephrasing suggested. >>> >>>> | | This Information Element =20 >>>> MUST be | >>>> | | defined as a Scope Field. =20 >>>> See | >>>> | | the PSAMP Information =20 >>>> Model | >>>> | | [I-D.ietf-psamp-info] for =20 >>>> a | >>>> | | definition of this =20 >>>> field. | >>>> | privateEnterpriseNumber | The Private Enterprise =20 >>>> number of | >>>> | | the Information Element =20 >>>> within | >>>> | | the specified Template =20 >>>> this | >>>> | | record describes. =20 >>>> This | >>> >>> same as before >>> >>>> | | Information Element MUST =20 >>>> be | >>>> | | defined as a Scope =20 >>>> Field. | >>> >>>> 3.10. Data Type and Semantics Restrictions >>>> >>>> Note that the informationElementSemantics values are primarily >>>> intended to differentiate semantic interpretation of numeric =20 >>>> values, >>>> and that not all combinations of the =20 >>>> informationElementDataType and >>>> informationElementSemantics Information Elements are valid; =20 >>>> e.g., a >>>> counter cannot be encoded as an IPv4 address. Any >>>> informationElementSemantics value is valid for unsigned >>>> informationElementDatimplies that the Enterprise ID bit of the =20 >>>> corresponding >>>> Information Element is set (has the value 1). >>> >>> How does this map to the example in the appendix? >>> >>> 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID =3D 257 | Length =3D 50 = | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PEN 6871 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 14 |0x01 unsigned8 |0x05 flags | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Here, the Enterprise bit is not set (14=3D0x000E), but the PEN is =20= >>> not zero. >>> >>>> 3.9. Information Element Type Options Template >>> >>>> Similarly, for security reasons, type information for a given >>>> Information Element MUST NOT be re-defined by Information =20 >>>> Element >>>> type records, and a Collecting Process MUST NOT allow an =20 >>>> Information >>>> Element type record to replace its own internal definition of an >>>> Information Element. Information Element type records SHOULD =20= >>>> NOT be >>>> duplicated within a Transport Session, but once an Information >>>> Element type record has been exported for a given Information =20= >>>> Element >>>> within a given Transport Session, all subsequent type records =20= >>>> for >>>> that Information Element MUST be identical. Conflicting =20 >>>> semantic or >>>> type information MUST be ignored by a Collecting Process. >>> >>> Maybe repeat the scope of these restrictions: Transport Session + =20= >>> OD. >>> >>>> +-------------------------------=20 >>>> +-----------------------------------+ >>>> | IE | =20 >>>> Description | >>>> +-------------------------------=20 >>>> +-----------------------------------+ >>>> | informationElementID | The Information =20 >>>> Element | >>>> | | identifier of the =20 >>>> Information | >>>> | | Element within the =20 >>>> specified | >>>> | | Template this record =20 >>>> describes. | >>> >>> Does the record describe the IE or the record? Rephrasing suggested. >>> >>>> | | This Information Element =20 >>>> MUST be | >>>> | | defined as a Scope Field. =20 >>>> See | >>>> | | the PSAMP Information =20 >>>> Model | >>>> | | [I-D.ietf-psamp-info] for =20 >>>> a | >>>> | | definition of this =20 >>>> field. | >>>> | privateEnterpriseNumber | The Private Enterprise =20 >>>> number of | >>>> | | the Information Element =20 >>>> within | >>>> | | the specified Template =20 >>>> this | >>>> | | record describes. =20 >>>> This | >>> >>> same as before >>> >>>> | | Information Element MUST =20 >>>> be | >>>> | | defined as a Scope =20 >>>> Field. | >>> >>>> 3.10. Data Type and Semantics Restrictions >>>> >>>> Note that the informationElementSemantics values are primarily >>>> intended to differentiate semantic interpretation of numeric =20 >>>> values, >>>> and that not all combinations of the =20 >>>> informationElementDataType and >>>> informationElementSemantics Information Elements are valid; =20 >>>> e.g., a >>>> counter cannot be encoded as an IPv4 address. Any >>>> informationElementSemantics value is valid for unsigned >>>> informationElementDaType values ("unsigned8", "unsigned16", >>>> "unsigned32", or "unsigned64"). Any informationElementSemantics >>>> value except flags is valid for signed =20 >>>> informationElementDataType >>>> values ("signed8", "signed16", "signed32", or "signed64"). Any >>>> informationElementSemantics value except "identifier" or =20 >>>> "flags" is >>>> valid for floating-point informationElementDataType values =20 >>>> ("float32" >>>> or "float64"). Only the informationElementSemantics value =20 >>>> "none" is >>>> valid for all other other informationElementDataType values >>>> ("octetArray", "boolean", "macAddress", "string", =20 >>>> "dateTimeSeconds", >>>> "dateTimeMilliseconds", "dateTimeMicroseconds", >>>> "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). >>> >>> Add reference to RFC 5102 section 3.2 where these limitations are >>> already specified. >>> >>>> Appendix A. Examples >>> >>> See comment to section 3.8. >>> >>> >>> >>> >>> --------------------------------------------------------------------=20= >>> ---- >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> >> --=20 >> Dipl.-Ing. Gerhard M=FCnz >> Computer Networks and Internet >> Wilhelm Schickard Institute for Computer Science >> University of Tuebingen >> Sand 13 (Room B309), D-72076 Tuebingen, Germany >> Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 >> E-mail: muenz@informatik.uni-tuebingen.de >> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > --Apple-Mail-1--651416985 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin forwarded message:

From: = Brian Trammell <trammell@tik.ee.ethz.ch>
Date: June 19, 2008 2:35:55 PM = GMT+02:00
Subject: Re: [IPFIX] WG Last Call for = 'Exporting Types' draft


On Jun 18, 2008, at 10:18 AM, Gerhard Muenz = wrote:
>>> "unsigned32", or "unsigned64"). Any informationElementSemantics >>>> value except flags is valid for signed =20 >>>> informationElementDataType >>>> values ("signed8", "signed16", "signed32", or "signed64"). Any >>>> informationElementSemantics value except "identifier" or =20 >>>> "flags" is >>>> valid for floating-point informationElementDataType values =20 >>>> ("float32" >>>> or "float64"). Only the informationElementSemantics value =20 >>>> "none" is >>>> valid for all other other informationElementDataType values >>>> ("octetArray", "boolean", "macAddress", "string", =20 >>>> "dateTimeSeconds", >>>> "dateTimeMilliseconds", "dateTimeMicroseconds", >>>> "dateTimeNanoseconds", "ipv4Address", or "ipv6Address"). >>> >>> Add reference to RFC 5102 section 3.2 where these limitations are >>> already specified. >>> >>>> Appendix A. Examples >>> >>> See comment to section 3.8. >>> >>> >>> >>> >>> --------------------------------------------------------------------=20= >>> ---- >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> >> --=20 >> Dipl.-Ing. Gerhard M=FCnz >> Computer Networks and Internet >> Wilhelm Schickard Institute for Computer Science >> University of Tuebingen >> Sand 13 (Room B309), D-72076 Tuebingen, Germany >> Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 >> E-mail: muenz@informatik.uni-tuebingen.de >> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > --Apple-Mail-1--651416985 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin forwarded message:

From: = Brian Trammell <trammell@tik.ee.ethz.ch>
Date: June 19, 2008 2:35:55 PM = GMT+02:00
Subject: Re: [IPFIX] WG Last Call for = 'Exporting Types' draft


On Jun 18, 2008, at 10:18 AM, Gerhard Muenz = wrote:
r>
=
Dear all,

I forgot = two more things in my review:

In RFC 5102, abstract data types = and data type semantics are explained
in = subsequent sections. Therefore, I would also move the definition = of
informationElementSemantics IE right after the = definition of
informationElementDataType = IE:
3.1.=A0 = informationElementDataType
3.6. =3D> = 3.2=A0 = informationElementSemantics

The = sections are arranged in alphabetical order so as to allow the IEs to be = found by name quickly; the proposed rearrangement would break = that.

=
Secondly, the definition of = the privateEnterpriseNumber IE allows zero
values = although type information must not be exported for = non-enterprise
IEs.
Is this because the definition of = privateEnterpriseNumber is to be
generic and = not restricted to the usage of type information export?
If so, I would add a note that in the context of = this draft,
privateEnterpriseNumber must not = be zero.
This is not a constraint imposed = by this document. Within the context of type information export, the PEN = may be zero.

The only constraint here is in Paragraph 4 of = section 2.9 (Information Element Type OT MUST NOT redefine an IE; CP = MUST ignore redefinitions). This allows the potential to use this = mechanism to improve interoperability between IPFIX implementations =
=
Dear all,

I forgot = two more things in my review:

In RFC 5102, abstract data types = and data type semantics are explained
in = subsequent sections. Therefore, I would also move the definition = of
informationElementSemantics IE right after the = definition of
informationElementDataType = IE:
3.1.=A0 = informationElementDataType
3.6. =3D> = 3.2=A0 = informationElementSemantics

The = sections are arranged in alphabetical order so as to allow the IEs to be = found by name quickly; the proposed rearrangement would break = that.

=
Secondly, the definition of = the privateEnterpriseNumber IE allows zero
values = although type information must not be exported for = non-enterprise
IEs.
Is this because the definition of = privateEnterpriseNumber is to be
generic and = not restricted to the usage of type information export?
If so, I would add a note that in the context of = this draft,
privateEnterpriseNumber must not = be zero.
This is not a constraint imposed = by this document. Within the context of type information export, the PEN = may be zero.

The only constraint here is in Paragraph 4 of = section 2.9 (Information Element Type OT MUST NOT redefine an IE; CP = MUST ignore redefinitions). This allows the potential to use this = mechanism to improve interoperability between IPFIX implementations including different versions of the IANA registry.


Brian



Gerhard Muenz wrote:
=
Dear all,

Nevil = Brownlee wrote:
this version resolved all issues = raised in earlier versions, and there's
been no = discussion on the IPFIX list since.

Its Working Group Last Call = starts now (5 June 08), and will finish
on = Friday 20 June 08.
Please read it one more time - I = need some reviews so that I can prepare
the = Shepherd Document for it.=A0 = And of course, please send any or all
your comments/feedback to the IPFIX list.
=

Please find my review comments below.

Gerhard


1.1. IPFIX Documents Overview
=


Brian



Gerhard Muenz wrote:
=
Dear all,

Nevil = Brownlee wrote:
this version resolved all issues = raised in earlier versions, and there's
been no = discussion on the IPFIX list since.

Its Working Group Last Call = starts now (5 June 08), and will finish
on = Friday 20 June 08.
Please read it one more time - I = need some reviews so that I can prepare
the = Shepherd Document for it.=A0 = And of course, please send any or all
your comments/feedback to the IPFIX list.
=

Please find my review comments below.

Gerhard


1.1. IPFIX Documents Overview
=

Maybe stress relevant relationships to this = document:
RFC 5102: specifies abstract = data types and additional data type semantics
RFC 5101: specifies the encoding of the data = types

=
3.1.=A0 = informationElementDataType

Maybe = change to informationElementAbstractDataType to be more = precise.

=
=A0=A0 Description: =A0 A description of the storage = type of an IPFIX
=A0 =A0 =A0 information = element.=A0 These = correspond to the abstract data types

You = introduce a new term "storage type". What is it? Is it necessary = to
use this term instead of "abstract data = type"?

=
=A0 =A0 =A0 defined in section = 3.1 of the IPFIX Information Model [RFC5102];
=A0 =A0 =A0 = see that section for more information on the types = described
=A0 =A0 =A0 below.=A0 This field may take the = following values:

=A0 = informationElementSemantics

Maybe = call this informationElementDataTypeSemantic?

=A0=A0 Description:
Maybe stress relevant relationships to this = document:
RFC 5102: specifies abstract = data types and additional data type semantics
RFC 5101: specifies the encoding of the data = types

=
3.1.=A0 = informationElementDataType

Maybe = change to informationElementAbstractDataType to be more = precise.

=
=A0=A0 Description: =A0 A description of the storage = type of an IPFIX
=A0 =A0 =A0 information = element.=A0 These = correspond to the abstract data types

You = introduce a new term "storage type". What is it? Is it necessary = to
use this term instead of "abstract data = type"?

=
=A0 =A0 =A0 defined in section = 3.1 of the IPFIX Information Model [RFC5102];
=A0 =A0 =A0 = see that section for more information on the types = described
=A0 =A0 =A0 below.=A0 This field may take the = following values:

=A0 = informationElementSemantics

Maybe = call this informationElementDataTypeSemantic?

=A0=A0 Description: =A0 A description of the = semantics of an IPFIX information
=A0 =A0 =A0 element.=A0 These correspond to the data = type semantics defined in

Why do these = semantics "correspond" to the data type semantics in RFC
5102? They "are" the data type semantics.
=3D> A description of the data type semantics of an = IPFIX information
element.

=A0 =A0 =A0 section 3.2 of the = IPFIX Information Model [RFC5102]; see that
=A0 =A0 =A0 section for more = information on the types described below.=A0 This
=A0 =A0 =A0 = field may take the following values; the special value 0x00 = (none)
=A0 =A0 =A0 is used to note that = no semantics apply to the field; it cannot be
=A0 =A0 =A0 = manipulated by a Collecting Process or File Reader that does = not
=A0 =A0 =A0 understand it a = priori.
3.8.=A0 = privateEnterpriseNumber

=A0=A0 Description: =A0 A private enterprise number = used to scope an
=A0 =A0 =A0 informationElementID, = as would appear in an IPFIX Template Record.
=A0 =A0 =A0 = This element can be used to scope properties to a = specific
=A0 =A0 =A0 Information = Element.=A0 If the = Enterprise ID bit of the
=A0 A description of the = semantics of an IPFIX information
=A0 =A0 =A0 element.=A0 These correspond to the data = type semantics defined in

Why do these = semantics "correspond" to the data type semantics in RFC
5102? They "are" the data type semantics.
=3D> A description of the data type semantics of an = IPFIX information
element.

=A0 =A0 =A0 section 3.2 of the = IPFIX Information Model [RFC5102]; see that
=A0 =A0 =A0 section for more = information on the types described below.=A0 This
=A0 =A0 =A0 = field may take the following values; the special value 0x00 = (none)
=A0 =A0 =A0 is used to note that = no semantics apply to the field; it cannot be
=A0 =A0 =A0 = manipulated by a Collecting Process or File Reader that does = not
=A0 =A0 =A0 understand it a = priori.
3.8.=A0 = privateEnterpriseNumber

=A0=A0 Description: =A0 A private enterprise number = used to scope an
=A0 =A0 =A0 informationElementID, = as would appear in an IPFIX Template Record.
=A0 =A0 =A0 = This element can be used to scope properties to a = specific
=A0 =A0 =A0 Information = Element.=A0 If the = Enterprise ID bit of the

What is = "Enterprise ID bit"?
Do you mean "Enterprise = bit" as in RFC 5101?
=A0 =A0 =A0 corresponding = Information Element is cleared (has the value 0),
=A0 =A0 =A0 = this IE should be set to 0.=A0= The presence of a non-zero value in
=A0 =A0 =A0 this IE implies that = the Enterprise ID bit of the corresponding
=A0 =A0 =A0 Information Element = is set (has the value 1).

How does this = map to the example in the appendix?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 1 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 2 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 = |=A0 =A0 =A0 =A0 =A0 = Set ID =3D 257 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 = Length =3D=A0 50 = =A0 =A0 =A0 =A0 |
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 PEN 6871 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 = |
What is = "Enterprise ID bit"?
Do you mean "Enterprise = bit" as in RFC 5101?
=A0 =A0 =A0 corresponding = Information Element is cleared (has the value 0),
=A0 =A0 =A0 = this IE should be set to 0.=A0= The presence of a non-zero value in
=A0 =A0 =A0 this IE implies that = the Enterprise ID bit of the corresponding
=A0 =A0 =A0 Information Element = is set (has the value 1).

How does this = map to the example in the appendix?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 1 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 2 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 = |=A0 =A0 =A0 =A0 =A0 = Set ID =3D 257 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 = Length =3D=A0 50 = =A0 =A0 =A0 =A0 |
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 PEN 6871 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 = IE 14 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |0x01 unsigned8 |0x05 flags =A0 =A0 |
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, the Enterprise bit is not set (14=3D0x000E), = but the PEN is not zero.

=A0 Information = Element Type Options Template

=A0=A0 = Similarly, for security reasons, type information for a = given
=A0=A0 Information Element MUST = NOT be re-defined by Information Element
=A0=A0 type records, and a = Collecting Process MUST NOT allow an Information
=A0=A0 = Element type record to replace its own internal definition of = an
=A0=A0 = Information Element.=A0 = Information Element type records SHOULD NOT be
=A0=A0 = duplicated within a Transport Session, but once an = Information
=A0=A0 Element type record has = been exported for a given Information Element
=A0=A0 = within a given Transport Session, all subsequent type records = for
=A0=A0 that Information Element = MUST be identical.=A0 = Conflicting semantic or
=A0=A0 type information MUST be = ignored by a Collecting Process.

Maybe = repeat the scope of these restrictions: Transport Session + = OD.

=
=A0 =A0 =A0 =A0 =A0 = IE 14 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |0x01 unsigned8 |0x05 flags =A0 =A0 |
=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, the Enterprise bit is not set (14=3D0x000E), = but the PEN is not zero.

=A0 Information = Element Type Options Template

=A0=A0 = Similarly, for security reasons, type information for a = given
=A0=A0 Information Element MUST = NOT be re-defined by Information Element
=A0=A0 type records, and a = Collecting Process MUST NOT allow an Information
=A0=A0 = Element type record to replace its own internal definition of = an
=A0=A0 = Information Element.=A0 = Information Element type records SHOULD NOT be
=A0=A0 = duplicated within a Transport Session, but once an = Information
=A0=A0 Element type record has = been exported for a given Information Element
=A0=A0 = within a given Transport Session, all subsequent type records = for
=A0=A0 that Information Element = MUST be identical.=A0 = Conflicting semantic or
=A0=A0 type information MUST be = ignored by a Collecting Process.

Maybe = repeat the scope of these restrictions: Transport Session + = OD.

=
=A0=A0 = +-------------------------------+----------------------------------= -+
=A0=A0 = | IE=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Description =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |
=A0=A0 = +-------------------------------+----------------------------------= -+
=A0=A0 = | informationElementID=A0 =A0= =A0 =A0 =A0 | The Information Element =A0 =A0 =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | identifier of the Information = =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Element within the = specified=A0 =A0 =A0 = |
=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Template this record describes. =A0 |

Does the = record describe the IE or the record? Rephrasing suggested.

=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | This Information Element MUST be=A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | defined as a Scope Field.=A0 See=A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | the PSAMP Information Model = =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | [I-D.ietf-psamp-info] for a = =A0 =A0 =A0 |
=A0=A0 = +-------------------------------+----------------------------------= -+
=A0=A0 = | IE=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Description =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |
=A0=A0 = +-------------------------------+----------------------------------= -+
=A0=A0 = | informationElementID=A0 =A0= =A0 =A0 =A0 | The Information Element =A0 =A0 =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | identifier of the Information = =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Element within the = specified=A0 =A0 =A0 = |
=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Template this record describes. =A0 |

Does the = record describe the IE or the record? Rephrasing suggested.

=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | This Information Element MUST be=A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | defined as a Scope Field.=A0 See=A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | the PSAMP Information Model = =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | [I-D.ietf-psamp-info] for a = =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | definition of this field. = =A0 =A0 =A0 =A0 |
=A0=A0 = | privateEnterpriseNumber =A0= =A0 =A0 | The Private Enterprise number of=A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | the Information Element = within=A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | the specified Template this = =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | record describes.=A0 This =A0 =A0 =A0 =A0 =A0 |
=

same as before

=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Information Element MUST be =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | defined as a Scope Field. = =A0 =A0 =A0 =A0 |
=

=
3.10.=A0 Data Type and Semantics = Restrictions

=A0=A0 = Note that the informationElementSemantics values are = primarily
=A0=A0 intended to differentiate = semantic interpretation of numeric values,
=A0=A0 and that not all = combinations of the informationElementDataType and
=A0=A0 = informatiospan class=3D"Apple-converted-space">=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | definition of this field. = =A0 =A0 =A0 =A0 |
=A0=A0 = | privateEnterpriseNumber =A0= =A0 =A0 | The Private Enterprise number of=A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | the Information Element = within=A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | the specified Template this = =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | record describes.=A0 This =A0 =A0 =A0 =A0 =A0 |
=

same as before

=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Information Element MUST be =A0 =A0 =A0 |
=A0=A0 = | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | defined as a Scope Field. = =A0 =A0 =A0 =A0 |
=

=
3.10.=A0 Data Type and Semantics = Restrictions

=A0=A0 = Note that the informationElementSemantics values are = primarily
=A0=A0 intended to differentiate = semantic interpretation of numeric values,
=A0=A0 and that not all = combinations of the informationElementDataType and
=A0=A0 = informatnElementSemantics Information Elements are valid; e.g., = a
=A0=A0 = counter cannot be encoded as an IPv4 address.=A0 Any
=A0=A0 = informationElementSemantics value is valid for unsigned
=A0=A0 = informationElementDataType values ("unsigned8", = "unsigned16",
=A0=A0 "unsigned32", or = "unsigned64").=A0 Any = informationElementSemantics
=A0=A0 value except flags is = valid for signed informationElementDataType
=A0=A0 values ("signed8", = "signed16", "signed32", or "signed64").=A0 Any
=A0=A0 = informationElementSemantics value except "identifier" or "flags" = is
=A0=A0 = valid for floating-point informationElementDataType values = ("float32"
=A0=A0 or "float64").=A0 Only the = informationElementSemantics value "none" is
=A0=A0 valid for all other other = informationElementDataType values
=A0=A0 ("octetArray", "boolean", = "macAddress", "string", "dateTimeSeconds",
=A0=A0 "dateTimeMilliseconds", = "dateTimeMicroseconds",
=A0=A0 "dateTimeNanoseconds", = "ipv4Address", or "ipv6Address").

Add = reference to RFC 5102 section 3.2 where these limitations are
already specified.

Appendix A.=A0 = Examples

See comment to section = 3.8.
=A0=A0 = counter cannot be encoded as an IPv4 address.=A0 Any
=A0=A0 = informationElementSemantics value is valid for unsigned
=A0=A0 = informationElementDataType values ("unsigned8", = "unsigned16",
=A0=A0 "unsigned32", or = "unsigned64").=A0 Any = informationElementSemantics
=A0=A0 value except flags is = valid for signed informationElementDataType
=A0=A0 values ("signed8", = "signed16", "signed32", or "signed64").=A0 Any
=A0=A0 = informationElementSemantics value except "identifier" or "flags" = is
=A0=A0 = valid for floating-point informationElementDataType values = ("float32"
=A0=A0 or "float64").=A0 Only the = informationElementSemantics value "none" is
=A0=A0 valid for all other other = informationElementDataType values
=A0=A0 ("octetArray", "boolean", = "macAddress", "string", "dateTimeSeconds",
=A0=A0 "dateTimeMilliseconds", = "dateTimeMicroseconds",
=A0=A0 "dateTimeNanoseconds", = "ipv4Address", or "ipv6Address").

Add = reference to RFC 5102 section 3.2 where these limitations are
already specified.

Appendix A.=A0 = Examples

See comment to section = 3.8.





IPFIX mailing list

--=A0
Computer = Networks and Internet
Wilhelm Schickard Institute = for Computer Science
University of = Tuebingen
Sand 13 (Room B309), D-72076 = Tuebingen, Germany
Phone:=A0 +49 7071 29-70534 =A0 =A0 =A0 Fax: +49 7071 = 29-5220

IPFIX mailing list


= --Apple-Mail-1--651416985-- --===============0324608917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cn-right: 0px; = margin-bottom: 0px; margin-left: 0px; min-height: 14px; ">




IPFIX mailing list

--=A0
Computer = Networks and Internet
Wilhelm Schickard Institute = for Computer Science
University of = Tuebingen
Sand 13 (Room B309), D-72076 = Tuebingen, Germany
Phone:=A0 +49 7071 29-70534 =A0 =A0 =A0 Fax: +49 7071 = 29-5220

IPFIX mailing list


= --Apple-Mail-1--651416985-- --===============0324608917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0ontent-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0324608917==-- Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0324608917==-- From ipfix-bounces@ietf.org Thu Jun 19 06:14:11 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BC83A681C; Thu, 19 Jun 2008 06:14:11 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B6B3A6767 for ; Thu, 19 Jun 2008 06:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG5WW9gsdC29 for ; Thu, 19 Jun 2008 06:14:08 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 2F7273A685C for ; Thu, 19 Jun 2008 06:14:07 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K9JyY-0007dg-5M; Thu, 19 Jun 2008 15:14:54 +0200 Message-ID: <485A5BD4.8040706@informatik.uni-tuebingen.de> Date: Thu, 19 Jun 2008 15:15:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <4858C4DD.8040304@informatik.uni-tuebingen.de> In-Reply-To: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0492577929==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0492577929== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070606050101070403060404" This is a cryptographically signed message in MIME format. --------------ms070606050101070403060404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, Brian Trammell wrote: > On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote: >> Secondly, the definition of the privateEnterpriseNumber IE allows zero= >> values although type information must not be exported for non-enterpri= se >> IEs. >> Is this because the definition of privateEnterpriseNumber is to be >> generic and not restricted to the usage of type information export? >> If so, I would add a note that in the context of this draft, >> privateEnterpriseNumber must not be zero. >=20 > This is not a constraint imposed by this document. Within the context o= f > type information export, the PEN may be zero. >=20 > The only constraint here is in Paragraph 4 of section 2.9 (Information > Element Type OT MUST NOT redefine an IE; CP MUST ignore redefinitions).= > This allows the potential to use this mechanism to improve > interoperability between IPFIX implementations including different > versions of the IANA registry. The introduction says: Note that the solution described in this draft is only for providing interoperability for enterprise specific information elements that are not yet standardized. Hence the document is only about enterprise-specific IEs. According to my understanding, an enterprise-specific IE always requires a PEN because RFC 5101 says: The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element identifier will report an IETF-specified Information Element, and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Section A.4.2. PENs assigned by IANA start with 1 (0 is reserved). http://www.iana.org/assignments/enterprise-numbers In the definition of privateEnterpriseNumber, you assume implicitly that the PEN is never 0 for a registered enterprise (which is ok in my opinion= ): Description: A private enterprise number used to scope an informationElementID, as would appear in an IPFIX Template Record. This element can be used to scope properties to a specific Information Element. If the Enterprise ID bit of the corresponding Information Element is cleared (has the value 0), this IE should be set to 0. The presence of a non-zero value in this IE implies that the Enterprise ID bit of the corresponding Information Element is set (has the value 1). However, as the draft is about enterprise-specific IEs only, the PEN will never be zero, and the enterprise bit will never be cleared in the IE type information record. Therefore, I would add a corresponding remark. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070606050101070403060404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxOTEzMTUwMFowIwYJKoZIhvcNAQkEMRYEFOaQ3FEwxneM rV8GbfXmHkdH6a4aMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBLnG6PSKiM8hBdJhPhsXnviwEQmTS4XDYNasu+oxwY0ZdP1dAqyp6Y1X9O LEO3ngcFhmUo5cJSYxezHmXUr4wFg22qZsD3Wwmzjnl5bU4/4XSt1hUq9JKNC8VJgXJdin/r QplA7CL5cou/nCYw6ilyRoRHBmPPqSdn5ZrQ2lVbdWrNvIKcWr1eG3TXSRd3T1/A1i8yHxKg iKgd2Uh3c/Xk8Dd/Sf+JrTa2v1jjV5p8phyQPcciLWAxGPHrEgKCDLy7/fQfPNivhyUmdk8c ZCzg9Czuni2ABEppHnzZuZVb1IPuohrf8qY3tkfk7/MPn7aHMqW9xIzTrhR6nmOFcIVUAAAA AAAA --------------ms070606050101070403060404-- --===============0492577929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0492577929==-- From ipfix-bounces@ietf.org Thu Jun 19 06:14:11 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BC83A681C; Thu, 19 Jun 2008 06:14:11 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B6B3A6767 for ; Thu, 19 Jun 2008 06:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG5WW9gsdC29 for ; Thu, 19 Jun 2008 06:14:08 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 2F7273A685C for ; Thu, 19 Jun 2008 06:14:07 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K9JyY-0007dg-5M; Thu, 19 Jun 2008 15:14:54 +0200 Message-ID: <485A5BD4.8040706@informatik.uni-tuebingen.de> Date: Thu, 19 Jun 2008 15:15:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <4858C4DD.8040304@informatik.uni-tuebingen.de> In-Reply-To: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0492577929==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0492577929== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070606050101070403060404" This is a cryptographically signed message in MIME format. --------------ms070606050101070403060404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, Brian Trammell wrote: > On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote: >> Secondly, the definition of the privateEnterpriseNumber IE allows zero= >> values although type information must not be exported for non-enterpri= se >> IEs. >> Is this because the definition of privateEnterpriseNumber is to be >> generic and not restricted to the usage of type information export? >> If so, I would add a note that in the context of this draft, >> privateEnterpriseNumber must not be zero. >=20 > This is not a constraint imposed by this document. Within the context o= f > type information export, the PEN may be zero. >=20 > The only constraint here is in Paragraph 4 of section 2.9 (Information > Element Type OT MUST NOT redefine an IE; CP MUST ignore redefinitions).= > This allows the potential to use this mechanism to improve > interoperability between IPFIX implementations including different > versions of the IANA registry. The introduction says: Note that the solution described in this draft is only for providing interoperability for enterprise specific information elements that are not yet standardized. Hence the document is only about enterprise-specific IEs. According to my understanding, an enterprise-specific IE always requires a PEN because RFC 5101 says: The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element identifier will report an IETF-specified Information Element, and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Section A.4.2. PENs assigned by IANA start with 1 (0 is reserved). http://www.iana.org/assignments/enterprise-numbers In the definition of privateEnterpriseNumber, you assume implicitly that the PEN is never 0 for a registered enterprise (which is ok in my opinion= ): Description: A private enterprise number used to scope an informationElementID, as would appear in an IPFIX Template Record. This element can be used to scope properties to a specific Information Element. If the Enterprise ID bit of the corresponding Information Element is cleared (has the value 0), this IE should be set to 0. The presence of a non-zero value in this IE implies that the Enterprise ID bit of the corresponding Information Element is set (has the value 1). However, as the draft is about enterprise-specific IEs only, the PEN will never be zero, and the enterprise bit will never be cleared in the IE type information record. Therefore, I would add a corresponding remark. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070606050101070403060404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxOTEzMTUwMFowIwYJKoZIhvcNAQkEMRYEFOaQ3FEwxneM rV8GbfXmHkdH6a4aMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBLnG6PSKiM8hBdJhPhsXnviwEQmTS4XDYNasu+oxwY0ZdP1dAqyp6Y1X9O LEO3ngcFhmUo5cJSYxezHmXUr4wFg22qZsD3Wwmzjnl5bU4/4XSt1hUq9JKNC8VJgXJdin/r QplA7CL5cou/nCYw6ilyRoRHBmPPqSdn5ZrQ2lVbdWrNvIKcWr1eG3TXSRd3T1/A1i8yHxKg iKgd2Uh3c/Xk8Dd/Sf+JrTa2v1jjV5p8phyQPcciLWAxGPHrEgKCDLy7/fQfPNivhyUmdk8c ZCzg9Czuni2ABEppHnzZuZVb1IPuohrf8qY3tkfk7/MPn7aHMqW9xIzTrhR6nmOFcIVUAAAA AAAA --------------ms070606050101070403060404-- --===============0492577929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0492577929==-- From ipfix-bounces@ietf.org Thu Jun 19 06:23:01 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A349728C10F; Thu, 19 Jun 2008 06:23:00 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B40328C10C for ; Thu, 19 Jun 2008 06:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyEr0Ehd+QuU for ; Thu, 19 Jun 2008 06:22:54 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 0665928C110 for ; Thu, 19 Jun 2008 06:22:54 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K9K76-0007e1-PC; Thu, 19 Jun 2008 15:23:44 +0200 Message-ID: <485A5DE7.7060500@informatik.uni-tuebingen.de> Date: Thu, 19 Jun 2008 15:23:51 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0884980281==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0884980281== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090906010403050508020704" This is a cryptographically signed message in MIME format. --------------ms090906010403050508020704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Brian Trammell wrote: >>> 3.9. Information Element Type Options Template >> >>> Similarly, for security reasons, type information for a given >>> Information Element MUST NOT be re-defined by Information Element >>> type records, and a Collecting Process MUST NOT allow an Informati= on >>> Element type record to replace its own internal definition of an >>> Information Element. Information Element type records SHOULD NOT = be >>> duplicated within a Transport Session, but once an Information >>> Element type record has been exported for a given Information Elem= ent >>> within a given Transport Session, all subsequent tyFrom ipfix-bounces@ietf.org Thu Jun 19 06:23:01 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A349728C10F; Thu, 19 Jun 2008 06:23:00 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B40328C10C for ; Thu, 19 Jun 2008 06:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyEr0Ehd+QuU for ; Thu, 19 Jun 2008 06:22:54 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 0665928C110 for ; Thu, 19 Jun 2008 06:22:54 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1K9K76-0007e1-PC; Thu, 19 Jun 2008 15:23:44 +0200 Message-ID: <485A5DE7.7060500@informatik.uni-tuebingen.de> Date: Thu, 19 Jun 2008 15:23:51 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0884980281==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0884980281== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090906010403050508020704" This is a cryptographically signed message in MIME format. --------------ms090906010403050508020704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Brian Trammell wrote: >>> 3.9. Information Element Type Options Template >> >>> Similarly, for security reasons, type information for a given >>> Information Element MUST NOT be re-defined by Information Element >>> type records, and a Collecting Process MUST NOT allow an Informati= on >>> Element type record to replace its own internal definition of an >>> Information Element. Information Element type records SHOULD NOT = be >>> duplicated within a Transport Session, but once an Information >>> Element type record has been exported for a given Information Elem= ent >>> within a given Transport Session, all subsequent typepe records for >>> that Information Element MUST be identical. Conflicting semantic = or >>> type information MUST be ignored by a Collecting Process. >> >> Maybe repeat the scope of these restrictions: Transport Session + OD. >=20 > Hm. Isn't this implied by 5101? Section 3.9 starts with: The Information Element Type Options Template attaches type information to Information Elements used within Template Records, as scoped to an Observation Domain within a Transport Session. When I was reading the draft, I thought that this should also be the scope of for the restrictions mentioned in the paragraph above. Instead, you mention Transport Session as scope: Information Element type records SHOULD NOT be duplicated within a Transport Session, but once an Information Element type record has been exported for a given Information Element within a given Transport Session, all subsequent type records for that Information Element MUST be identical. That's confusing. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms090906010403050508020704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJK records for >>> that Information Element MUST be identical. Conflicting semantic = or >>> type information MUST be ignored by a Collecting Process. >> >> Maybe repeat the scope of these restrictions: Transport Session + OD. >=20 > Hm. Isn't this implied by 5101? Section 3.9 starts with: The Information Element Type Options Template attaches type information to Information Elements used within Template Records, as scoped to an Observation Domain within a Transport Session. When I was reading the draft, I thought that this should also be the scope of for the restrictions mentioned in the paragraph above. Instead, you mention Transport Session as scope: Information Element type records SHOULD NOT be duplicated within a Transport Session, but once an Information Element type record has been exported for a given Information Element within a given Transport Session, all subsequent type records for that Information Element MUST be identical. That's confusing. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms090906010403050508020704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxOTEzMjM1MVowIwYJKoZIhvcNAQkEMRYEFLrVJ6EQxFtg XuA744QROksRTzdZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCQNytGsF9aIRVCnhZ4hEA6lsfSmAq8EIW0mDQvI3mbr9Ef2zuE+8xE3Y7x jcyNMFT5NByulPKcep1N/jyauZP+pr0BGT8OhpPPem5JFDo2L9nqVUBh4HoXfiKsLGlebvV5 VG/nWxa/b/7Y8j7p5c0JiL2+yP25EKKxda5HYXLpakBwhjgLu5Dvgu4g05BAAKmcxuMT0wz1 HwFCT1r0EftH+4IRY+X53YIS7GieQfvWUiIrFQz6Ni5cjxY5woeQTUl0omvr9EtE/lrFFA1n Mx9eVyfsrqD52ArmkrzNZBzZWqtzEul0+AzbybnFbvXmN4+fraAX8/Fz19uqUDYO9K/fAAAA AAAA --------------ms090906010403050508020704-- --===============0884980281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0884980281==-- IhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDYxOTEzMjM1MVowIwYJKoZIhvcNAQkEMRYEFLrVJ6EQxFtg XuA744QROksRTzdZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCQNytGsF9aIRVCnhZ4hEA6lsfSmAq8EIW0mDQvI3mbr9Ef2zuE+8xE3Y7x jcyNMFT5NByulPKcep1N/jyauZP+pr0BGT8OhpPPem5JFDo2L9nqVUBh4HoXfiKsLGlebvV5 VG/nWxa/b/7Y8j7p5c0JiL2+yP25EKKxda5HYXLpakBwhjgLu5Dvgu4g05BAAKmcxuMT0wz1 HwFCT1r0EftH+4IRY+X53YIS7GieQfvWUiIrFQz6Ni5cjxY5woeQTUl0omvr9EtE/lrFFA1n Mx9eVyfsrqD52ArmkrzNZBzZWqtzEul0+AzbybnFbvXmN4+fraAX8/Fz19uqUDYO9K/fAAAA AAAA --------------ms090906010403050508020704-- --===============0884980281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0884980281==-- From ipfix-bounces@ietf.org Thu Jun 19 08:01:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC383A6AB0; Thu, 19 Jun 2008 08:01:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5958B3A6AB0 for ; Thu, 19 Jun 2008 08:01:01 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yAnjzatKO+K for ; Thu, 19 Jun 2008 08:01:00 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 2CA253A6A69 for ; Thu, 19 Jun 2008 08:00:59 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 0385E4CF8; Thu, 19 Jun 2008 17:01:49 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id D7B56B0030; Thu, 19 Jun 2008 17:01:48 +0200 (CEST) Message-ID: <485A74DF.6060309@informatik.uni-erlangen.de> Date: Thu, 19 Jun 2008 17:01:51 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Gerhard Muenz References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: <4857B927.8090801@informatik.uni-tuebingen.de> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Nevil Brownlee wrote: > Please read it one more time - I need some reviews so that I can prepare > the Shepherd Document for it. And of course, please send any or all > your comments/feedback to the IPFIX list. Some thoughts I had when reading draft-ietf-ipfix-exporting-type-01: Section 1.1 talks about the Protocol document covering transport "via a congestion-aware transport protocol". IIRC RFC5101 also allows UDP. But, besides that, how is this important for type export? Section 1.1 starts a bit odd. One introductory sentence would make it look a bit nicer. Section 1.1 states "The IPFIX Protocol document [RFC5101] then covers the details": Why "then"? Why is this mentioned here? Wouldn't this sentence fit better into the "IPFIX Protocol documentFrom ipfix-bounces@ietf.org Thu Jun 19 08:01:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC383A6AB0; Thu, 19 Jun 2008 08:01:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5958B3A6AB0 for ; Thu, 19 Jun 2008 08:01:01 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yAnjzatKO+K for ; Thu, 19 Jun 2008 08:01:00 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 2CA253A6A69 for ; Thu, 19 Jun 2008 08:00:59 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 0385E4CF8; Thu, 19 Jun 2008 17:01:49 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id D7B56B0030; Thu, 19 Jun 2008 17:01:48 +0200 (CEST) Message-ID: <485A74DF.6060309@informatik.uni-erlangen.de> Date: Thu, 19 Jun 2008 17:01:51 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Gerhard Muenz References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: <4857B927.8090801@informatik.uni-tuebingen.de> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Nevil Brownlee wrote: > Please read it one more time - I need some reviews so that I can prepare > the Shepherd Document for it. And of course, please send any or all > your comments/feedback to the IPFIX list. Some thoughts I had when reading draft-ietf-ipfix-exporting-type-01: Section 1.1 talks about the Protocol document covering transport "via a congestion-aware transport protocol". IIRC RFC5101 also allows UDP. But, besides that, how is this important for type export? Section 1.1 starts a bit odd. One introductory sentence would make it look a bit nicer. Section 1.1 states "The IPFIX Protocol document [RFC5101] then covers the details": Why "then"? Why is this mentioned here? Wouldn't this sentence fit better into the "IPFIX Protocol docume" paragraph? Section 3 says ... "followed by the Information Element Type Options Template itself", although the term only just appeared there for the first time. Section 3.6 lists a special value to indicate that an IE has "no semantics" (semantics: "none"). Wouldn't it be better to name this value something along the lines of "opaque"? Section 3.8 defines "privateEnterpriseNumber". All the other new IEs begin with informationElement - why not this one? Also, the other documents seem to favour "Enterprise Identifier" or "Enterprise ID" over "Enterprise Number". Section 3.9 mandates that conflicting semantics "MUST be ignored" by collectors. This seems a bit lax, given that it indicates that the sender might have a completely different idea of what an IE means. Section 3.9 specifies the semantics of the IEs introduced in Section 3.4. Section 3.4 defines a new IE, informationElementRangeBegin and additionally very strict semantics. In particular, it declares use of the IE as invalid if no Range End is given. Section 3.9, on the other hand, allows one or the other to be omitted. I'm generally much more in favour of at least allowing via MAY as many IEs as possible to be omitted from an Options Data Record without breaking the protocol. The restriction of invalidating sets when fields are missing seems a bit harsh. Section 3.10 restricts what data types can be used with what semantics. Apart from the list being very hard to parse (why not make it a table?), this also seems like it might be too harsh a restriction. If I really want to treat an octet array as a series of flags (or an IP Address as an identifier) -- why keep me from doing it? Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is this on purpose? Cheers, Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix nt" paragraph? Section 3 says ... "followed by the Information Element Type Options Template itself", although the term only just appeared there for the first time. Section 3.6 lists a special value to indicate that an IE has "no semantics" (semantics: "none"). Wouldn't it be better to name this value something along the lines of "opaque"? Section 3.8 defines "privateEnterpriseNumber". All the other new IEs begin with informationElement - why not this one? Also, the other documents seem to favour "Enterprise Identifier" or "Enterprise ID" over "Enterprise Number". Section 3.9 mandates that conflicting semantics "MUST be ignored" by collectors. This seems a bit lax, given that it indicates that the sender might have a completely different idea of what an IE means. Section 3.9 specifies the semantics of the IEs introduced in Section 3.4. Section 3.4 defines a new IE, informationElementRangeBegin and additionally very strict semantics. In particular, it declares use of the IE as invalid if no Range End is given. Section 3.9, on the other hand, allows one or the other to be omitted. I'm generally much more in favour of at least allowing via MAY as many IEs as possible to be omitted from an Options Data Record without breaking the protocol. The restriction of invalidating sets when fields are missing seems a bit harsh. Section 3.10 restricts what data types can be used with what semantics. Apart from the list being very hard to parse (why not make it a table?), this also seems like it might be too harsh a restriction. If I really want to treat an octet array as a series of flags (or an IP Address as an identifier) -- why keep me from doing it? Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is this on purpose? Cheers, Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 00:49:54 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B583A68AC; Fri, 20 Jun 2008 00:49:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059823A68AC for ; Fri, 20 Jun 2008 00:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb3l-154-K5m for ; Fri, 20 Jun 2008 00:49:51 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 748163A6853 for ; Fri, 20 Jun 2008 00:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC61AD943A; Fri, 20 Jun 2008 09:49:46 +0200 (MEST) 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 3E0vNgRjZtRM; Fri, 20 Jun 2008 09:49:46 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8D73DD93DA; Fri, 20 Jun 2008 09:49:46 +0200 (MEST) In-Reply-To: <485A5DE7.7060500@informatik.uni-tuebingen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A5DE7.7060500@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 09:49:45 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Ah, I see now. Agreed and fixed, thanks. Regards, Brian On Jun 19, 2008, at 3:23 PM, Gerhard Muenz wrote: > > Brian, > > Brian Trammell wrote: >>>> 3.9. Information Element Type Options Template >>> >>>> Similarly, for security reasons, type information for a given >>>> Information Element MUST NOT be re-defined by Information = >>>> Element >>>> type records, and a Collecting Process MUST NOT allow an = >>>> Information >>>> Element type record to replace its own internal definition of an >>>> Information Element. Information Element type records SHOULD From ipfix-bounces@ietf.org Fri Jun 20 00:49:54 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B583A68AC; Fri, 20 Jun 2008 00:49:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059823A68AC for ; Fri, 20 Jun 2008 00:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb3l-154-K5m for ; Fri, 20 Jun 2008 00:49:51 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 748163A6853 for ; Fri, 20 Jun 2008 00:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC61AD943A; Fri, 20 Jun 2008 09:49:46 +0200 (MEST) 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 3E0vNgRjZtRM; Fri, 20 Jun 2008 09:49:46 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8D73DD93DA; Fri, 20 Jun 2008 09:49:46 +0200 (MEST) In-Reply-To: <485A5DE7.7060500@informatik.uni-tuebingen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A5DE7.7060500@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 09:49:45 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Ah, I see now. Agreed and fixed, thanks. Regards, Brian On Jun 19, 2008, at 3:23 PM, Gerhard Muenz wrote: > > Brian, > > Brian Trammell wrote: >>>> 3.9. Information Element Type Options Template >>> >>>> Similarly, for security reasons, type information for a given >>>> Information Element MUST NOT be re-defined by Information = >>>> Element >>>> type records, and a Collecting Process MUST NOT allow an = >>>> Information >>>> Element type record to replace its own internal definition of an >>>> Information Element. Information Element type records SHOULD= >>>> NOT be >>>> duplicated within a Transport Session, but once an Information >>>> Element type record has been exported for a given Information = >>>> Element >>>> within a given Transport Session, all subsequent type records = >>>> for >>>> that Information Element MUST be identical. Conflicting = >>>> semantic or >>>> type information MUST be ignored by a Collecting Process. >>> >>> Maybe repeat the scope of these restrictions: Transport Session + = >>> OD. >> >> Hm. Isn't this implied by 5101? > > Section 3.9 starts with: > > The Information Element Type Options Template attaches type > information to Information Elements used within Template = > Records, as > scoped to an Observation Domain within a Transport Session. > > When I was reading the draft, I thought that this should also be the > scope of for the restrictions mentioned in the paragraph above. > Instead, you mention Transport Session as scope: > > Information Element type records SHOULD NOT be > duplicated within a Transport Session, but once an Information > Element type record has been exported for a given Information = > Element > within a given Transport Session, all subsequent type records for > that Information Element MUST be identical. > > That's confusing. > > Regards, > Gerhard > > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix = >>>> NOT be >>>> duplicated within a Transport Session, but once an Information >>>> Element type record has been exported for a given Information = >>>> Element >>>> within a given Transport Session, all subsequent type records = >>>> for >>>> that Information Element MUST be identical. Conflicting = >>>> semantic or >>>> type information MUST be ignored by a Collecting Process. >>> >>> Maybe repeat the scope of these restrictions: Transport Session + = >>> OD. >> >> Hm. Isn't this implied by 5101? > > Section 3.9 starts with: > > The Information Element Type Options Template attaches type > information to Information Elements used within Template = > Records, as > scoped to an Observation Domain within a Transport Session. > > When I was reading the draft, I thought that this should also be the > scope of for the restrictions mentioned in the paragraph above. > Instead, you mention Transport Session as scope: > > Information Element type records SHOULD NOT be > duplicated within a Transport Session, but once an Information > Element type record has been exported for a given Information = > Element > within a given Transport Session, all subsequent type records for > that Information Element MUST be identical. > > That's confusing. > > Regards, > Gerhard > > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 03:02:41 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCC13A69E0; Fri, 20 Jun 2008 03:02:41 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3803A69E0 for ; Fri, 20 Jun 2008 03:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ4OqJ6hG0Pl for ; Fri, 20 Jun 2008 03:02:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 930983A6913 for ; Fri, 20 Jun 2008 03:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F1BCAD943E; Fri, 20 Jun 2008 12:02:32 +0200 (MEST) 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 GeNNVcO0vMUP; Fri, 20 Jun 2008 12:02:32 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC83CD9367; Fri, 20 Jun 2008 12:02:32 +0200 (MEST) In-Reply-To: <485A74DF.6060309@informatik.uni-erlangen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> From: Brian Trammell Date: Fri, 20 Jun 2008 12:02:29 +0200 To: Christoph Sommer X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Christoph, Thanks for the review! Comments inline. Regards, Brian On Jun 19, 2008, at 5:01 PM, Christoph Sommer wrote: > Section 3 says ... "followed by the Information Element Type Options > Template itself", although the term only just appeared there for the > first time. Hm, a minor point, perhaps, but yes... Edited. > Section 3.6 lists a special value to indicate that an IE has "no > semantics" (semantics: "none"). Wouldn't it be better to name this > value > something along the lines of "opaque"? Possibly, although that's not quite accurate, given that what "none" really means is "the default for this data type", hence I'd suggest "default". (Does anyone else have an opinion on this point?) > Section 3.8 defines "privateEnterpriseNumber". All the other new IEs > begin with informationElement - why not this one? Also, the other > documents seem to favour "Enterprise Identifier" or "Enterprise ID" > over > "Enterprise Number". The information element could be used to specify a Private Enterprise Number in any context (though this is not particularly clear from the Description; I've fixed this.); hence informationElementPrivateEnterpriseNumber is too specific, in addition to being overly verbose. The proper terminology as taken from the IANA registry, is "Private Enterprise Number". > Section 3.9 mandates that conflicting semantics "MUST be ignored" by > collectors. This seems a bit lax, given that it indicates that the > sender might have a completely different idea of what an IE means. Hmm. This is a good point. It seems the correct thing to do here is to mandate not that conflicting semantics must be ignored, but that information elements for which conflicting semantics are received must be ignored... fixed for -02. > Section 3.9 specifies the semantics of the IEs introduced in Section > 3.4. Section 3.4 defines a new IE, informationElementRangeBegin and > additionally very strict semantics. In particular, it declares use of > the IE as invalid if no Range End is given. Section 3.9, on the other > hand, allows one or the other to be omitted. I'm generally much > more in > favour of at least allowing via MAY as many IEs as possible to be > omitted from an Options Data Record without breaking the protocol. The > restriction of invalidating sets when fields are missing seems a > bit harsh. er... I'm not sure I understand the issue here. Range Begin and Range End are a pair. Either both are present, or neither are present, or one is present and it is treated as invalid (meaning, an IE described by a type record containing only a Range End would be treated as if it had no range information at all). How does this invalidate the set? > Section 3.10 restricts what data types can be used with what > semantics. > Apart from the list being very hard to parse (why not make it a > table?), > this also seems like it might be too harsh a restriction. If I really > want to treat an octet array as a series of flags (or an IP Address as > an identifier) -- why keep me from doing it? This is a descriptive list, not a proscriptive list. It doesn't really keep you from doing anything that the properties of the data types and semantics don't already. The data types for which "none" is the only acceptable semantics value have their own semantics as part of the data type (hence "default" may be a better name; see above). As for your examples: An octet array with flags semantics is an integer; as per 5102 section 3.2 you need to be able to do bitwise math on an IE in order for it to have flags semantics. An IP address has its own semantics (and its own operations, such as masking, implied by these). I agree that a table might clarify this. We'll see what we can come up with; for now I've edited them into a list, which at least makes it scan a bit more easily. > Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is > this on purpose? The IE type options template requires the informationElementId IE, which is defined in psamp-info, and as such is not yet available in the IANA registry. > > Cheers, > > Christoph > _______________________________________________ > 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 ipfix-bounces@ietf.org Fri Jun 20 03:02:41 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCC13A69E0; Fri, 20 Jun 2008 03:02:41 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3803A69E0 for ; Fri, 20 Jun 2008 03:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ4OqJ6hG0Pl for ; Fri, 20 Jun 2008 03:02:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 930983A6913 for ; Fri, 20 Jun 2008 03:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F1BCAD943E; Fri, 20 Jun 2008 12:02:32 +0200 (MEST) 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 GeNNVcO0vMUP; Fri, 20 Jun 2008 12:02:32 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC83CD9367; Fri, 20 Jun 2008 12:02:32 +0200 (MEST) In-Reply-To: <485A74DF.6060309@informatik.uni-erlangen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> From: Brian Trammell Date: Fri, 20 Jun 2008 12:02:29 +0200 To: Christoph Sommer X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Christoph, Thanks for the review! Comments inline. Regards, Brian On Jun 19, 2008, at 5:01 PM, Christoph Sommer wrote: > Section 3 says ... "followed by the Information Element Type Options > Template itself", although the term only just appeared there for the > first time. Hm, a minor point, perhaps, but yes... Edited. > Section 3.6 lists a special value to indicate that an IE has "no > semantics" (semantics: "none"). Wouldn't it be better to name this > value > something along the lines of "opaque"? Possibly, although that's not quite accurate, given that what "none" really means is "the default for this data type", hence I'd suggest "default". (Does anyone else have an opinion on this point?) > Section 3.8 defines "privateEnterpriseNumber". All the other new IEs > begin with informationElement - why not this one? Also, the other > documents seem to favour "Enterprise Identifier" or "Enterprise ID" > over > "Enterprise Number". The information element could be used to specify a Private Enterprise Number in any context (though this is not particularly clear from the Description; I've fixed this.); hence informationElementPrivateEnterpriseNumber is too specific, in addition to being overly verbose. The proper terminology as taken from the IANA registry, is "Private Enterprise Number". > Section 3.9 mandates that conflicting semantics "MUST be ignored" by > collectors. This seems a bit lax, given that it indicates that the > sender might have a completely different idea of what an IE means. Hmm. This is a good point. It seems the correct thing to do here is to mandate not that conflicting semantics must be ignored, but that information elements for which conflicting semantics are received must be ignored... fixed for -02. > Section 3.9 specifies the semantics of the IEs introduced in Section > 3.4. Section 3.4 defines a new IE, informationElementRangeBegin and > additionally very strict semantics. In particular, it declares use of > the IE as invalid if no Range End is given. Section 3.9, on the other > hand, allows one or the other to be omitted. I'm generally much > more in > favour of at least allowing via MAY as many IEs as possible to be > omitted from an Options Data Record without breaking the protocol. The > restriction of invalidating sets when fields are missing seems a > bit harsh. er... I'm not sure I understand the issue here. Range Begin and Range End are a pair. Either both are present, or neither are present, or one is present and it is treated as invalid (meaning, an IE described by a type record containing only a Range End would be treated as if it had no range information at all). How does this invalidate the set? > Section 3.10 restricts what data types can be used with what > semantics. > Apart from the list being very hard to parse (why not make it a > table?), > this also seems like it might be too harsh a restriction. If I really > want to treat an octet array as a series of flags (or an IP Address as > an identifier) -- why keep me from doing it? This is a descriptive list, not a proscriptive list. It doesn't really keep you from doing anything that the properties of the data types and semantics don't already. The data types for which "none" is the only acceptable semantics value have their own semantics as part of the data type (hence "default" may be a better name; see above). As for your examples: An octet array with flags semantics is an integer; as per 5102 section 3.2 you need to be able to do bitwise math on an IE in order for it to have flags semantics. An IP address has its own semantics (and its own operations, such as masking, implied by these). I agree that a table might clarify this. We'll see what we can come up with; for now I've edited them into a list, which at least makes it scan a bit more easily. > Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is > this on purpose? The IE type options template requires the informationElementId IE, which is defined in psamp-info, and as such is not yet available in the IANA registry. > > Cheers, > > Christoph > _______________________________________________ > 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 ipfix-bounces@ietf.org Fri Jun 20 03:22:56 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC1328C0D6; Fri, 20 Jun 2008 03:22:56 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7934428C0D6 for ; Fri, 20 Jun 2008 03:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoHfUjMcZtMa for ; Fri, 20 Jun 2008 03:22:54 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 278733A6A15 for ; Fri, 20 Jun 2008 03:22:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B0203D943E; Fri, 20 Jun 2008 12:22:53 +0200 (MEST) 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 LNJpYw0rFQWw; Fri, 20 Jun 2008 12:22:53 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7A147D943C; Fri, 20 Jun 2008 12:22:53 +0200 (MEST) In-Reply-To: <485A5BD4.8040706@informatik.uni-tuebingen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <4858C4DD.8040304@informatik.uni-tuebingen.de> <485A5BD4.8040706@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <1E066700-211D-465C-9B86-919C9BF5D30C@tik.ee.ethz.ch> From: Brian Trammell Date: Fri, 20 Jun 2008 12:22:52 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Ah, I see. The point of the paragraph in the introduction in question = is not to restrict the usefulness of this (generic) type export = mechanism to enterprise-specific IEs only, but to discourage the use = of this mechanism as a substitute for the IANA registration process. = (indeed, see point (b) in the following paragraph). However, the = intro paragraph was worded poorly: we'll fix it. Thanks! Cheers, Brian On Jun 19, 2008, at 3:15 PM, Gerhard Muenz wrote: > > Hi Brian, > > Brian Trammell wrote: >> On Jun 18, From ipfix-bounces@ietf.org Fri Jun 20 03:22:56 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC1328C0D6; Fri, 20 Jun 2008 03:22:56 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7934428C0D6 for ; Fri, 20 Jun 2008 03:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoHfUjMcZtMa for ; Fri, 20 Jun 2008 03:22:54 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 278733A6A15 for ; Fri, 20 Jun 2008 03:22:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B0203D943E; Fri, 20 Jun 2008 12:22:53 +0200 (MEST) 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 LNJpYw0rFQWw; Fri, 20 Jun 2008 12:22:53 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7A147D943C; Fri, 20 Jun 2008 12:22:53 +0200 (MEST) In-Reply-To: <485A5BD4.8040706@informatik.uni-tuebingen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <4858C4DD.8040304@informatik.uni-tuebingen.de> <485A5BD4.8040706@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <1E066700-211D-465C-9B86-919C9BF5D30C@tik.ee.ethz.ch> From: Brian Trammell Date: Fri, 20 Jun 2008 12:22:52 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Ah, I see. The point of the paragraph in the introduction in question = is not to restrict the usefulness of this (generic) type export = mechanism to enterprise-specific IEs only, but to discourage the use = of this mechanism as a substitute for the IANA registration process. = (indeed, see point (b) in the following paragraph). However, the = intro paragraph was worded poorly: we'll fix it. Thanks! Cheers, Brian On Jun 19, 2008, at 3:15 PM, Gerhard Muenz wrote: > > Hi Brian, > > Brian Trammell wrote: >> On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote: >>> Secondly, the definition of the privateEnterpriseNumber IE allows = >>> zero >>> values although type information must not be exported for non- = >>> enterprise >>> IEs. >>> Is this because the definition of privateEnterpriseNumber is to be >>> generic and not restricted to the usage of type information export? >>> If so, I would add a note that in the context of this draft, >>> privateEnterpriseNumber must not be zero. >> >> This is not a constraint imposed by this document. Within the = >> context of >> type information export, the PEN may be zero. >> >> The only constraint here is in Paragraph 4 of section 2.9 = >> (Information >> Element Type OT MUST NOT redefine an IE; CP MUST ignore = >> redefinitions). >> This allows the potential to use this mechanism to improve >> interoperability between IPFIX implementations including different >> versions of the IANA registry. > > The introduction says: > > Note that the solution described in this draft is only for = > providing > interoperability for enterprise specific information elements that > are not yet standardized. > > Hence the document is only about enterprise-specific IEs. > According to my understanding, an enterprise-specific IE always = > requires > a PEN because RFC 5101 says: > > The Information Elements are identified by the Information Element > identifier. When the Enterprise bit is set to 0, the corresponding > Information Element identifier will report an IETF-specified > Information Element, and the Enterprise Number MUST NOT be present. > When the Enterprise bit is set to 1, the corresponding Information > Element identifier will report an enterprise-specific Information > Element; the Enterprise Number MUST be present. An example of this > is shown in Section A.4.2. > > PENs assigned by IANA start with 1 (0 is reserved). > http://www.iana.org/assignments/enterprise-numbers > > In the definition of privateEnterpriseNumber, you assume implicitly = > that > the PEN is never 0 for a registered enterprise (which is ok in my = > opinion): > > Description: A private enterprise number used to scope an > informationElementID, as would appear in an IPFIX Template = > Record. > This element can be used to scope properties to a specific > Information Element. If the Enterprise ID bit of the > corresponding Information Element is cleared (has the value 0), > this IE should be set to 0. The presence of a non-zero value in > this IE implies that the Enterprise ID bit of the corresponding > Information Element is set (has the value 1). > > However, as the draft is about enterprise-specific IEs only, the PEN > will never be zero, and the enterprise bit will never be cleared in = > the > IE type information record. > Therefore, I would add a corresponding remark. > > Regards, > Gerhard > > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix 2008, at 10:18 AM, Gerhard Muenz wrote: >>> Secondly, the definition of the privateEnterpriseNumber IE allows = >>> zero >>> values although type information must not be exported for non- = >>> enterprise >>> IEs. >>> Is this because the definition of privateEnterpriseNumber is to be >>> generic and not restricted to the usage of type information export? >>> If so, I would add a note that in the context of this draft, >>> privateEnterpriseNumber must not be zero. >> >> This is not a constraint imposed by this document. Within the = >> context of >> type information export, the PEN may be zero. >> >> The only constraint here is in Paragraph 4 of section 2.9 = >> (Information >> Element Type OT MUST NOT redefine an IE; CP MUST ignore = >> redefinitions). >> This allows the potential to use this mechanism to improve >> interoperability between IPFIX implementations including different >> versions of the IANA registry. > > The introduction says: > > Note that the solution described in this draft is only for = > providing > interoperability for enterprise specific information elements that > are not yet standardized. > > Hence the document is only about enterprise-specific IEs. > According to my understanding, an enterprise-specific IE always = > requires > a PEN because RFC 5101 says: > > The Information Elements are identified by the Information Element > identifier. When the Enterprise bit is set to 0, the corresponding > Information Element identifier will report an IETF-specified > Information Element, and the Enterprise Number MUST NOT be present. > When the Enterprise bit is set to 1, the corresponding Information > Element identifier will report an enterprise-specific Information > Element; the Enterprise Number MUST be present. An example of this > is shown in Section A.4.2. > > PENs assigned by IANA start with 1 (0 is reserved). > http://www.iana.org/assignments/enterprise-numbers > > In the definition of privateEnterpriseNumber, you assume implicitly = > that > the PEN is never 0 for a registered enterprise (which is ok in my = > opinion): > > Description: A private enterprise number used to scope an > informationElementID, as would appear in an IPFIX Template = > Record. > This element can be used to scope properties to a specific > Information Element. If the Enterprise ID bit of the > corresponding Information Element is cleared (has the value 0), > this IE should be set to 0. The presence of a non-zero value in > this IE implies that the Enterprise ID bit of the corresponding > Information Element is set (has the value 1). > > However, as the draft is about enterprise-specific IEs only, the PEN > will never be zero, and the enterprise bit will never be cleared in = > the > IE type information record. > Therefore, I would add a corresponding remark. > > Regards, > Gerhard > > -- = > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 03:26:54 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD0A3A69D2; Fri, 20 Jun 2008 03:26:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858F33A69D2 for ; Fri, 20 Jun 2008 03:26:53 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E4Cv0LI-54n for ; Fri, 20 Jun 2008 03:26:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 18B283A6913 for ; Fri, 20 Jun 2008 03:26:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="scan'208";a="12222641" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 12:26:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5KAQq5O005887; Fri, 20 Jun 2008 12:26:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KAQp48005273; Fri, 20 Jun 2008 10:26:51 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KAQo407644; Fri, 20 Jun 2008 11:26:50 +0100 (BST) Message-ID: <485B85F2.6090302@cisco.com> Date: Fri, 20 Jun 2008 11:26:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1821; t=1213957612; x=1214821612; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=+4Bz4owiCTS1HQjsUzpcLYB8oqPWMP9AnYU/Yt27wMI=; b=r7GCctpjOO+cunw7wdeFn4YBD6gpclY69ufPj0v9X6uGVErHL7wfSDRPVB eolYoLPI6oFQlfDnWl/FH7hJiu9CW+Q80IcaslXj9nOtgXeZf5PamTD/+eB0 GPznfkzPv8; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, >> 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 257 | Length = 50 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PEN 6871 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IE 14 |0x01 unsigned8 |0x05 flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Here, the Enterprise bit is not set (14=0x000E), but the PEN is not >> zero. > > Hm. The intention here is that the informationElementId be the _base_ > information element ID, without the enterprise bit; in other words, > ((the IE number from the template) & ~0x8000). However, reading > section 8.2.3. of the PSAMP Info document (which is now in > Publication Requested state), such is not stated, because the > definition was written, I think, without considering enteprise- > specific IEs. > > So, the privateEnterpriseNumber IE could be defined so as to fix > this. If the PEN IE is present, then the high bit in > informationElementID is ignored. This would seem to be be the most > "be liberal in what you accept" way to address this... You could explicitly state this by defining the high bit as a "don't care" field, eg +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| IE 14 |0x01 unsigned8 |0x05 flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 03:26:54 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD0A3A69D2; Fri, 20 Jun 2008 03:26:54 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858F33A69D2 for ; Fri, 20 Jun 2008 03:26:53 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E4Cv0LI-54n for ; Fri, 20 Jun 2008 03:26:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 18B283A6913 for ; Fri, 20 Jun 2008 03:26:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="scan'208";a="12222641" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 12:26:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5KAQq5O005887; Fri, 20 Jun 2008 12:26:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KAQp48005273; Fri, 20 Jun 2008 10:26:51 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KAQo407644; Fri, 20 Jun 2008 11:26:50 +0100 (BST) Message-ID: <485B85F2.6090302@cisco.com> Date: Fri, 20 Jun 2008 11:26:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1821; t=1213957612; x=1214821612; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=+4Bz4owiCTS1HQjsUzpcLYB8oqPWMP9AnYU/Yt27wMI=; b=r7GCctpjOO+cunw7wdeFn4YBD6gpclY69ufPj0v9X6uGVErHL7wfSDRPVB eolYoLPI6oFQlfDnWl/FH7hJiu9CW+Q80IcaslXj9nOtgXeZf5PamTD/+eB0 GPznfkzPv8; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, >> 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 257 | Length = 50 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PEN 6871 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IE 14 |0x01 unsigned8 |0x05 flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Here, the Enterprise bit is not set (14=0x000E), but the PEN is not >> zero. > > Hm. The intention here is that the informationElementId be the _base_ > information element ID, without the enterprise bit; in other words, > ((the IE number from the template) & ~0x8000). However, reading > section 8.2.3. of the PSAMP Info document (which is now in > Publication Requested state), such is not stated, because the > definition was written, I think, without considering enteprise- > specific IEs. > > So, the privateEnterpriseNumber IE could be defined so as to fix > this. If the PEN IE is present, then the high bit in > informationElementID is ignored. This would seem to be be the most > "be liberal in what you accept" way to address this... You could explicitly state this by defining the high bit as a "don't care" field, eg +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| IE 14 |0x01 unsigned8 |0x05 flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 03:30:35 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5519C28C136; Fri, 20 Jun 2008 03:30:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A7928C134 for ; Fri, 20 Jun 2008 03:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKS16F7ILCHL for ; Fri, 20 Jun 2008 03:30:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 1C56F28C132 for ; Fri, 20 Jun 2008 03:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9A0E5D9449; Fri, 20 Jun 2008 12:30:28 +0200 (MEST) 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 OMSROHXdb9QU; Fri, 20 Jun 2008 12:30:28 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6918CD9444; Fri, 20 Jun 2008 12:30:28 +0200 (MEST) In-Reply-To: <485B85F2.6090302@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485B85F2.6090302@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 12:30:27 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Ah. An excellent idea; will do... Thanks, Brian On Jun 20, 2008, at 12:26 PM, Paul Aitken wrote: > Brian, > >>> 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 257 | Length = 50 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PEN 6871 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+From ipfix-bounces@ietf.org Fri Jun 20 03:30:35 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5519C28C136; Fri, 20 Jun 2008 03:30:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A7928C134 for ; Fri, 20 Jun 2008 03:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKS16F7ILCHL for ; Fri, 20 Jun 2008 03:30:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 1C56F28C132 for ; Fri, 20 Jun 2008 03:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9A0E5D9449; Fri, 20 Jun 2008 12:30:28 +0200 (MEST) 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 OMSROHXdb9QU; Fri, 20 Jun 2008 12:30:28 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6918CD9444; Fri, 20 Jun 2008 12:30:28 +0200 (MEST) In-Reply-To: <485B85F2.6090302@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485B85F2.6090302@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 12:30:27 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Ah. An excellent idea; will do... Thanks, Brian On Jun 20, 2008, at 12:26 PM, Paul Aitken wrote: > Brian, > >>> 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 257 | Length = 50 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PEN 6871 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 14 |0x01 unsigned8 |0x05 flags | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Here, the Enterprise bit is not set (14=0x000E), but the PEN is >>> not zero. >> Hm. The intention here is that the informationElementId be the >> _base_ information element ID, without the enterprise bit; in >> other words, ((the IE number from the template) & ~0x8000). >> However, reading section 8.2.3. of the PSAMP Info document (which >> is now in Publication Requested state), such is not stated, >> because the definition was written, I think, without considering >> enteprise- specific IEs. >> So, the privateEnterpriseNumber IE could be defined so as to fix >> this. If the PEN IE is present, then the high bit in >> informationElementID is ignored. This would seem to be be the >> most "be liberal in what you accept" way to address this... > > You could explicitly state this by defining the high bit as a > "don't care" field, eg > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X| IE 14 |0x01 unsigned8 |0x05 flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix -+-+-+ >>> | IE 14 |0x01 unsigned8 |0x05 flags | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Here, the Enterprise bit is not set (14=0x000E), but the PEN is >>> not zero. >> Hm. The intention here is that the informationElementId be the >> _base_ information element ID, without the enterprise bit; in >> other words, ((the IE number from the template) & ~0x8000). >> However, reading section 8.2.3. of the PSAMP Info document (which >> is now in Publication Requested state), such is not stated, >> because the definition was written, I think, without considering >> enteprise- specific IEs. >> So, the privateEnterpriseNumber IE could be defined so as to fix >> this. If the PEN IE is present, then the high bit in >> informationElementID is ignored. This would seem to be be the >> most "be liberal in what you accept" way to address this... > > You could explicitly state this by defining the high bit as a > "don't care" field, eg > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X| IE 14 |0x01 unsigned8 |0x05 flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 03:40:19 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026163A69BA; Fri, 20 Jun 2008 03:40:19 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD633A69BA for ; Fri, 20 Jun 2008 03:40:17 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4+aIfDo4JCG for ; Fri, 20 Jun 2008 03:40:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 340EA3A69AA for ; Fri, 20 Jun 2008 03:40:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="scan'208";a="12224232" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 12:40:16 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5KAeGUs011601; Fri, 20 Jun 2008 12:40:16 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KAeFHJ010837; Fri, 20 Jun 2008 10:40:16 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KAeE408750; Fri, 20 Jun 2008 11:40:15 +0100 (BST) Message-ID: <485B8916.2010400@cisco.com> Date: Fri, 20 Jun 2008 11:40:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> In-Reply-To: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3231; t=1213958416; x=1214822416; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=1N8KPjh1c3qy5/g2RUPe8Mn2Lu0QkV8Rr8zcdMo3vx0=; b=gpLEMIC5xgYgZ2iWKE4lSuT6wElXaZ5xTkffiBklu6duBeUVBpoNkMMFTY 6FCgnrKMfLPvtgQMrRwAuLQmyURFRWi6Htcndvay1EBeQgMGYGzHTTBeSQET If8Gwajj0t; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026163A69BA; Fri, 20 Jun 2008 03:40:19 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD633A69BA for ; Fri, 20 Jun 2008 03:40:17 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4+aIfDo4JCG for ; Fri, 20 Jun 2008 03:40:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 340EA3A69AA for ; Fri, 20 Jun 2008 03:40:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="scan'208";a="12224232" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 12:40:16 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5KAeGUs011601; Fri, 20 Jun 2008 12:40:16 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KAeFHJ010837; Fri, 20 Jun 2008 10:40:16 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KAeE408750; Fri, 20 Jun 2008 11:40:15 +0100 (BST) Message-ID: <485B8916.2010400@cisco.com> Date: Fri, 20 Jun 2008 11:40:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> In-Reply-To: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3231; t=1213958416; x=1214822416; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=1N8KPjh1c3qy5/g2RUPe8Mn2Lu0QkV8Rr8zcdMo3vx0=; b=gpLEMIC5xgYgZ2iWKE4lSuT6wElXaZ5xTkffiBklu6duBeUVBpoNkMMFTY 6FCgnrKMfLPvtgQMrRwAuLQmyURFRWi6Htcndvay1EBeQgMGYGzHTTBeSQET If8Gwajj0t; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, >> Section 3.6 lists a special value to indicate that an IE has "no >> semantics" (semantics: "none"). Wouldn't it be better to name this >> value something along the lines of "opaque"? > > Possibly, although that's not quite accurate, given that what "none" > really means is "the default for this data type", hence I'd suggest > "default". (Does anyone else have an opinion on this point?) "default" is good. "none" might suggest something... less. >> Section 3.9 specifies the semantics of the IEs introduced in >> Section 3.4. Section 3.4 defines a new IE, >> informationElementRangeBegin and additionally very strict >> semantics. In particular, it declares use of the IE as invalid if >> no Range End is given. Section 3.9, on the other hand, allows one >> or the other to be omitted. I'm generally much more in favour of at >> least allowing via MAY as many IEs as possible to be omitted from >> an Options Data Record without breaking the protocol. The >> restriction of invalidating sets when fields are missing seems a >> bit harsh. > > er... I'm not sure I understand the issue here. Range Begin and Range > End are a pair. Either both are present, or neither are present, or > one is present and it is treated as invalid (meaning, an IE described > by a type record containing only a Range End would be treated as if > it had no range information at all). Why should that be? A range end without a start could be assumed to start from the lowest possible value for the type, or from 0. Similarly, a range start without an end could be assumed to end at the highest possible value for the type, or 0xFF...FF. Consider: in real life we often only give one end of a range, leaving the other end implied: "starting tomorrow..." or "until Saturday". >> Section 3.10 restricts what data types can be used with what >> semantics. Apart from the list being very hard to parse (why not >> make it a table?), this also seems like it might be too harsh a >> restriction. If I really want to treat an octet array as a series >> of flags (or an IP Address as an identifier) -- why keep me from >> doing it? > > This is a descriptive list, not a proscriptive list. It doesn't > really keep you from doing anything that the properties of the data > types and semantics don't already. The data types for which "none" is > the only acceptable semantics value have their own semantics as part > of the data type (hence "default" may be a better name; see above). > As for your examples: An octet array with flags semantics is an > integer; Sounds like a bitfield to me. > as per 5102 section 3.2 you need to be able to do bitwise math on an > IE in order for it to have flags semantics. Not so: you might check the top bit of the IE number to see whether it's enterprise specific, though nobody would describe an IE as having flags semantics! > The IE type options template requires the informationElementId IE, > which is defined in psamp-info, and as such is not yet available in > the IANA registry. I hope Nevil and IANA will have this cleared up before the next meeting? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix stinfo/ipfix>, Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, >> Section 3.6 lists a special value to indicate that an IE has "no >> semantics" (semantics: "none"). Wouldn't it be better to name this >> value something along the lines of "opaque"? > > Possibly, although that's not quite accurate, given that what "none" > really means is "the default for this data type", hence I'd suggest > "default". (Does anyone else have an opinion on this point?) "default" is good. "none" might suggest something... less. >> Section 3.9 specifies the semantics of the IEs introduced in >> Section 3.4. Section 3.4 defines a new IE, >> informationElementRangeBegin and additionally very strict >> semantics. In particular, it declares use of the IE as invalid if >> no Range End is given. Section 3.9, on the other hand, allows one >> or the other to be omitted. I'm generally much more in favour of at >> least allowing via MAY as many IEs as possible to be omitted from >> an Options Data Record without breaking the protocol. The >> restriction of invalidating sets when fields are missing seems a >> bit harsh. > > er... I'm not sure I understand the issue here. Range Begin and Range > End are a pair. Either both are present, or neither are present, or > one is present and it is treated as invalid (meaning, an IE described > by a type record containing only a Range End would be treated as if > it had no range information at all). Why should that be? A range end without a start could be assumed to start from the lowest possible value for the type, or from 0. Similarly, a range start without an end could be assumed to end at the highest possible value for the type, or 0xFF...FF. Consider: in real life we often only give one end of a range, leaving the other end implied: "starting tomorrow..." or "until Saturday". >> Section 3.10 restricts what data types can be used with what >> semantics. Apart from the list being very hard to parse (why not >> make it a table?), this also seems like it might be too harsh a >> restriction. If I really want to treat an octet array as a series >> of flags (or an IP Address as an identifier) -- why keep me from >> doing it? > > This is a descriptive list, not a proscriptive list. It doesn't > really keep you from doing anything that the properties of the data > types and semantics don't already. The data types for which "none" is > the only acceptable semantics value have their own semantics as part > of the data type (hence "default" may be a better name; see above). > As for your examples: An octet array with flags semantics is an > integer; Sounds like a bitfield to me. > as per 5102 section 3.2 you need to be able to do bitwise math on an > IE in order for it to have flags semantics. Not so: you might check the top bit of the IE number to see whether it's enterprise specific, though nobody would describe an IE as having flags semantics! > The IE type options template requires the informationElementId IE, > which is defined in psamp-info, and as such is not yet available in > the IANA registry. I hope Nevil and IANA will have this cleared up before the next meeting? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 04:54:23 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE64E28C0E5; Fri, 20 Jun 2008 04:54:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7033A69E0 for ; Fri, 20 Jun 2008 04:54:22 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDJPwb0-Uw9x for ; Fri, 20 Jun 2008 04:54:21 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 03AEC3A6A6B for ; Fri, 20 Jun 2008 04:54:17 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 0027A4D24; Fri, 20 Jun 2008 13:54:16 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id D3DD7B002F; Fri, 20 Jun 2008 13:54:16 +0200 (CEST) Message-ID: <485B9A6A.7070605@informatik.uni-erlangen.de> Date: Fri, 20 Jun 2008 13:54:18 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> In-Reply-To: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, Brian Trammell wrote: > Christoph Sommer wrote: > >> In particular, [Section 3.4] declares use of >> the IE as invalid if no Range End is given. Section 3.9, on the other >> hand, allows one or the other to be omitted. > > [...] an IE described by a type record containing only a Range End would be treated as if it had no > range information at all Ah, okay. I misunderstood "invalid" as meaning "MUST NOT be done in protocol-conformant implementations". If you need this restriction, I'd suggest moving it to Section 3.9. No need to restrict the semantics of any implementation besides 'Exporting Types' that uses this IE, but I fully agree with From ipfix-bounces@ietf.org Fri Jun 20 04:54:23 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE64E28C0E5; Fri, 20 Jun 2008 04:54:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7033A69E0 for ; Fri, 20 Jun 2008 04:54:22 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDJPwb0-Uw9x for ; Fri, 20 Jun 2008 04:54:21 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 03AEC3A6A6B for ; Fri, 20 Jun 2008 04:54:17 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 0027A4D24; Fri, 20 Jun 2008 13:54:16 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id D3DD7B002F; Fri, 20 Jun 2008 13:54:16 +0200 (CEST) Message-ID: <485B9A6A.7070605@informatik.uni-erlangen.de> Date: Fri, 20 Jun 2008 13:54:18 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> In-Reply-To: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, Brian Trammell wrote: > Christoph Sommer wrote: > >> In particular, [Section 3.4] declares use of >> the IE as invalid if no Range End is given. Section 3.9, on the other >> hand, allows one or the other to be omitted. > > [...] an IE described by a type record containing only a Range End would be treated as if it had no > range information at all Ah, okay. I misunderstood "invalid" as meaning "MUST NOT be done in protocol-conformant implementations". If you need this restriction, I'd suggest moving it to Section 3.9. No need to restrict the semantics of any implementation besides 'Exporting Types' that uses this IE, but I fully agree with PaPaul that it's probably better to just allow it. >> Section 3.10 restricts what data types can be used with what semantics. > > This is a descriptive list, not a proscriptive list. It doesn't really > keep you from doing anything that the properties of the data types and > semantics don't already. I fully agree that it's nice to hint at sensible combinations of both, but currently it sure reads like a proscriptive list, stating "Information Element type records containing invalid combinations [...] MUST NOT be sent by Exporting Processes". > An IP address has its own semantics (and its own operations, such as masking, implied by these). I've probably not understood the meaning of the "semantics" field. I thought it allowed a sender to communicate something like "In Field #42 I'm storing an IP Address, which I use as an identifier", so it struck me as odd that Section 3.10 reads as if this is not allowed. Regards, Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ul that it's probably better to just allow it. >> Section 3.10 restricts what data types can be used with what semantics. > > This is a descriptive list, not a proscriptive list. It doesn't really > keep you from doing anything that the properties of the data types and > semantics don't already. I fully agree that it's nice to hint at sensible combinations of both, but currently it sure reads like a proscriptive list, stating "Information Element type records containing invalid combinations [...] MUST NOT be sent by Exporting Processes". > An IP address has its own semantics (and its own operations, such as masking, implied by these). I've probably not understood the meaning of the "semantics" field. I thought it allowed a sender to communicate something like "In Field #42 I'm storing an IP Address, which I use as an identifier", so it struck me as odd that Section 3.10 reads as if this is not allowed. Regards, Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 05:13:36 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2C93A69B0; Fri, 20 Jun 2008 05:13:36 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A403A6915 for ; Fri, 20 Jun 2008 05:13:35 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnX33rypiVNP for ; Fri, 20 Jun 2008 05:13:34 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 232223A69B0 for ; Fri, 20 Jun 2008 05:13:34 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4D3084D22; Fri, 20 Jun 2008 14:13:34 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id 2235BB002F; Fri, 20 Jun 2008 14:13:34 +0200 (CEST) Message-ID: <485B9EEF.1090804@informatik.uni-erlangen.de> Date: Fri, 20 Jun 2008 14:13:35 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> In-Reply-To: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, Brian Trammell wrote: > An IP address has its own semantics (and its own operations, such as masking, implied by these). I was trying to imagine what the possible values of a "semantics" IE would allow a collector (in particular an aggregator) to do with data it received. I came up with this list: none: No additional benefit quantity: Can freely add, substract, calculate median etc. deltaCounter: Same as quantity, but has to be aware of wraparound to 0 totalCounter: Same as deltaCounter, but might need to look at history identifier: No additional benefit flags: Can freely apply boolean operations So, at least as far as aggregation is concerned, what a collector can learn from the field is: "none" and "identifier" don't help much. Is there a difference? "quantity", "deltaCounter" and "totalCounter" tell the receiver to add up (and how to add up) the values received. "flags" tell the receiver that it can do bitwise operations on the received fields. It's sad that there's no value of the "semantics" field that tells a receiver which operations the collector performed to derive a field's value during flow creation (and, thus, which might be appropriate during aggregation). This would be helped by additional values like these: "start-of-interval" (take/took the *minimum* of all received values) "end-of-interval" (take/took the *maximum*) "and-bitfield" (take/took bitwise *and*) "or-bitfield" (take/took bitwise *or*) What do you think? Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 05:13:36 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2C93A69B0; Fri, 20 Jun 2008 05:13:36 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A403A6915 for ; Fri, 20 Jun 2008 05:13:35 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnX33rypiVNP for ; Fri, 20 Jun 2008 05:13:34 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 232223A69B0 for ; Fri, 20 Jun 2008 05:13:34 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4D3084D22; Fri, 20 Jun 2008 14:13:34 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id 2235BB002F; Fri, 20 Jun 2008 14:13:34 +0200 (CEST) Message-ID: <485B9EEF.1090804@informatik.uni-erlangen.de> Date: Fri, 20 Jun 2008 14:13:35 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> In-Reply-To: <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, Brian Trammell wrote: > An IP address has its own semantics (and its own operations, such as masking, implied by these). I was trying to imagine what the possible values of a "semantics" IE would allow a collector (in particular an aggregator) to do with data it received. I came up with this list: none: No additional benefit quantity: Can freely add, substract, calculate median etc. deltaCounter: Same as quantity, but has to be aware of wraparound to 0 totalCounter: Same as deltaCounter, but might need to look at history identifier: No additional benefit flags: Can freely apply boolean operations So, at least as far as aggregation is concerned, what a collector can learn from the field is: "none" and "identifier" don't help much. Is there a difference? "quantity", "deltaCounter" and "totalCounter" tell the receiver to add up (and how to add up) the values received. "flags" tell the receiver that it can do bitwise operations on the received fields. It's sad that there's no value of the "semantics" field that tells a receiver which operations the collector performed to derive a field's value during flow creation (and, thus, which might be appropriate during aggregation). This would be helped by additional values like these: "start-of-interval" (take/took the *minimum* of all received values) "end-of-interval" (take/took the *maximum*) "and-bitfield" (take/took bitwise *and*) "or-bitfield" (take/took bitwise *or*) What do you think? Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 05:25:51 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C4F3A6A5B; Fri, 20 Jun 2008 05:25:51 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D133A6A5B for ; Fri, 20 Jun 2008 05:25:51 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id askcTgHXxKrg for ; Fri, 20 Jun 2008 05:25:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CF9CC3A6A4D for ; Fri, 20 Jun 2008 05:25:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="12236979" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 14:25:45 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5KCPj2o010795; Fri, 20 Jun 2008 14:25:45 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KCPjXt024566; Fri, 20 Jun 2008 12:25:45 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KCPh418213; Fri, 20 Jun 2008 13:25:43 +0100 (BST) Message-ID: <485BA1CF.6060705@cisco.com> Date: Fri, 20 Jun 2008 13:25:51 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Christoph Sommer References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B9EEF.1090804@informatik.uni-erlangen.de> In-Reply-To: <485B9EEF.1090804@informatik.uni-erlangen.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1193; t=1213964745; x=1214828745; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=rfXMuEwAKQi87FLbcfuIwfI82ndFlgAh7QiOcxSqTZ4=; b=K/pTBGIaYDVSovPmUluAQTg274NkvQet2B6AmxNCc2R+tUEjT0zqmz8ZTm ND4oxI8z96WrcDhAF6qXngcY2NGyNml7RejLdk0iY/uFXPDy60ch9eDIBUYZ ZChwR+OXZu; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C4F3A6A5B; Fri, 20 Jun 2008 05:25:51 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D133A6A5B for ; Fri, 20 Jun 2008 05:25:51 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id askcTgHXxKrg for ; Fri, 20 Jun 2008 05:25:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CF9CC3A6A4D for ; Fri, 20 Jun 2008 05:25:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="12236979" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 14:25:45 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5KCPj2o010795; Fri, 20 Jun 2008 14:25:45 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KCPjXt024566; Fri, 20 Jun 2008 12:25:45 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KCPh418213; Fri, 20 Jun 2008 13:25:43 +0100 (BST) Message-ID: <485BA1CF.6060705@cisco.com> Date: Fri, 20 Jun 2008 13:25:51 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Christoph Sommer References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B9EEF.1090804@informatik.uni-erlangen.de> In-Reply-To: <485B9EEF.1090804@informatik.uni-erlangen.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1193; t=1213964745; x=1214828745; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=rfXMuEwAKQi87FLbcfuIwfI82ndFlgAh7QiOcxSqTZ4=; b=K/pTBGIaYDVSovPmUluAQTg274NkvQet2B6AmxNCc2R+tUEjT0zqmz8ZTm ND4oxI8z96WrcDhAF6qXngcY2NGyNml7RejLdk0iY/uFXPDy60ch9eDIBUYZ ZChwR+OXZu; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Christoph, > "none" and "identifier" don't help much. Is there a difference? "none" implies the IE is opaque, ie the collector has no idea what it is, what it means or how to deal with it. I can't think of a good use for this. Whereas "identifier" implies a number which is related to something else on the exporting system (ie, the identified thing). Identifiers can be compared (at least with another identifier of the same type) and can probably be displayed as integers. > It's sad that there's no value of the "semantics" field that tells a > receiver which operations the collector performed to derive a field's > value during flow creation (and, thus, which might be appropriate during > aggregation). This would be helped by additional values like these: > > "start-of-interval" (take/took the *minimum* of all received values) > "end-of-interval" (take/took the *maximum*) > "and-bitfield" (take/took bitwise *and*) > "or-bitfield" (take/took bitwise *or*) I slightly agree, though it's not clear to me how this information would make a difference to flow treatment on the collector. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix bject=help> List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Christoph, > "none" and "identifier" don't help much. Is there a difference? "none" implies the IE is opaque, ie the collector has no idea what it is, what it means or how to deal with it. I can't think of a good use for this. Whereas "identifier" implies a number which is related to something else on the exporting system (ie, the identified thing). Identifiers can be compared (at least with another identifier of the same type) and can probably be displayed as integers. > It's sad that there's no value of the "semantics" field that tells a > receiver which operations the collector performed to derive a field's > value during flow creation (and, thus, which might be appropriate during > aggregation). This would be helped by additional values like these: > > "start-of-interval" (take/took the *minimum* of all received values) > "end-of-interval" (take/took the *maximum*) > "and-bitfield" (take/took bitwise *and*) > "or-bitfield" (take/took bitwise *or*) I slightly agree, though it's not clear to me how this information would make a difference to flow treatment on the collector. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 06:15:30 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9363B3A6AC8; Fri, 20 Jun 2008 06:15:30 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B363C28C13F for ; Fri, 20 Jun 2008 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv2UIMozX2q9 for ; Fri, 20 Jun 2008 06:15:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id CA5363A6AAC for ; Fri, 20 Jun 2008 06:15:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BE280D937B; Fri, 20 Jun 2008 15:15:27 +0200 (MEST) 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 I9v8IW72IfEP; Fri, 20 Jun 2008 15:15:27 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8BE5AD936B; Fri, 20 Jun 2008 15:15:27 +0200 (MEST) In-Reply-To: <485BA1CF.6060705@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B9EEF.1090804@informatik.uni-erlangen.de> <485BA1CF.6060705@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 15:15:24 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Christoph, all, One point inline below. On Jun 20, 2008, at 2:25 PM, Paul Aitken wrote: >> It's sad that there's no value of the "semantics" field that tells a >> receiver which operations the collector performed to derive a field's >> value during flow creation (and, thus, which might be appropriate >> during >> aggregation). This would be helped by additional values like these: >> "start-of-interval" (take/took the *minimum* of all received values) >> "end-of-interval" (take/took the *maximum*) >> "and-bitfFrom ipfix-bounces@ietf.org Fri Jun 20 06:15:30 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9363B3A6AC8; Fri, 20 Jun 2008 06:15:30 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B363C28C13F for ; Fri, 20 Jun 2008 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv2UIMozX2q9 for ; Fri, 20 Jun 2008 06:15:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id CA5363A6AAC for ; Fri, 20 Jun 2008 06:15:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BE280D937B; Fri, 20 Jun 2008 15:15:27 +0200 (MEST) 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 I9v8IW72IfEP; Fri, 20 Jun 2008 15:15:27 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8BE5AD936B; Fri, 20 Jun 2008 15:15:27 +0200 (MEST) In-Reply-To: <485BA1CF.6060705@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B9EEF.1090804@informatik.uni-erlangen.de> <485BA1CF.6060705@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 15:15:24 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Christoph, all, One point inline below. On Jun 20, 2008, at 2:25 PM, Paul Aitken wrote: >> It's sad that there's no value of the "semantics" field that tells a >> receiver which operations the collector performed to derive a field's >> value during flow creation (and, thus, which might be appropriate >> during >> aggregation). This would be helped by additional values like these: >> "start-of-interval" (take/took the *minimum* of all received values) >> "end-of-interval" (take/took the *maximum*) >> "and-bitfield" (take/took bitwise *and*) >> "or-bitfield" (take/took bitwise *or*) > > I slightly agree, though it's not clear to me how this information > would make a difference to flow treatment on the collector. It's also out of scope for this draft. The semantics we describe here come from 5102 section 3.2, nothing more, nothing less. - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ield" (take/took bitwise *and*) >> "or-bitfield" (take/took bitwise *or*) > > I slightly agree, though it's not clear to me how this information > would make a difference to flow treatment on the collector. It's also out of scope for this draft. The semantics we describe here come from 5102 section 3.2, nothing more, nothing less. - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 06:25:40 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D853C3A69F9; Fri, 20 Jun 2008 06:25:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EF33A6915 for ; Fri, 20 Jun 2008 06:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11L5l3VKT018 for ; Fri, 20 Jun 2008 06:25:32 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 08D603A6929 for ; Fri, 20 Jun 2008 06:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D6CB9D9445; Fri, 20 Jun 2008 15:25:31 +0200 (MEST) 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 8dhwfj9-kBKG; Fri, 20 Jun 2008 15:25:31 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A31A7D943F; Fri, 20 Jun 2008 15:25:31 +0200 (MEST) In-Reply-To: <485B8916.2010400@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B8916.2010400@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 15:25:28 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Jun 20, 2008, at 12:40 PM, Paul Aitken wrote: > Brian, > >>> Section 3.6 lists a special value to indicate that an IE has "no >>> semantics" (semantics: "none"). Wouldn't it be better to name this >>> value something along the lines of "opaque"? >> Possibly, although that's not quite accurate, given that what "none" >> really means is "the default for this data type", hence I'd suggest >> "default". (Does anyone else have an opinion on this point?) > > "default" is good. "none" might suggest something... less. I've managed to convince myself of this too. Default it is. (None still makes sense as the nothing-to-see-here value for informationElementUnits, though...) >>> Section 3.9 specifies the semantics of the IEs introduced in >>> Section 3.4. Section 3.4 defines a new IE, >>> informationElementRangeBegin and additionally very strict >>> semantics. In particular, it declares use of the IE as invalid if >>> no Range End is given. Section 3.9, on the other hand, allows one >>> or the other to be omitted. I'm generally much more in favour of at >>> least allowing via MAY as many IEs as possible to be omitted from >>> an Options Data Record without breaking the protocol. The >>> restriction of invalidating sets when fields are missing seems a >>> bit harsh. >> er... I'm not sure I understand the issue here. Range Begin and Range >> End are a pair. Either both are present, or neither are present, or >> one is present and it is treated as invalid (meaning, an IE described >> by a type record containing only a Range End would be treated as if >> it had no range information at all). > > Why should that be? A range end without a start could be assumed to > start from the lowest possible value for the type, or from 0. > > Similarly, a range start without an end could be assumed to end at the > highest possible value for the type, or 0xFF...FF. > > Consider: in real life we often only give one end of a range, leaving > the other end implied: "starting tomorrow..." or "until Saturday". The time example I think is a but spurious, because the only sensible interpretation of (say) "until Saturday" in an IE range limitation is "from 0 UTC, 1 January 1970... until Saturday," but yes, the point is well made. I've removed these restrictions from the IE sections, and for each field in the options templates: "This element SHOULD be omitted if the (beginning|end) of the Information Element's acceptable range is defined by its data type." >>> Section 3.10 restricts what data types can be used with what >>> semantics. Apart from the list being very hard to parse (why not >>> make it a table?), this also seems like it might be too harsh a >>> restriction. If I really want to treat an octet array as a series >>> of flags (or an IP Address as an identifier) -- why keep me from >>> doing it? >> This is a descriptive list, not a proscriptive list. It doesn't >> really keep you from doing anything that the properties of the data >> types and semantics don't already. The data types for which "none" is >> the only acceptable semantics value have their own semantics as part >> of the data type (hence "default" may be a better name; see above). >> As for your examples: An octet array with flags semantics is an >> integer; > > Sounds like a bitfield to me. Well, yes. But we decided at some point not to have a completely variable-width bitfield type. 5102 section 3.2.5 clearly states flags must be integral (which makes sense, because computers generally do bitwise ops on integral types...) >> as per 5102 section 3.2 you need to be able to do bitwise math on an >> IE in order for it to have flags semantics. > > Not so: you might check the top bit of the IE number to see whether > it's > enterprise specific, though nobody would describe an IE as having > flags > semantics! Ah, okay, right. But an IE number is still integral (unsigned16)... >> The IE type options template requires the informationElementId IE, >> which is defined in psamp-info, and as such is not yet available in >> the IANA registry. > > I hope Nevil and IANA will have this cleared up before the next > meeting? psamp-info is still in the rfc editor queue, waiting for the protocol and sampling techniques edits, I think... Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 06:25:40 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D853C3A69F9; Fri, 20 Jun 2008 06:25:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EF33A6915 for ; Fri, 20 Jun 2008 06:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11L5l3VKT018 for ; Fri, 20 Jun 2008 06:25:32 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 08D603A6929 for ; Fri, 20 Jun 2008 06:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D6CB9D9445; Fri, 20 Jun 2008 15:25:31 +0200 (MEST) 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 8dhwfj9-kBKG; Fri, 20 Jun 2008 15:25:31 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A31A7D943F; Fri, 20 Jun 2008 15:25:31 +0200 (MEST) In-Reply-To: <485B8916.2010400@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B8916.2010400@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 15:25:28 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Jun 20, 2008, at 12:40 PM, Paul Aitken wrote: > Brian, > >>> Section 3.6 lists a special value to indicate that an IE has "no >>> semantics" (semantics: "none"). Wouldn't it be better to name this >>> value something along the lines of "opaque"? >> Possibly, although that's not quite accurate, given that what "none" >> really means is "the default for this data type", hence I'd suggest >> "default". (Does anyone else have an opinion on this point?) > > "default" is good. "none" might suggest something... less. I've managed to convince myself of this too. Default it is. (None still makes sense as the nothing-to-see-here value for informationElementUnits, though...) >>> Section 3.9 specifies the semantics of the IEs introduced in >>> Section 3.4. Section 3.4 defines a new IE, >>> informationElementRangeBegin and additionally very strict >>> semantics. In particular, it declares use of the IE as invalid if >>> no Range End is given. Section 3.9, on the other hand, allows one >>> or the other to be omitted. I'm generally much more in favour of at >>> least allowing via MAY as many IEs as possible to be omitted from >>> an Options Data Record without breaking the protocol. The >>> restriction of invalidating sets when fields are missing seems a >>> bit harsh. >> er... I'm not sure I understand the issue here. Range Begin and Range >> End are a pair. Either both are present, or neither are present, or >> one is present and it is treated as invalid (meaning, an IE described >> by a type record containing only a Range End would be treated as if >> it had no range information at all). > > Why should that be? A range end without a start could be assumed to > start from the lowest possible value for the type, or from 0. > > Similarly, a range start without an end could be assumed to end at the > highest possible value for the type, or 0xFF...FF. > > Consider: in real life we often only give one end of a range, leaving > the other end implied: "starting tomorrow..." or "until Saturday". The time example I think is a but spurious, because the only sensible interpretation of (say) "until Saturday" in an IE range limitation is "from 0 UTC, 1 January 1970... until Saturday," but yes, the point is well made. I've removed these restrictions from the IE sections, and for each field in the options templates: "This element SHOULD be omitted if the (beginning|end) of the Information Element's acceptable range is defined by its data type." >>> Section 3.10 restricts what data types can be used with what >>> semantics. Apart from the list being very hard to parse (why not >>> make it a table?), this also seems like it might be too harsh a >>> restriction. If I really want to treat an octet array as a series >>> of flags (or an IP Address as an identifier) -- why keep me from >>> doing it? >> This is a descriptive list, not a proscriptive list. It doesn't >> really keep you from doing anything that the properties of the data >> types and semantics don't already. The data types for which "none" is >> the only acceptable semantics value have their own semantics as part >> of the data type (hence "default" may be a better name; see above). >> As for your examples: An octet array with flags semantics is an >> integer; > > Sounds like a bitfield to me. Well, yes. But we decided at some point not to have a completely variable-width bitfield type. 5102 section 3.2.5 clearly states flags must be integral (which makes sense, because computers generally do bitwise ops on integral types...) >> as per 5102 section 3.2 you need to be able to do bitwise math on an >> IE in order for it to have flags semantics. > > Not so: you might check the top bit of the IE number to see whether > it's > enterprise specific, though nobody would describe an IE as having > flags > semantics! Ah, okay, right. But an IE number is still integral (unsigned16)... >> The IE type options template requires the informationElementId IE, >> which is defined in psamp-info, and as such is not yet available in >> the IANA registry. > > I hope Nevil and IANA will have this cleared up before the next > meeting? psamp-info is still in the rfc editor queue, waiting for the protocol and sampling techniques edits, I think... Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 06:34:06 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978933A6A7C; Fri, 20 Jun 2008 06:34:06 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF8B3A6929 for ; Fri, 20 Jun 2008 06:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4kn5Iw9hJot for ; Fri, 20 Jun 2008 06:34:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9DE203A6915 for ; Fri, 20 Jun 2008 06:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CF711D944B; Fri, 20 Jun 2008 15:25:32 +0200 (MEST) 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 SdSokfN1vRh8; Fri, 20 Jun 2008 15:25:32 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A0696D943F; Fri, 20 Jun 2008 15:25:32 +0200 (MEST) In-Reply-To: <485B9A6A.7070605@informatik.uni-erlangen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B9A6A.7070605@informatik.uni-erlangen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 15:25:30 +0200 To: Christoph Sommer X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Jun 20, 2008, at 1:54 PM, Christoph Sommer wrote: > Brian, > > Brian Trammell wrote: >> Christoph Sommer wrote: >> >>> In particular, [Section 3.4] declares use of >>> the IE as invalid if no Range End is given. Section 3.9, on the >>> other >>> hand, allows one or the other to be omitted. >> >> [...] an IE described by a type record containing only a Range End >> would be treated as if it had no >> range information at all > > Ah, okay. I misunderstood "invalid" as meaning "MUST NOT be done in > protocol-conformant implementatioFrom ipfix-bounces@ietf.org Fri Jun 20 06:34:06 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978933A6A7C; Fri, 20 Jun 2008 06:34:06 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF8B3A6929 for ; Fri, 20 Jun 2008 06:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4kn5Iw9hJot for ; Fri, 20 Jun 2008 06:34:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9DE203A6915 for ; Fri, 20 Jun 2008 06:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CF711D944B; Fri, 20 Jun 2008 15:25:32 +0200 (MEST) 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 SdSokfN1vRh8; Fri, 20 Jun 2008 15:25:32 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A0696D943F; Fri, 20 Jun 2008 15:25:32 +0200 (MEST) In-Reply-To: <485B9A6A.7070605@informatik.uni-erlangen.de> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B9A6A.7070605@informatik.uni-erlangen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 15:25:30 +0200 To: Christoph Sommer X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org On Jun 20, 2008, at 1:54 PM, Christoph Sommer wrote: > Brian, > > Brian Trammell wrote: >> Christoph Sommer wrote: >> >>> In particular, [Section 3.4] declares use of >>> the IE as invalid if no Range End is given. Section 3.9, on the >>> other >>> hand, allows one or the other to be omitted. >> >> [...] an IE described by a type record containing only a Range End >> would be treated as if it had no >> range information at all > > Ah, okay. I misunderstood "invalid" as meaning "MUST NOT be done in > protocol-conformant implementations". > > If you need this restriction, I'd suggest moving it to Section 3.9. No > need to restrict the semantics of any implementation besides > 'Exporting > Types' that uses this IE, but I fully agree with Paul that it's > probably > better to just allow it. See other message. >>> Section 3.10 restricts what data types can be used with what >>> semantics. >> >> This is a descriptive list, not a proscriptive list. It doesn't >> really >> keep you from doing anything that the properties of the data types >> and >> semantics don't already. > > I fully agree that it's nice to hint at sensible combinations of both, > but currently it sure reads like a proscriptive list, stating > "Information Element type records containing invalid combinations > [...] > MUST NOT be sent by Exporting Processes". ...because they do not make any sense, not because we are arbitrarily restricting them. >> An IP address has its own semantics (and its own operations, such >> as masking, implied by these). > > I've probably not understood the meaning of the "semantics" field. I > thought it allowed a sender to communicate something like "In Field > #42 > I'm storing an IP Address, which I use as an identifier", so it struck > me as odd that Section 3.10 reads as if this is not allowed. Have a look at section 3.2 of RFC 5102, where the various semantics are defined in detail. Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ns". > > If you need this restriction, I'd suggest moving it to Section 3.9. No > need to restrict the semantics of any implementation besides > 'Exporting > Types' that uses this IE, but I fully agree with Paul that it's > probably > better to just allow it. See other message. >>> Section 3.10 restricts what data types can be used with what >>> semantics. >> >> This is a descriptive list, not a proscriptive list. It doesn't >> really >> keep you from doing anything that the properties of the data types >> and >> semantics don't already. > > I fully agree that it's nice to hint at sensible combinations of both, > but currently it sure reads like a proscriptive list, stating > "Information Element type records containing invalid combinations > [...] > MUST NOT be sent by Exporting Processes". ...because they do not make any sense, not because we are arbitrarily restricting them. >> An IP address has its own semantics (and its own operations, such >> as masking, implied by these). > > I've probably not understood the meaning of the "semantics" field. I > thought it allowed a sender to communicate something like "In Field > #42 > I'm storing an IP Address, which I use as an identifier", so it struck > me as odd that Section 3.10 reads as if this is not allowed. Have a look at section 3.2 of RFC 5102, where the various semantics are defined in detail. Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 06:53:12 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E133A69F9; Fri, 20 Jun 2008 06:53:12 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748823A6A51 for ; Fri, 20 Jun 2008 06:53:10 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gyLuKRFRZIy for ; Fri, 20 Jun 2008 06:53:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 390683A69F9 for ; Fri, 20 Jun 2008 06:53:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="12249340" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 15:53:05 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5KDr5il010386; Fri, 20 Jun 2008 15:53:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KDr4Xi005032; Fri, 20 Jun 2008 13:53:04 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KDr3429251; Fri, 20 Jun 2008 14:53:03 +0100 (BST) Message-ID: <485BB648.2020600@cisco.com> Date: Fri, 20 Jun 2008 14:53:12 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B8916.2010400@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=611; t=1213969985; x=1214833985; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=O5heFBGF7XqWcysSdxV3Jnc4znnU/fWMoXyntZB8oMk=; b=dZ5AF6L2alSl+3mnrAO0HxHL8US4Dr0UWv5ve+E76zDrP/nEqEA+1RUVRk 1U5tHkRnSa9Jjfa0xefN1G67LGAJM6CIqX1wor5Lkt5Bl1dk89mamnV23opD YPVs+2wiCo; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian >>> The IE type options template requires the informationElementId IE, >>> which is defined in psamp-info, and as such is not yet available in >>> the IANA registry. >> >> I hope Nevil and IANA will have this cleared up before the next meeting? > > psamp-info is still in the rfc editor queue, waiting for the protocol > and sampling techniques edits, I think... Even so, the IEs can and should be added to the IANA registry immediately. Is there any reason to stall their addition pending official publication of the RFC? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 06:53:12 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E133A69F9; Fri, 20 Jun 2008 06:53:12 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748823A6A51 for ; Fri, 20 Jun 2008 06:53:10 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gyLuKRFRZIy for ; Fri, 20 Jun 2008 06:53:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 390683A69F9 for ; Fri, 20 Jun 2008 06:53:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="12249340" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 15:53:05 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5KDr5il010386; Fri, 20 Jun 2008 15:53:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KDr4Xi005032; Fri, 20 Jun 2008 13:53:04 GMT Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KDr3429251; Fri, 20 Jun 2008 14:53:03 +0100 (BST) Message-ID: <485BB648.2020600@cisco.com> Date: Fri, 20 Jun 2008 14:53:12 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Brian Trammell References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B8916.2010400@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=611; t=1213969985; x=1214833985; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20ipfix-bounces@ietf.org] =20=20Re=3A=20[IPFIX]=20WG=20Last=20Call=20for=0A=20'Exporti ng=20Types'=20draft |Sender:=20; bh=O5heFBGF7XqWcysSdxV3Jnc4znnU/fWMoXyntZB8oMk=; b=dZ5AF6L2alSl+3mnrAO0HxHL8US4Dr0UWv5ve+E76zDrP/nEqEA+1RUVRk 1U5tHkRnSa9Jjfa0xefN1G67LGAJM6CIqX1wor5Lkt5Bl1dk89mamnV23opD YPVs+2wiCo; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian >>> The IE type options template requires the informationElementId IE, >>> which is defined in psamp-info, and as such is not yet available in >>> the IANA registry. >> >> I hope Nevil and IANA will have this cleared up before the next meeting? > > psamp-info is still in the rfc editor queue, waiting for the protocol > and sampling techniques edits, I think... Even so, the IEs can and should be added to the IANA registry immediately. Is there any reason to stall their addition pending official publication of the RFC? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Jun 20 07:18:26 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1843F3A6A0C; Fri, 20 Jun 2008 07:18:26 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998723A698E for ; Fri, 20 Jun 2008 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL-uR-FsDoAX for ; Fri, 20 Jun 2008 07:18:19 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 298763A67B3 for ; Fri, 20 Jun 2008 07:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 07B96D93AF; Fri, 20 Jun 2008 16:18:19 +0200 (MEST) 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 F8UYLPBq1nsl; Fri, 20 Jun 2008 16:18:18 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id C5C9ED937E; Fri, 20 Jun 2008 16:18:18 +0200 (MEST) In-Reply-To: <485BB648.2020600@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B8916.2010400@cisco.com> <485BB648.2020600@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 16:18:16 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Hmm. Come to think of it, no. This would also remove the normative reference to -info. - Brian On Jun 20, 2008, at 3:53 PM, Paul Aitken wrote: > Brian > >>>> The IE type options template requires the informationElementId IE, >>>> which is defined in psamp-info, and as such is not yet available in >>>> the IANA registry. >>> >>> I hope Nevil and IANA will have this cleared up before the next >>> meeting? >> psamp-info is still in the rfc editor queue, waiting for the >From ipfix-bounces@ietf.org Fri Jun 20 07:18:26 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1843F3A6A0C; Fri, 20 Jun 2008 07:18:26 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998723A698E for ; Fri, 20 Jun 2008 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL-uR-FsDoAX for ; Fri, 20 Jun 2008 07:18:19 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 298763A67B3 for ; Fri, 20 Jun 2008 07:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 07B96D93AF; Fri, 20 Jun 2008 16:18:19 +0200 (MEST) 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 F8UYLPBq1nsl; Fri, 20 Jun 2008 16:18:18 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id C5C9ED937E; Fri, 20 Jun 2008 16:18:18 +0200 (MEST) In-Reply-To: <485BB648.2020600@cisco.com> References: <6C4319CC-BB19-45DA-A05B-F76DFF0EDB0A@cert.org> <8F4BEED5-19ED-4644-A89E-DBD9DACEA947@cert.org> <48071369.4050404@informatik.uni-tuebingen.de> <6DD52CEB-A4F7-4778-B487-8AAC1A60ABAC@auckland.ac.nz> <4857B927.8090801@informatik.uni-tuebingen.de> <485A74DF.6060309@informatik.uni-erlangen.de> <8A364F1D-746B-4E3A-81A9-596DF3C72FFC@tik.ee.ethz.ch> <485B8916.2010400@cisco.com> <485BB648.2020600@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Trammell Date: Fri, 20 Jun 2008 16:18:16 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: WG Last Call for 'Exporting Types' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Hmm. Come to think of it, no. This would also remove the normative reference to -info. - Brian On Jun 20, 2008, at 3:53 PM, Paul Aitken wrote: > Brian > >>>> The IE type options template requires the informationElementId IE, >>>> which is defined in psamp-info, and as such is not yet available in >>>> the IANA registry. >>> >>> I hope Nevil and IANA will have this cleared up before the next >>> meeting? >> psamp-info is still in the rfc editor queue, waiting for the > protocol and sampling techniques edits, I think... > > Even so, the IEs can and should be added to the IANA registry > immediately. > > Is there any reason to stall their addition pending official > publication of the RFC? > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix >> protocol and sampling techniques edits, I think... > > Even so, the IEs can and should be added to the IANA registry > immediately. > > Is there any reason to stall their addition pending official > publication of the RFC? > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jun 26 22:25:59 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA413A68A1; Thu, 26 Jun 2008 22:25:59 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429D73A68A1 for ; Thu, 26 Jun 2008 22:25:58 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drLXvc-H72Pk for ; Thu, 26 Jun 2008 22:25:57 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 47A703A67D7 for ; Thu, 26 Jun 2008 22:25:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 39509480539; Fri, 27 Jun 2008 17:26:00 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypiMo1ifHqNV; Fri, 27 Jun 2008 17:26:00 +1200 (NZST) Received: from [130.216.38.130] (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 50BEA480543; Fri, 27 Jun 2008 17:25:56 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Nevil Brownlee Date: Fri, 27 Jun 2008 17:25:55 +1200 To: Elisa Boschi , Brian Trammell , Lutz Mark , Tanja Zseby X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: [IPFIX] IPFIX Exporting Types X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Elisa et al: There seem to have been lots of comments from this draft's WG LC, so clearly you need to published a new revision of it. After that, do you think we need another WG LC, or will it then be ready to submit to IESG? 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jun 26 22:25:59 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA413A68A1; Thu, 26 Jun 2008 22:25:59 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429D73A68A1 for ; Thu, 26 Jun 2008 22:25:58 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drLXvc-H72Pk for ; Thu, 26 Jun 2008 22:25:57 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 47A703A67D7 for ; Thu, 26 Jun 2008 22:25:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 39509480539; Fri, 27 Jun 2008 17:26:00 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypiMo1ifHqNV; Fri, 27 Jun 2008 17:26:00 +1200 (NZST) Received: from [130.216.38.130] (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 50BEA480543; Fri, 27 Jun 2008 17:25:56 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Nevil Brownlee Date: Fri, 27 Jun 2008 17:25:55 +1200 To: Elisa Boschi , Brian Trammell , Lutz Mark , Tanja Zseby X-Mailer: Apple Mail (2.753.1) Cc: IETF IPFIX Working Group Subject: [IPFIX] IPFIX Exporting Types X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Elisa et al: There seem to have been lots of comments from this draft's WG LC, so clearly you need to published a new revision of it. After that, do you think we need another WG LC, or will it then be ready to submit to IESG? 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jun 30 05:00:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B973A6ACB; Mon, 30 Jun 2008 05:00:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 82E543A6ACB; Mon, 30 Jun 2008 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080630120001.82E543A6ACB@core3.amsl.com> Date: Mon, 30 Jun 2008 05:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart 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 : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-00.txt Pages : 25 Date : 2008-06-30 This document describes a framework for an IPFIX Mediation. An IPFIX Mediation device (IPFIX Mediator) is an intermediate device between IPFIX Exporters and IPFIX Collectors. This framework describes an architecture model, the components of the architecture, and guidelines for the IPFIX protocol specifications for the IPFIX Mediators. In addition, this document describes applicable examples for IPFIX Mediation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-30045531.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jun 30 05:00:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B973A6ACB; Mon, 30 Jun 2008 05:00:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 82E543A6ACB; Mon, 30 Jun 2008 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080630120001.82E543A6ACB@core3.amsl.com> Date: Mon, 30 Jun 2008 05:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart 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 : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-00.txt Pages : 25 Date : 2008-06-30 This document describes a framework for an IPFIX Mediation. An IPFIX Mediation device (IPFIX Mediator) is an intermediate device between IPFIX Exporters and IPFIX Collectors. This framework describes an architecture model, the components of the architecture, and guidelines for the IPFIX protocol specifications for the IPFIX Mediators. In addition, this document describes applicable examples for IPFIX Mediation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-30045531.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jun 30 14:46:43 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94C13A6B0B; Mon, 30 Jun 2008 14:46:43 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5DC28C104 for ; Mon, 30 Jun 2008 09:32:27 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CRrskB-VNhJ for ; Mon, 30 Jun 2008 09:32:27 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C902128C0FF for ; Mon, 30 Jun 2008 09:32:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7CE32D93DE; Mon, 30 Jun 2008 18:32:36 +0200 (MEST) 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 xaWhnc+YdaF1; Mon, 30 Jun 2008 18:32:36 +0200 (MEST) Received: from [82.130.102.89] (nb-5442.ethz.ch [82.130.102.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: boschie) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3EC24D936B; Mon, 30 Jun 2008 18:32:36 +0200 (MEST) Message-ID: <48690AA4.5030901@tik.ee.ethz.ch> Date: Mon, 30 Jun 2008 18:32:36 +0200 From: Elisa Boschi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nevil Brownlee References: In-Reply-To: X-Mailman-Approved-At: Mon, 30 Jun 2008 14:46:43 -0700 Cc: Lutz Mark , Tanja Zseby , IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Exporting Types X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Nevil, yes we will submit a new revision of Exporting Types shortly. There haven't been major issues and we've addressed all the comments received during last call in the upcoming version, so we believe it will be ready for submission to the IESG. cheers, Elisa Nevil Brownlee wrote: > > Hi Elisa et al: > > There seem to have been lots of comments from this draft's WG LC, > so clearly you need to published a new revision of it. After that, > do you think we need another WG LC, or will it then be ready to > submit to IESG? > > 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 > > > > > ************************************************************************************************** > E-mail Confidentiality Notice and Disclaimer. > This e-mail and any files transmitted with it are confidential and are > intended solely for the use of the individual or entity to which they > are addressed. Access to this e-mail by anyone else is unauthorised. If > you are not the intended recipient, any disclosure, copying, > distribution or any > action taken or omitted to be taken in reliance on it, is prohibited. > E-mail messages are not necessarily secure. Hitachi does not accept > responsibility for any changes made to this message after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer > viruses. > ************************************************************************************************** > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jun 30 14:46:43 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94C13A6B0B; Mon, 30 Jun 2008 14:46:43 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5DC28C104 for ; Mon, 30 Jun 2008 09:32:27 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CRrskB-VNhJ for ; Mon, 30 Jun 2008 09:32:27 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C902128C0FF for ; Mon, 30 Jun 2008 09:32:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7CE32D93DE; Mon, 30 Jun 2008 18:32:36 +0200 (MEST) 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 xaWhnc+YdaF1; Mon, 30 Jun 2008 18:32:36 +0200 (MEST) Received: from [82.130.102.89] (nb-5442.ethz.ch [82.130.102.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: boschie) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3EC24D936B; Mon, 30 Jun 2008 18:32:36 +0200 (MEST) Message-ID: <48690AA4.5030901@tik.ee.ethz.ch> Date: Mon, 30 Jun 2008 18:32:36 +0200 From: Elisa Boschi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nevil Brownlee References: In-Reply-To: X-Mailman-Approved-At: Mon, 30 Jun 2008 14:46:43 -0700 Cc: Lutz Mark , Tanja Zseby , IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Exporting Types X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Nevil, yes we will submit a new revision of Exporting Types shortly. There haven't been major issues and we've addressed all the comments received during last call in the upcoming version, so we believe it will be ready for submission to the IESG. cheers, Elisa Nevil Brownlee wrote: > > Hi Elisa et al: > > There seem to have been lots of comments from this draft's WG LC, > so clearly you need to published a new revision of it. After that, > do you think we need another WG LC, or will it then be ready to > submit to IESG? > > 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 > > > > > ************************************************************************************************** > E-mail Confidentiality Notice and Disclaimer. > This e-mail and any files transmitted with it are confidential and are > intended solely for the use of the individual or entity to which they > are addressed. Access to this e-mail by anyone else is unauthorised. If > you are not the intended recipient, any disclosure, copying, > distribution or any > action taken or omitted to be taken in reliance on it, is prohibited. > E-mail messages are not necessarily secure. Hitachi does not accept > responsibility for any changes made to this message after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer > viruses. > ************************************************************************************************** > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix